Felaket kurtarma planı genellikle bir kez yazılır, bir klasöre konur ve unutulur. Sonra bir gün sistem odasında su baskını olur, plan açılır ve ilk adımda takılınır: yedek lokasyondaki sunucunun yönetici parolasını kimse bilmez, VPN bağlantısı çalışmaz, veritabanı açılır ama uygulama bağlanmaz. Bu sorunların hepsi bir testte ortaya çıkabilirdi. Felaket kurtarma testi, planın kâğıt üzerinde değil gerçekte çalıştığını gösteren tek yoldur. Bu yazıda test türlerini, bir testin nasıl hazırlanıp yürütüleceğini ve sonrasında ne yapılması gerektiğini anlatıyoruz. Planın kendisi için felaket kurtarma sayfamıza bakabilirsiniz.
Neden test etmelisiniz?
Bir felaket kurtarma planı; teknik altyapıya, belgelere ve insanlara dayanır. Üçü de zamanla değişir. Yeni bir sunucu eklenir ama replikasyona dahil edilmez. Güvenlik duvarı kuralları güncellenir ama yedek lokasyona taşınmaz. Planı yazan kişi şirketten ayrılır. Test, bu kaymaları felaket gelmeden yakalar.
Testin ikinci amacı ölçmektir. RTO ve RPO hedefleri kâğıt üzerinde bir anlam taşır; gerçek geri dönüş süresini yalnızca test gösterir. Dört saatlik bir hedefin karşısında altı saat süren bir test sonucu, ya yöntemin değişmesi ya da hedefin iş birimleriyle yeniden konuşulması gerektiğini söyler.
Test türleri
Her test tüm sistemi durdurmayı gerektirmez. Basitten kapsamlıya doğru şu türler kullanılır:
Belge incelemesi
Plan baştan sona okunur. Telefon numaraları, sistem listesi, parola kasasındaki kayıtlar ve bağımlılıklar güncel mi diye kontrol edilir. En az emek isteyen, ama en çok eksik bulan adımlardan biridir.
Masa başı tatbikat
NIST’in test ve tatbikat rehberi SP 800-84, masa başı tatbikatı (tabletop exercise) şöyle tanımlar: Plandaki rol ve sorumlulukları olan kişilerin bir araya gelip belirli bir acil durum senaryosunda neler yapacaklarını konuşarak planın içeriğini doğruladığı, tartışmaya dayalı tatbikat. Bir kolaylaştırıcı senaryoyu sunar ve sorular sorar: “Saat 09.00, ERP sunucusu açılmıyor. İlk kim fark eder? Kimi arar? Yük devretme kararını kim verir?” Hiçbir sisteme dokunulmaz, ama iletişim ve karar boşlukları görünür hâle gelir.
Bileşen testi
Tek bir sistem ya da tek bir adım test edilir: bir sunucunun yedekten geri yüklenmesi, bir veritabanının yedek lokasyonda açılması ya da VPN bağlantısının kurulması. Yedeklerin otomatik olarak test edilmesi bu türün bir parçasıdır. Veeam ile bunun nasıl yapıldığını SureBackup ile yedek testi yazımızda anlattık.
Yalıtılmış yük devretme testi
NIST SP 800-84’ün işlevsel tatbikat olarak tanımladığı türe yakındır: Kişiler planı simüle edilmiş bir operasyon ortamında uygular. Kritik sistemler yedek lokasyonda, canlı ağdan yalıtılmış bir ağda açılır; uygulamaların çalıştığı ve verinin güncel olduğu kontrol edilir. Canlı sistem çalışmaya devam eder. OpenText Availability ve StorageCraft ShadowProtect gibi çözümler bu tür testleri üretimi durdurmadan yapmaya imkân verir.
Tam yük devretme
Üretim gerçekten yedek lokasyona taşınır, kullanıcılar bir süre oradan çalışır ve ardından ana lokasyona geri dönülür. En gerçekçi testtir, ama risk de taşır. Genellikle önceki test türleri sorunsuz geçtikten sonra, planlı bir bakım penceresinde yapılır.
Test öncesi hazırlık
- Kapsamı belirleyin. Hangi sistemler test edilecek, hangi senaryo kullanılacak? Tüm sistemi tek seferde test etmek yerine kritik bir iş sürecini seçmek daha yönetilebilirdir.
- Başarı ölçütünü önceden yazın. “Sistem açıldı” yeterli değildir. Örneğin: “ERP 4 saat içinde yedek lokasyonda açılır, son 15 dakikanın verisi eksiksizdir, üç kullanıcı sipariş girebilir.”
- Rolleri atayın. Testi yöneten, adımları uygulayan, süreyi ölçen ve not tutan kişiler belli olsun.
- Canlı sistemi koruyun. Yalıtılmış ağ kullanın; test edilen kopyanın üretim ağına, e-posta sunucusuna ya da dış sistemlere erişmediğinden emin olun.
- Geri çekilme planı hazırlayın. Bir şey ters giderse testin nasıl durdurulacağı önceden bilinmelidir.
- İlgilileri bilgilendirin. Özellikle tam yük devretmede kullanıcılar ve iş birimleri test saatini bilmelidir.
Test sırasında
Testi planda yazıldığı gibi uygulayın. Planı yazan kişinin değil, felaket anında işi yapacak kişinin uygulaması daha gerçekçi sonuç verir. Her adımın başlangıç ve bitiş saatini kaydedin: arızanın fark edilmesi, kararın verilmesi, sistemlerin açılması, uygulamanın kontrolü ve kullanıcıların bağlanması. Planda yazmayan her müdahaleyi not edin; bunlar planın eksikleridir.
Kontrol edilmesi sık unutulan noktalar:
- Kullanıcılar yedek lokasyondaki sistemlere gerçekten bağlanabiliyor mu? DNS ve güvenlik duvarı kuralları hazır mı?
- Uygulama lisansları farklı bir donanımda ya da sanal makinede çalışıyor mu?
- Yönetici hesaplarına ve parolalara, ana lokasyon yokken ulaşılabiliyor mu?
- Veri gerçekten hedeflenen RPO kadar güncel mi?
Test sonrası: rapor ve düzeltme
Test, raporuyla değer kazanır. Kısa bir rapor şu başlıkları içermelidir:
| Başlık | İçerik |
|---|---|
| Kapsam ve senaryo | Hangi sistemler, hangi senaryoyla test edildi? |
| Ölçülen süreler | Adım adım süreler ve hedeflerle karşılaştırma |
| Bulunan sorunlar | Plandaki eksikler, teknik hatalar, iletişim boşlukları |
| Aksiyonlar | Her sorun için sorumlu kişi ve tarih |
| Güncellenen belgeler | Plandaki değişikliklerin listesi |
Bulunan sorunlar giderildikten sonra plan güncellenir ve gerekirse ilgili adım yeniden test edilir.
Sık görülen test bulguları
İlk testlerde karşılaştığımız sorunlar çoğu zaman teknik değil, küçük ve gözden kaçmış ayrıntılardır:
- Yedek lokasyondaki sunucuların yerel yönetici parolaları hiçbir yerde kayıtlı değil.
- Uygulama, veritabanı sunucusuna IP adresiyle bağlanıyor; yeni lokasyonda adres değiştiği için bağlantı kurulamıyor.
- Planda yazan telefon numaralarından biri, iki yıl önce ayrılmış bir çalışana ait.
- Replikasyona son altı ayda eklenen bir sunucu dahil edilmemiş.
- Lisans sunucusu yalnızca ana lokasyondaki donanıma bağlı olduğu için uygulama açılmıyor.
- Yük devretme kararını kimin vereceği yazılı değil; herkes birbirini bekliyor.
Bu bulguların hiçbiri gerçek bir felakette kabul edilebilir değildir; ama bir testte bulunduklarında bir öğleden sonrada giderilebilirler.
Ne sıklıkla test etmeli?
Herkes için geçerli tek bir sıklık yoktur; sistemin kritikliğine ve değişim hızına bağlıdır. Pratikte işe yarayan bir düzen şöyledir: yedeklerin otomatik doğrulaması sürekli, kritik sistemlerin bileşen testleri üç ayda bir, masa başı tatbikat ve yalıtılmış yük devretme yılda en az bir kez. Ayrıca büyük bir değişiklikten sonra, örneğin yeni bir ERP’ye geçişte, sanallaştırma platformu değişikliğinde ya da lokasyon taşımasında test tekrarlanmalıdır. Testin iş tarafındaki karşılığını iş sürekliliği planı yazımızda anlattık.
Unna ile felaket kurtarma testi
- Önce dinleriz. Mevcut planınızı ve altyapınızı inceler, hangi sistemlerin hangi test türüyle doğrulanacağını birlikte belirleriz.
- Birlikte planlarız. Senaryoyu, başarı ölçütlerini, rolleri ve yalıtılmış test ortamını hazırlarız.
- Testi birlikte yürütürüz. Adımları sizinle uygular, süreleri ölçer, raporu ve aksiyon listesini hazırlarız.
- Yanınızda kalırız. Bulunan sorunları giderir, planı günceller, testleri düzenli aralıklarla tekrarlarız.
Henüz bir planınız yoksa önce yedekleme ile felaket kurtarma arasındaki farka göz atabilir, yedekleme yapınızı gözden geçirebilir ya da bize ulaşabilirsiniz.
