Başarılı bir yedekleme işlemi, bir işlemin tamamlandığını gösterir. Ancak uygulamanın kurtarılabilir olup olmadığını göstermez. Bu fark, asıl sunucu erişilemez hale geldiğinde ve şifreleme anahtarının nerede saklandığını kimse hatırlamadığında acı bir şekilde ortaya çıkar.
Küçük bir ekip için, başka bir mühendisin baskı altında bile uygulayabileceği bir kurtarma planı istiyorum. Plan, işlemlerin sırasını ve uygulamanın tekrar kullanılabilir hale geldiğini belirlemek için gerekli kanıtları açıklamalıdır.
İki iş sorusuyla başlayın
İşletme, son dönemde toplanan verilerin ne kadarını kaybetmeyi göze alabilir ve hizmet ne kadar süreyle kullanılamaz durumda kalabilir? Bu soruların yanıtları, kurtarma noktası ve kurtarma süresi hedeflerini belirler. Bu hedefler, uygulamaya bağımlı olan kişilerle mutabık kalınmalıdır.
Günlük bir veritabanı kopyalaması, kurum içi bir raporlama aracı için uygun olabilirken, yoğun bir sipariş sistemi için kabul edilemez olabilir. Benzer şekilde, geri yüklemesi saatler süren bir yedekleme, teknik açıdan geçerli olsa da iş gereksinimlerini karşılayamayabilir.
Hedefin temelini oluşturan varsayımları not alıyorum: veri hacmi, mevcut altyapı, operatöre erişim ve kurtarma işleminin aynı sağlayıcıda gerçekleştirilip gerçekleştirilmeyeceği. Orijinal sunucunun çalışır durumda olduğunu varsayan bir kurtarma tahmini, söz konusu sunucu arızalı bileşen olduğunda bir anlam ifade etmez.
Veritabanının bağlı olduğu her şeyi listeleyin
Uygulamanın kurtarılması için genellikle tabloların ötesinde unsurlar gerekir. Yüklenen dosyalar, şifreleme anahtarları, yapılandırma, şema geçişleri, kimlik ayarları ve dağıtım öğeleri, geri yüklenen verilerin yorumlanması veya kullanılması için gerekli olabilir.
Sırları sıradan uygulama dosyalarından ayrı tutuyorum, ancak kurtarma prosedürü için yine de bunları geri alabilmenin yetkili bir yoluna ihtiyaç var. “Anahtarların güvenli olması” ile “anahtarların kurtarılabilir olması” birbirinden ayrı özelliklerdir.
Envanterde, harici ödeme durumu gibi yedeklemeye dahil edilmeyen bağımlılıklar da kaydedilmelidir. Kurtarma işleminden sonra, uygulamanın her iki sistemin de aynı anda durduğunu varsaymak yerine, yerel kayıtlarını bir sağlayıcıyla karşılaştırması gerekebilir.
İzole edilmiş bir ortama geri yükle
Bir deneme, çalışan veritabanının elverişli bir kopyasından değil, depolanmış yedekten başlamalıdır. Bu alıştırmanın erişim, şifre çözme, aktarım, geri yükleme ve uygulamanın başlatılmasını test etmesini istiyorum.
Yeniden devreye alınan uygulama, müşterilere e-posta göndermemeli, canlı ödeme işlemleri gerçekleştirmemeli veya giden webhook’ları tekrar çalıştırmamalıdır. İşlemcileri başlatmadan önce, bu entegrasyonları devre dışı bırakıyorum ya da kimlik bilgilerini test yapılandırmasıyla değiştiriyorum. Aksi takdirde, bir kurtarma tatbikatı kendi başına bir üretim kesintisine yol açabilir.
PostgreSQL’in SQL dökümü belgeleri mantıksal yedeklemelerin işleyişini ve sınırlamalarını açıklar. Bir yedekleme yöntemi seçerken veritabanının boyutu ve kurtarma gereksinimleri göz önünde bulundurulmalıdır; mantıksal döküm, her iş yükü için otomatik olarak en uygun tasarım değildir.
Sadece satır sayısını değil, davranışı da doğrulayın
Uygulama düzeyinde kısa bir kurtarma kontrol listesi kullanıyorum:
- Yetkili bir kullanıcı oturum açabilir mi?
- Uygulama, hem güncel hem de daha eski kayıtlardan örnek niteliğinde olanları okuyabilir mi?
- Yüklenen varlıklar ve bunların veritabanı referansları birbiriyle uyumlu mu?
- Güvenli bir test işlemi başarıyla tamamlanabilir mi?
- Arka plan çalışanları, istenmeyen geçmiş işlemleri yürütmeden hazır mı?
- Geri yüklemeden sonra kiracı sınırları hâlâ geçerli mi?
Sayımlar ve sağlama toplamları, eksik verilerin tespit edilmesine yardımcı olur; ancak uygulamanın düzgün çalıştığını kanıtlamaz. Ayrıca, gerçek kurtarma süresini ve operatörün belgelenmemiş bilgiye ihtiyaç duyduğu durumları da kaydediyorum.
Sürprizleri bakım işlerine dönüştürün
Bir sorunu ortaya çıkaran bir prova, amacına ulaşmış demektir. Eksik izinler, güncelliğini yitirmiş talimatlar ve uyumsuz uygulama sürümlerini, üretim ortamı sorunsuz çalışırken tespit etmek daha az maliyetlidir.
Çalışma kılavuzunu hemen güncelliyorum, ardından başarısız olan kısmı tekrarlıyorum. Kayıtta yedekleme tanımlayıcısı, uygulama sürümü, kurtarma ortamı, sonuç ve kalan eksiklikler yer almalıdır.
Bir yedeğe olan güvenim, yakın zamanda gerçekleştirilmiş ve tekrarlanabilir bir geri yükleme işleminden kaynaklanıyor. Zamanlanmış görev, gerekli verileri oluşturur; prova ise ekibin bu verileri yeniden bir hizmete dönüştürebilip dönüştüremeyeceğini gösterir.
25 Eylül 2026 tarihinde güncellenmiştir.