Web sitesi yedekleme ve geri yükleme planı

Neyi kaybedebileceğinizi belirleyin

Bir içerik sitesinde birkaç saatlik yazı değişikliği ile sipariş alan bir uygulamadaki birkaç saatlik işlem kaybı aynı etkiye sahip değildir. Kabul edilebilir veri kaybını ve hizmetin ne kadar süre kapalı kalabileceğini iş sahibiyle belirleyin.

RPO, geri dönüşte kabul edilen veri kaybının zaman aralığını; RTO, hizmeti geri getirmek için hedeflenen süreyi anlatır. Örneğin “en fazla bir saatlik veri kaybı” hedefi varsa günde bir yedek almak bu hedefi tek başına karşılamaz. Bunlar planlama hedefleridir; gerçekleşen süreyi testte ölçün.

Yedek kapsamını yazın

• Uygulama dosyaları ve sürüm bilgisi.
• Veritabanı ve tutarlı bir geri yükleme yöntemi.
• Kullanıcıların yüklediği dosyalar.
• Sunucu ve uygulama yapılandırmasının gerekli kısımları.
• Zamanlanmış işler ile bağımlı hizmetlerin envanteri.

Gizli anahtarları ve parolaları açık arşivlerde tutmayın. Yedek erişimini sınırlandırın ve şifreli saklama yöntemini planlayın. Aynı sunucudaki tek kopya, sunucu veya disk kaybında yeterli olmayabilir.

Geri yüklemeyi ayrı ortamda deneyin

Test için üretimden ayrılmış bir ortam kullanın. Yedeği açın, veritabanını yükleyin, gerekli yapılandırmaları tamamlayın ve uygulamanın kritik akışlarını kontrol edin. Test ortamının gerçek müşterilere e-posta, bildirim veya ödeme isteği göndermesini engelleyin.

Yedek tarihini, işlemi yapan kişiyi, geçen süreyi ve eksik bulunan dosyaları kaydedin. Rastgele birkaç dosyanın açılması yerine form gönderimi, yönetim girişi ve örnek kayıt okuma gibi anlamlı kontroller seçin.

Saklama ve olay planını işletin

Günlük, haftalık ve daha eski geri dönüş noktalarının kaç gün saklanacağını belirleyin. Bir sorun hemen fark edilmeyebilir; yalnızca son kopyayı tutmak hatalı veriyi bütün yedeklere taşıyabilir. Yedek işinin başarısızlığı için bildirim kurun.

Olay anında kimin karar vereceği, hangi yedeğin seçileceği, geri yükleme sonrası hangi kontrollerin yapılacağı ve kullanıcıların nasıl bilgilendirileceği önceden yazılı olmalı. Sunucu teklifinde yedek hizmeti varsa bu işlerin hangisinin sağlayıcıya ait olduğunu ayrıca sorun.

Kurtarma tatbikatının sonuç tutanağı

Geri yükleme testinden sonra yalnızca “başarılı” yazmayın. Kullanılan yedeğin tarihi, geri getirilen uygulama sürümü, veri kapsamı ve gerçek geçen süre birlikte kaydedilsin. Yedeğin alınma zamanı ile kullanılabilir hizmetin geri geldiği zaman farklı bilgilerdir.

Örneğin dosyalar açıldığı hâlde veritabanındaki son kayıtlar eksik olabilir. Ya da uygulama açılır ama yüklenen görseller yanlış dizinde kaldığı için görünmez. Kabul listesine içerik okuma, dosya erişimi ve uygulamanıza uygun kritik bir iş akışı ekleyin.

• Yedek dosyası ve gerekli erişimler bulunabildi mi?
• Geri yüklemeyi dokümana bakarak başka bir kişi yapabildi mi?
• Veri kaybı ve süre, belirlenen hedef içinde kaldı mı?
• Eksikler için sorumlu ve düzeltme tarihi belirlendi mi?

Tatbikatın amacı yalnızca sistemi sınamak değil, olay anında gereken bilginin tek bir kişiye bağlı kalmasını da önlemektir.