PostgreSQL yedek işinin “başarılı” görünmesi, veritabanının istenen ana geri döndürülebileceğini kanıtlamaz. Point-in-Time Recovery (PITR); bir base backup ile bu yedekten sonra oluşan kesintisiz WAL arşivini birleştirerek veritabanını belirli bir zamana veya işlem noktasına taşımayı hedefler. Ancak eksik bir WAL parçası, yanlış retention politikası, bozuk arşiv komutu veya belgelenmemiş şifreleme anahtarı geri dönüşü durdurabilir. Bu nedenle PITR bir ayar değil, düzenli olarak tatbik edilmesi gereken operasyon kabiliyetidir.

Backup ile PITR arasındaki fark

Mantıksal dump; tablo, şema veya seçili veriyi taşımak için kullanışlıdır. Fiziksel base backup ise cluster dosyalarının tutarlı bir temel kopyasını sağlar. PITR için base backup tek başına yetmez: Başlangıç noktasından hedef ana kadar gerekli WAL segmentlerinin eksiksiz ve doğru sırada erişilebilir olması gerekir. Bu zincirdeki boşluk, geri yüklemenin hedefe ilerlemesini engeller.

PITR özellikle yanlış veri silme, hatalı toplu güncelleme veya sorunlu uygulama dağıtımı gibi “veritabanı çalışıyor ama veri istenmeyen duruma geldi” senaryolarında değerlidir. Donanım arızası veya tam cluster kaybı için de kullanılabilir; fakat yüksek erişilebilirlik replikasının yerine geçmez. Replika servis devamlılığını, yedek ve PITR ise geçmişteki güvenli duruma dönüşü destekler.

Tatbikattan önce RPO ve RTO’yu netleştirin

RPO, kabul edilebilir veri kaybı aralığını; RTO ise hizmetin ne kadar sürede geri dönmesi gerektiğini anlatır. “Her gün yedek alıyoruz” ifadesi bu hedefleri tek başına karşılamaz. Günlük base backup alınsa bile WAL sürekli ve güvenli biçimde arşivleniyorsa daha dar bir RPO hedeflenebilir. Fakat geri dönüş süresi; veritabanı boyutu, depolama performansı, WAL miktarı, ağ aktarımı ve doğrulama adımlarına bağlıdır.

• Hangi veri kaybı aralığı işletme tarafından kabul edilebilir?
• Geri yüklenen sistem ne kadar sürede uygulamaya açılmalı?
• Hedef, son sağlıklı zaman mı yoksa belirli işlem/LSN noktası mı?
• Tatbikat için production’dan izole yeterli disk ve işlem kapasitesi var mı?
• Uygulama ekibi veri doğrulamasını hangi sorgularla yapacak?

Base backup ve WAL zincirini doğrulayın

Tatbikat için kullanılacak base backup’ın başlangıç/bitiş bilgilerini, boyutunu, checksum durumunu ve saklandığı konumu kaydedin. Ardından bu yedekten hedef zamana kadar gereken WAL segmentlerinin arşivde bulunduğunu kontrol edin. Yalnızca dosya sayısına bakmak yeterli değildir; arşivleme hataları, sıfır boyutlu dosyalar, yanlış timeline veya retention nedeniyle silinen segmentler ayrıca incelenmelidir.

Arşiv deposuna erişim için gereken kimlik bilgileri ve şifreleme anahtarları production sunucusunun tek kopyasına bağlı olmamalıdır. Felaket senaryosunda production erişilemez kabul edilmelidir. Geri yükleme runbook’u yeni ve yetkili bir operatörün anlayabileceği şekilde depo yolu, sürüm, gerekli uzantılar ve yapılandırma bağımlılıklarını içermelidir.

İzole geri yükleme ortamını hazırlayın

PITR tatbikatını mevcut production cluster’ın üzerinde yapmayın. Aynı ana sürümü, gerekli eklentileri, locale/encoding ayarlarını ve yeterli depolamayı içeren izole bir ortam kurun. Ağ kuralları, geri yüklenen veritabanının istemeden gerçek e-posta, ödeme, webhook veya job sistemlerine bağlanmasını engellemelidir. Uygulama testi yapılacaksa dış servisler sahte veya devre dışı uçlara yönlendirilmelidir.

Hedef zamanı olay çizelgesine göre seçin

Yanlış işlem saat 14:07’de fark edilmiş olabilir; fakat ilk hatalı kayıt 13:58’de oluşmuş olabilir. Hedefi yalnızca alarm saatine göre seçmek veri hatasını geri getirebilir. Uygulama logları, denetim kayıtları ve veritabanı olaylarını ortak zaman diliminde karşılaştırın. Önce olaydan birkaç dakika önceki güvenli hedefi belirleyin; gerekiyorsa farklı hedeflerle birden fazla izole restore yapın.

Recovery ayarlarında hedef zaman, timeline ve recovery tamamlandıktan sonraki davranış açıkça belirlenmelidir. Yanlış hedefe ulaşıldığında sistemi hemen uygulamaya açmak yerine doğrulama kapısında tutun. Tatbikatın amacı yalnızca PostgreSQL’in başlaması değil, doğru verinin doğru noktada bulunduğunu kanıtlamaktır.

Teknik ve iş doğrulamasını birlikte yapın

Veritabanının bağlantı kabul etmesi başlangıç kontrolüdür. Ardından sistem katalogları, uzantılar, tablo ve indeks erişimi, son işlem zamanları, sequence değerleri ve uygulamanın kritik sorguları doğrulanmalıdır. İş ekibi de temsilî müşteri, sipariş veya rapor kayıtlarını kontrol etmelidir. Teknik bütünlük ile iş bütünlüğü aynı değildir; ikisi için ayrı kabul ölçütü gerekir.

• PostgreSQL sürümü, timeline ve recovery logları beklenen durumda mı?
• Kritik tablolar okunuyor ve beklenen kayıt sayısı aralığında mı?
• İndeksler, constraint’ler ve uzantılar kullanılabilir mi?
• Sequence değerleri yeni kayıt üretmeye uygun mu?
• Uygulama salt-okunur smoke test’i tamamlıyor mu?
• Hatalı işlemin hedef sonrası kayıtları geri gelmemiş mi?
• Gizli veri içeren test ortamına erişim ve imha süreci tanımlı mı?

Süreyi ölçün ve darboğazı kaydedin

Tatbikatta her aşamanın başlangıç ve bitişini kaydedin: altyapı hazırlığı, base backup aktarımı, WAL replay, PostgreSQL açılışı, teknik doğrulama ve uygulama onayı. Toplam süre RTO hedefini aşıyorsa daha sık base backup, daha hızlı restore depolaması, önceden hazırlanmış otomasyon veya paralel doğrulama adımları değerlendirilebilir. Ölçülmeyen RTO yalnızca tahmindir.

Tatbikat sıklığını risk ve değişim hızına bağlayın

Geri yükleme tatbikatı yılda bir kez yapılan sembolik bir kontrol olmamalıdır. Veritabanı boyutu, trafik, şema değişim hızı, uzantılar, yedek altyapısı ve ekip değişiklikleri sıklığı belirler. Kritik bir SaaS veritabanında üç aylık tam PITR tatbikatı ve daha sık otomatik bütünlük kontrolleri uygun olabilir; daha düşük riskli sistemlerde farklı periyot seçilebilir. Önemli olan periyodun yazılı olması ve başarısız kontrolün takip işine dönüşmesidir.

PostgreSQL ana sürüm yükseltmesi, arşiv deposu değişikliği, şifreleme anahtarı rotasyonu, yedek aracının güncellenmesi veya büyük şema dönüşümü sonrasında takvimi beklemeden ek tatbikat planlayın. Sonuç kaydı; kullanılan base backup, ilk ve son WAL segmenti, hedef zaman, gerçekleşen RPO/RTO, doğrulama sorguları, hatalar ve düzeltme sahibini içermelidir. Böylece sonraki tatbikat aynı belirsizlikleri yeniden çözmek yerine önceki ölçümün üzerine kurulur.

PITR tatbikatı kontrol listesi

• RPO, RTO ve hedef recovery noktası yazılı.
• Base backup bütünlüğü ve PostgreSQL ana sürümü doğrulandı.
• Hedefe kadar WAL zincirinde boşluk olmadığı kontrol edildi.
• Arşiv erişimleri ve şifreleme anahtarları felaket senaryosunda kullanılabilir.
• İzole ortam yeterli disk, CPU, RAM ve ağ sınırlarına sahip.
• Dış e-posta, ödeme, webhook ve job çıkışları engellendi.
• Recovery logları, timeline ve hedef nokta kaydedildi.
• Teknik sorgular ve iş doğrulama senaryoları tamamlandı.
• Gerçekleşen RPO/RTO ile hedefler karşılaştırıldı.
• Tatbikat verisi güvenli biçimde silindi; runbook güncellendi.

PostgreSQL yedeklerinizi geri dönüş kabiliyetine çevirin

PostgreSQL Cluster Hosting ihtiyacınızda yedekleme, replikasyon, izleme ve bakım hedeflerini uygulamanızın RPO/RTO beklentileriyle birlikte değerlendirin. Mevcut PostgreSQL yapınız için kapasite ve geri dönüş planını görüşmek üzere Narweb ile iletişime geçebilirsiniz.