Felaket Kurtarma Planı Rehberi: RPO, RTO ve Tatbikat

Bu rehber, bir felaket kurtarma planının nasıl hazırlanacağını anlatır: iş etki analizinden hedef sürelere, yedekleme mimarisinden tatbikata. Küçük bir şirketin tek sunucusu için de, çok bölgeli bir bulut altyapısı için de aynı sıra geçerlidir.

1. İş Etki Analizi

Her sistem için iki soru sorulur: Bu sistem ne kadar süre durabilir ve en fazla ne kadar veri kaybedebiliriz? Cevaplar iş birimleriyle birlikte verilir; teknik ekip tek başına karar vermez. Sistemler kritiklik sınıflarına ayrılır; sınıf, hedef süreleri ve bütçeyi belirler.

Çıktı: Sistem envanteri, bağımlılık haritası, kritiklik sınıfları.

2. RPO ve RTO

RPO (kurtarma noktası hedefi) kabul edilebilir veri kaybını, RTO (kurtarma süresi hedefi) kabul edilebilir kesintiyi tanımlar. Dört saatlik RPO, saatte bir yedek almanın yeterli olmadığını; bir saatlik RTO, geri yüklemenin bir saatte bitmesi gerektiğini söyler. Her ikisi düşürüldükçe maliyet artar; bu nedenle hedefler sistem bazında farklı olmalıdır.

Çıktı: Sistem bazlı RPO / RTO tablosu, yönetim onayı.

3. Yedekleme Mimarisi

3-2-1-1-0 kuralı temel alınır: en az üç kopya, iki farklı ortam, bir kopya uzakta, bir kopya çevrimdışı ya da değiştirilemez, sıfır doğrulama hatası. Fidye yazılımı yedek sunucusuna da ulaşabildiğinden değiştirilemez (immutable) depolama ve ayrı kimlik bilgileri şarttır. Veritabanları için zaman noktasına geri dönüş, SaaS verileri (e-posta, dokümanlar, CRM) için sağlayıcıdan bağımsız yedek planlanır.

4. Felaket Senaryoları

Plan en az beş senaryoyu kapsar: tek sunucu arızası, veri bozulması ya da yanlışlıkla silme, fidye yazılımı, veri merkezi veya bölge kesintisi, kritik personelin ulaşılamaz olması. Her senaryo için tetikleyici, karar verici, ilk adımlar ve iletişim listesi yazılır.

5. Runbook'lar

Geri dönüş adımları, o sistemi daha önce hiç yönetmemiş bir mühendisin uygulayabileceği açıklıkta yazılır: hangi yedek, hangi komut, hangi sırayla, doğrulama nasıl yapılır. Runbook'lar sürüm kontrolünde tutulur ve her tatbikattan sonra güncellenir.

Çıktı: Sistem başına runbook; erişim bilgileri güvenli kasada.

6. İkinci Bölge Seçenekleri

Soğuk bekleme (yalnızca yedek var, altyapı sonradan kurulur) en ucuz ve en yavaştır; ılık bekleme (altyapı hazır, veri düzenli eşitlenir) orta; sıcak bekleme (eş zamanlı çoğaltma, otomatik geçiş) en pahalı ve en hızlıdır. Seçim RTO hedefine göre yapılır; altyapının kod olarak tanımlanması (IaC) soğuk ve ılık seçenekleri önemli ölçüde hızlandırır.

7. Tatbikat

Test edilmemiş plan, plan değildir. Çeyreklik geri yükleme testleri (tek sistem) ve yıllık tam tatbikat (senaryo bazlı) takvime bağlanır. Tatbikat üretimi etkilemeyen yalıtılmış ortamda yapılır; ölçülen gerçek süreler hedeflerle karşılaştırılır, farklar iyileştirme listesine girer.

Çıktı: Tatbikat raporu: ölçülen RPO / RTO, aksayan adımlar, güncellenen runbook'lar.

8. İşletme ve Uyum

Günlük yedek başarı kontrolü, aylık rapor, değişen sistemlerin plana eklenmesi ve yıllık gözden geçirme hizmetin rutinidir. ISO 22301 ve KVKK denetimleri için tatbikat raporları ve yedek kayıtları kanıt olarak saklanır.

9. Süre ve Maliyeti Belirleyen Etkenler

• Sistem sayısı ve veri hacmi; veritabanı ve uygulama çeşitliliği.
• Hedef süreler: düşük RPO / RTO ikinci bölge ve çoğaltma gerektirir.
• Bekleme modeli: soğuk, ılık ya da sıcak.
• SaaS ve uç nokta verilerinin kapsama alınıp alınmayacağı.
• Tatbikat sıklığı ve denetim gereksinimleri.

Kontrol Listesi

• Sistem envanteri ve kritiklik sınıfları onaylandı.
• Sistem bazlı RPO / RTO tablosu yönetimce imzalandı.
• 3-2-1-1-0 kuralı uygulanıyor; değiştirilemez kopya var.
• Beş temel senaryo için karar verici ve iletişim listesi yazılı.
• Her kritik sistemin runbook'u sürüm kontrolünde.
• İkinci bölge modeli RTO hedefine göre seçildi.
• Son tatbikat raporu altı aydan yeni; iyileştirmeler kapatıldı.
• Yedek başarı raporu günlük kontrol ediliyor.