İçeriğe atla
Bilgi Merkezi/Rehber
Rehber

Bir Şey Kanıtlayan Felaket Kurtarma Testi Nasıl Yapılır?

Saldırıya uğrayan kurumların ortalama kurtarma süresi 24,6 gün. Uygulanabilir bir FKM test prosedürü, neyin ölçüleceği ve hangi sıklıkla tekrarlanacağı.

Oğuzhan Gerçek··3 dk okuma
Bir Şey Kanıtlayan Felaket Kurtarma Testi Nasıl Yapılır?

Kısa cevap: Katman 1 sistemler için yılda en az iki kez, izole bir ağa kesintisiz devreye alma testi yapın; kurtarılan uygulamayı teknolojinin "sanal makineler açıldı" onayı değil, iş birimi kullanıcıları doğrulasın. Karar anından çalışan servise kadar geçen süreyi ölçün; gerçek RTO'nuz plandaki değil, o sayıdır.

Test edilmemiş planlar neden başarısız olur?

Rakamla başlayalım. Veeam'in 2025 fidye yazılımı araştırmasında saldırıya uğrayan kurumların yalnızca %10'u verisinin %90'ından fazlasını geri alabildi, %57'si yarısından azını kurtardı ve ortalama kurtarma 24,6 gün sürdü. Bu kurumların neredeyse hepsinin yedeği vardı. Eksik olan yedek değil, o yedekten dönüldüğünün kanıtıydı.

Hiç çalıştırılmamış bir kurtarma planı bir varsayımdır. Gerçek olaylarda ortaya çıkan hatalar egzotik değil, tutarlı biçimde sıradandır:

    Prosedürler artık var olmayan sunuculara, IP aralıklarına veya kişilere atıf yapar.Uygulama bağımlılıkları eksik haritalanmıştır; veritabanı kurtarılır, ona bağımlı servis kurtarılmaz.Mesai dışında felaket ilan etme yetkisi kimsede yoktur, ilk saat onay aramakla geçer.Yedekler başarılı raporlanmış ama hiç geri yüklenmemiştir.DNS ve sertifika değişiklikleri planın parçası değildir.

Bunların her biri testte ucuza, olayda pahalıya bulunur. PagerDuty'nin 2026 verisinde kesintinin ortalama dakika maliyeti 4.537 dolar; yani bir sabahını harcayan test, olay anında kaybedilecek yirmi dakikanın altında bir maliyet.

Prosedür

1. Senaryoyu tanımlayın. "Veri merkezi yok oldu" değil. Somut ve olası bir şey: bir depolama ünitesi arızası, pazar sabahı 02:00'de fidye yazılımı, tek bir kritik uygulamanın kaybı.

2. Başarı ölçütlerini önceden yazın. Bu senaryoda "kurtarıldı" ne demek, iş diliyle yazın. Örneğin: kullanıcı sipariş verebiliyor ve sipariş ERP'de doğru görünüyor.

3. Test ortamını izole edin. Hem Zerto hem Veeam izole ağa kurtarmayı destekler. Başlamadan önce izolasyonu doğrulayın; üretime sızan bir test, hiç test yapmamaktan kötüdür.

4. Saati karar anında başlatın, ilk komut yazıldığında değil. Onay süresi RTO'nun parçasıdır ve genellikle en uzun parçasıdır.

5. Ezbere değil prosedürden uygulayın. Prosedür, onu yazmamış biri tarafından takip edilemiyorsa prosedür değildir. Testi bilerek, sistemi en iyi bilen kişi olmadan yapın; gerçek olayda o kişinin telefonu açacağının garantisi yok.

6. Doğrulamayı iş birimi yapsın. teknolojinin makinelerin çalıştığını teyit etmesi çok az şey kanıtlar. Gerçek bir kullanıcıdan gerçek bir işlemi tamamlamasını isteyin.

7. Ters giden her şeyi kaydedin, sonra ayrıntılar tazeyken prosedürü aynı hafta düzeltin. Düzeltilmeyen bulgu, ikinci testte yeniden bulunur ve o zaman iki testi de boşa çıkarır.

Ne ölçülmeli

    Ölçülen RTO. Karardan çalışan servise. Hedefi nasıl belirleyeceğinizi RPO ve RTO nasıl hesaplanır yazısında anlattık.Ölçülen RPO. Kurtarma noktasında gerçekte ne kadar veri kaybedildi.Manuel adımlar. Her manuel adım gece 03:00'te bir hata noktasıdır.Bağımlılık boşlukları. Korunan grubun dışında kalan ve ihtiyaç duyulan her şey.Karar süresi. Toplam sürenin ne kadarı teknik iş, ne kadarı onay bekleme. Bu ikisi ayrılmazsa yanlış sorun optimize edilir.

Sıklık

    Katman 1: yılda en az iki kez, tam devreye alma.Katman 2: yılda bir.Katman 3: yılda bir örnekleme geri yükleme kontrolü genellikle yeterlidir.Ayrıca her önemli mimari değişiklikten sonra.

Masa başı tatbikatlar karar pratiği için yararlıdır ama teknolojiyi doğrulamaz. Gerçek devreye almanın yerini tutmazlar.

Geri dönüşü unutmayın

Ekipler devreye almayı prova eder, geri dönüşü (failback) ihmal eder; sonra gerçek olayda birincil lokasyona dönmenin oradan ayrılmaktan daha zor olduğunu keşfeder. Sebep basit: kurtarma merkezinde geçen sürede üretilen veri, geri dönerken birincil tarafa taşınmak zorunda ve bu ters yönde bir senkronizasyon gerektiriyor. İkisini de çalışın.

Sık sorulan sorular

Test üretimi etkiler mi? İzole ağda çalışıyorsa etkilemez; her iki büyük platform da bunu destekler. Önce izolasyonu doğrulayın.

Test ne kadar sürer? İlk Katman 1 testi için doğrulama ve değerlendirme dâhil yarım gün planlayın. Sonrakiler hızlanır.

Kimler katılmalı? Altyapı, uygulama sahipleri, en az bir iş birimi doğrulayıcısı ve olay ilan etme yetkisi olan biri. Bu yetkinin yazılı olup olmadığını incident escalation matrisi yazısındaki yedi satırla sınayabilirsiniz.

Test başarısız olursa? Bu, testin işe yaradığı anlamına gelir. Başarısız bir test bir sabaha mal olur; aynı hata olay anında çok daha fazlasına.

Kaynaklar