Yedekleme Planı: RPO, RTO ve Gerçek Geri Yükleme Testi

Veri kaybı hedefi ile kesinti hedefini ayırın

RPO, kabul edilebilir veri kaybının zaman boyutunu; RTO ise hizmetin geri dönmesi için kabul edilen süreyi tarif eden hedeflerdir. AWS kurtarma hedefleri açıklaması bu ayrımı yapar. [1] Hedefleri teknik ekip tek başına seçmemeli; iş etkisi ve maliyet birlikte değerlendirilmelidir.

Bir rapor arşivi ile aktif sipariş sistemi aynı hedefe ihtiyaç duymayabilir. “Her şeyi her dakika yedekleyelim” gibi belirsiz bir istek yerine hangi verinin yeniden oluşturulabildiğini ve kesintinin hangi işi durdurduğunu yazın. Hedef, ölçülmüş başarı değil istenen koşuldur.

Yedek kapsamını bileşen bazında çıkarın

Veri tabanı dışında yüklenen dosyalar, yapılandırma, uygulama sürümü ve dış servis bağlantıları gerekebilir. Veri geri geldi ama dosyalar yoksa iş tamamlanamayabilir. Yedeğin hangi bileşenleri kapsadığı, hangi bağımlılıkları kapsamadığı açık olsun.

PostgreSQL farklı yedekleme yaklaşımlarını ayrı yöntemler olarak ele alır. [2] Kullanılan yöntemin sürüm uyumu, geri yükleme gereksinimi ve kapsamı değerlendirilmelidir. Dosya kopyalama ile veri tabanı için tutarlı yedek alma aynı şey olarak kabul edilmemelidir.

Örnek: sipariş verisi var, ek dosyalar eksik

Varsayımsal B2B sisteminde sipariş çizimleri dosya depolamada, sipariş satırları veri tabanında tutuluyor. Sadece veri tabanı geri yüklendiğinde sipariş ekranı açılır ama üretim için gerekli çizim yoktur. Teknik sağlık kontrolü yeşil olsa da işlevsel kurtarma tamamlanmamıştır.

Örnekte gerçek kesinti süresi veya veri kaybı sonucu ileri sürülmez. Amaç, geri yüklemenin işletme işiyle doğrulanması gerektiğini göstermektir.

Yedeğin erişimini ve ayrılığını düşünün

Üretim hesabını etkileyen bir hata yedeğe de zarar verebiliyorsa risk değerlendirilmelidir. Yedeklere erişim, silme yetkisi ve saklama politikası ayrı ele alınabilir. Şifreleme kullanılıyorsa geri yükleme sırasında gerekli anahtarlara kontrollü erişimin sağlandığı doğrulanmalıdır.

Yedeklerin nerede bulunduğunu herkesin bilmesi gerekmez; fakat yetkili ekip kurtarma yönergesine ulaşabilmelidir. Tek kişinin bilgisayarındaki not veya erişim bilgisi operasyonel bağımlılık yaratır. Gerekli yetki devri ve acil erişim süreci planlanmalıdır.

Prova sırasında yanlış dış işlemleri engelleyin

Yedekten açılan test ortamı gerçek müşterilere mesaj göndermemeli, canlı ödeme veya sipariş sistemine kontrolsüz bağlanmamalıdır. Kurtarma testi için güvenli çevre ve sentetik doğrulama adımları hazırlayın. Testin kendisi yeni bir olaya dönüşmemelidir.

Süre ölçümünü ilk komutla değil, belirlenen kurtarma başlangıcıyla ilişkilendirin. Yedeği bulma, erişim açma, altyapıyı hazırlama ve işlevsel kontrol zamanları toplam sürenin parçası olabilir. Sadece veri kopyalama süresini RTO sonucu gibi sunmayın.

Sonuçları hedeflerle karşılaştırın

Geri gelen son doğrulanmış kaydın zamanı ve hizmetin kullanılabilir olduğu an kaydedilsin. Hedef karşılanmadıysa darboğazın nerede olduğu açıklansın. Daha sık yedek almak her durumda geri yükleme süresini kısaltmayabilir; hedefler farklıdır.

Teslimde yedek politikası, kapsam listesi, geri yükleme yönergesi ve son prova raporu isteyin. Yeni dosya türü veya entegrasyon eklendiğinde plan güncellensin. Bu rehber mevzuata uygunluk veya veri kaybının imkânsız olduğu yönünde bir garanti vermez.

Sık sorulan sorular

### Otomatik yedekleme açıksa test şart mı? Yedeğin kullanılabilirliği, bağımlılıklar ve geri dönüş süresi ancak uygun prova ile doğrulanabilir. Otomasyonun açık olması tek başına yeterli kanıt değildir.

Replika sunucu yedek yerine geçer mi?

Her riski karşılamaz. Hatalı değişiklikler kopyaya da yayılabilir. Yedek, geçmişe dönüş ve hizmet sürekliliği ihtiyaçları ayrı değerlendirilmelidir.