Yedek almak ile geri dönebilmek aynı şey değildir. PostgreSQL tarafında bu fark en çok Point-in-Time Recovery (PITR) senaryolarında ortaya çıkar. Snapshot vardır ama hedeflenen dakikaya dönemezsiniz; WAL vardır ama zincir eksiktir; restore vardır ama uygulama ekibi ne zaman trafik açacağını bilemez.
Bu yazıda, WAL arşivleme + base backup + tatbikat disiplini ile üretimde gerçekten işe yarayan PITR akışını ele alıyorum. Amaç “yedek var” demek değil, “şu zamana güvenle dönebiliyoruz” diyebilmektir.
1) Önce hedef: ne kadar geriye, ne kadar sürede döneceğiz?
PITR tasarımı teknik parametreyle değil, iki operasyonel soruyla başlar:
- RPO: Kaç dakikalık veri kaybı kabul edilebilir?
- RTO: Servis kaç dakikada tekrar ayağa kalkmalı?
Bu iki hedef, arşivleme sıklığını, depolama sınıfını ve restore altyapısını doğrudan belirler. RPO 5 dakika ise “günde bir dump” zaten tartışma dışıdır. RTO 20 dakika ise 2 TB veritabanını tek spindle diskten geri açmak da gerçekçi değildir.
2) Sağlam model: base backup + sürekli WAL arşivi
En pratik yapı:
- Düzenli base backup
- Sürekli ve doğrulanan WAL archive
- Ayrı ortamda restore prova hattı
Bu üçlüden biri eksikse PITR yalnızca dokümantasyonda kalır. Base backup noktayı verir, WAL aralığı doldurur, prova hattı ise zincirin gerçekten işe yaradığını kanıtlar.
Neleri mutlaka doğrularım?
archive_mode=onarchive_commandgerçekten hata kontrolü yapıyor mu?- Arşiv hedefi ayrı hata alanında mı? (aynı disk/kümeye yazmak risklidir)
- WAL dosyaları restore edilmeden önce bozulma kontrolü var mı?
Basit ama yüksek değerli ilke: sessiz başarısızlık kabul edilmez. Arşivleme komutu “0” döndürüp dosyayı eksik bırakıyorsa elinizde yedek yoktur.
3) Arşiv hedefi: ucuz depolama yetmez, doğrulanabilir depolama gerekir
Sahada iki hata çok görülür:
- WAL aynı altyapıya yazılır, ana sistem gidince arşiv de gider
- Object storage var ama bütünlük ve erişim modeli tanımsızdır
Doğru yaklaşım:
- Farklı hata alanına yaz
- Yazılan nesne için checksum/bütünlük doğrulaması yap
- Yaşam döngüsünü tanımla: kaç gün hot, kaç gün archive?
- Restore sırasında erişim hızını ölç
Object storage kullanıyorsanız yalnızca “orada duruyor” demek yetmez. İlgili prefix için yanlış lifecycle policy, replication gecikmesi veya erişim anahtarı problemi PITR gününde ortaya çıkar.
4) Restore runbook: saat kaçta ne yapacağım?
PITR runbook’u şu kararları açık taşımalıdır:
- Hedef zaman damgası nasıl belirlenecek?
- Hangi base backup kullanılacak?
- Geri yüklenen kopya izole ağda mı açılacak?
- Uygulama tarafı ne zaman read-only veya maintenance moduna alınacak?
- Trafik ne zaman yeni kopyaya yönlenecek?
Örnek akış:
pg_basebackup --write-recovery-conf --pgdata /restore/pgdata
restore_command='cp /wal-archive/%f %p'
recovery_target_time='2026-04-29 10:37:00+03'Komut satırı tek başına yeterli değil. En kritik karar, hedef zaman damgasının kimin onayıyla seçildiğidir. Erken dönerseniz veri kaybı büyür; geç dönerseniz bozuk değişiklikleri geri almış olmazsınız.
5) Tatbikat: başarı ölçütü “restore açıldı” değil
İyi tatbikatta şu sorulara cevap çıkar:
- Hedef zamana gerçekten döndük mü?
- Uygulama login/checkout/order gibi kritik akışları geçti mi?
- Replikasyon veya yeni yedekleme zinciri tekrar devreye alındı mı?
- İşlem toplam ne kadar sürdü?
Benim önerim, tatbikat sonucunu şu başlıklarla kapatmaktır:
- Teknik sonuç: zincir çalıştı mı?
- Süre: RTO’ya uydu mu?
- Karar boşluğu: ekip hangi anda duraksadı?
- Aksiyon: sonraki tatbikata kadar ne düzeliyor?
6) En pahalı hatalar
- Arşiv hedefini hiç restore etmeden “çalışıyor” sanmak
- Base backup ve WAL sürüm uyumsuzluğunu prova etmemek
- PITR runbook’unu yalnızca DBA’nın bilmesi
- Kurtarma sonrası yeni yedekleme zincirini başlatmayı unutmak
Son madde özellikle kritiktir. Restore sonrası sistem açılır ama yeni backup zinciri kurulmazsa, ikinci bir arızada tekrar kör kalırsınız.
Sonuç
PostgreSQL PITR, “yedek alıyoruz” rahatlığının değil, geri dönüş disiplininin testidir. Base backup, WAL arşivi ve düzenli tatbikat üçlüsünü birlikte işletirseniz veri kaybı penceresini gerçekten yönetebilirsiniz. Üretimde fark yaratan şey komut ezberi değil; hedef zaman, erişim modeli ve kurtarma sonrası toparlanma zincirini netleştirmektir.