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 nereye kaydedildiğini 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. Bu plan, işlemlerin sırasını ve uygulamanın yeniden kullanılabilir hale geldiğinin ilan edilmesi için gerekli kanıtları açıklamalıdır.
İki iş sorusuyla başlayın
İşletme, ne kadar miktarda güncel veriyi 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ğlı olan kişilerle mutabık kalınarak belirlenmelidir.
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 işe yaramaz.
Veritabanının bağlı olduğu her şeyi listele
Uygulamanın geri yüklenmesi 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 getirebilecek yetkili bir yol gerekiyor. “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 prova, çalışmakta olan 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 uygulama başlatma işlemlerini 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. İşleyicileri başlatmadan önce, bu entegrasyonları devre dışı bırakırım ya da kimlik bilgilerini test yapılandırmasıyla değiştiririm. Aksi takdirde, bir kurtarma tatbikatı kendi başına bir üretim kazasına yol açabilir.
PostgreSQL’in SQL dökümü belgeleri, mantıksal yedeklemelerin işleyişini ve sınırlamalarını açıklamaktadır. 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ılarını değil, davranışları da doğrulayın
Uygulama düzeyinde kısa bir kurtarma kontrol listesi kullanıyorum:
- Yetkili bir kullanıcı oturum açabilir mi?
- Uygulama, son dönemden ve daha eski dönemlerden temsili kayıtları okuyabilir mi?
- Yüklenen varlıklar ile bunların veritabanındaki referansları birbiriyle uyumlu mu?
- Güvenli bir test işlemi tamamlanabilir mi?
- Arka plan çalışanları, istenmeyen geçmiş işlemleri yürütmeden hazır mı?
- Geri yükleme işleminden 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 işlevsel olduğunu 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 kimliği, 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.