Şirketlerde felaket kurtarma tatbikatı (DR Drill) adımları: Gerçekçi senaryo testi, sistem geri yükleme süreleri ve kriz yönetimi kontrol listesi rehberi.
Hızlı Özet (TL;DR)
Test edilmemiş bir felaket kurtarma planı ve doğrulanmamış bir yedekleme mimarisi, sadece kâğıt üzerinde duran bir iyi niyet belgesidir. Felaket Kurtarma Tatbikatı (DR Drill); ana sunucuların çöktüğü, fidye yazılımının ağa yayıldığı, depolama ünitesinin (SAN/NAS) donanımsal arıza yaptığı veya sistem odasını su bastığı varsayılan senaryoların yılda en az iki kez kontrollü ve ölçülebilir şekilde canlandırılmasıdır. Bu tatbikatlar sayesinde yedek dosyalarının bozuk (corrupt) olup olmadığı, hedeflenen RTO ve RPO sürelerinin gerçekte kaç saat sürdüğü, şifre kasası erişimlerinin çalışıp çalışmadığı ve personelin kriz anında nasıl hareket edeceği uygulamalı olarak sınanır.
1. Neden Yedekleme Yazılımının “Yeşil Tik” Raporuna Güvenilmemelidir?
Birçok işletmede bilgi işlem sorumluları her sabah yedekleme yazılımından gelen “Backup Job Successful” e-postasını gördüğünde sistemin güvende olduğunu varsayar. Oysa gerçek felaket anlarında karşılaşılan acı tablo çok farklıdır:
- Sessiz Veri Bozulması (Silent Bit Rot) ve Eksik Bağımlılıklar: Sanal makine yedeği (VMDK/VHDX) başarıyla alınmış görünse de, veritabanı servisi o sırada bellekteki (RAM) işlemleri diske yazmamışsa (Application-Consistent Snapshot alınmamışsa) geri yüklenen SQL veritabanı “Suspect Mode” hatasıyla açılmaz.
- Unutulan Şifreleme Anahtarları ve Parolalar: Yedek arşivi güvenlik gereği AES-256 ile şifrelenmiştir; ancak şifreleme anahtarı (Decryption Key) yine çöken ana sunucunun içinde bırakıldığı için yedek dosyası açılamaz.
- Donanım ve Bant Genişliği Darboğazları: Kağıt üzerinde “1 saatte döneriz” denilen 8 TB’lık bir ERP ve dosya sunucusu yedeğinin, 1 Gbps’lik standart ağ kartı üzerinden geri kopyalanmasının matematiksel olarak en az 18-20 saat sürdüğü ancak tatbikat sırasında fark edilir.
2. Kurumlarda Uygulanan 4 Farklı Felaket Kurtarma Test Seviyesi
ISO 22301, TISAX ve BDDK/SPK bilgi sistemleri denetimlerinde kabul gören tatbikat türleri, operasyonel risk ve kapsam derinliğine göre dört kademeye ayrılır:
| Tatbikat Türü | Yapılış Biçimi ve Yöntemi | Canlı Operasyonel Risk | Test Edilen Temel Bileşen | Önerilen Sıklık |
|---|---|---|---|---|
| 1. Masaüstü İnceleme (Tabletop) | Kriz komitesinin ve BT ekibinin toplantı odasında senaryoyu adım adım tartışması | Sıfır risk (Canlı sistemlere dokunulmaz) | İletişim zinciri, karar alma yetki sınırları ve Runbook güncelliği | 3 ayda bir |
| 2. İzole Ağ Testi (Sandbox / Bubble) | Yedeklerin üretim ağından tamamen kopuk izole bir VLAN/vSwitch içinde açılması | Sıfır risk (Canlı üretim ve IP’ler etkilenmez) | Veritabanı tutarlılığı, önyükleme (Boot) başarısı ve gerçek RTO süresi | Ayda bir / Otomatik |
| 3. Paralel Test (Parallel Test) | Felaket kurtarma (DRC) ortamının ayağa kaldırılıp canlı iş yükü örnekleriyle sınanması | Çok düşük risk (Ana sistem çalışmaya devam eder) | Yedek sunucunun CPU/RAM/IOPS performansı ve entegrasyon servisleri | 6 ayda bir |
| 4. Tam Kesinti Testi (Full Cutover) | Ana sistemlerin fişinin çekilerek tüm şirket trafiğinin yedek merkeze aktarılması | Kontrollü ve planlı risk (Hafta sonu / vardiya dışı) | DNS/VPN yönlendirmeleri, uçtan uca tüm işletme dayanıklılığı ve Failback | Yılda 1 kez |
3. Adım Adım DR Tatbikatı Nasıl İcra Edilir?
Başarılı bir DR Drill, rastgele sunucu kapatmak değil; bilimsel bir deney titizliğiyle kronometre tutularak yürütülen mühendislik operasyonudur.
1. Senaryonun, Kapsamın ve Başarı Kriterlerinin Tanımlanması
Tatbikattan önce senaryo netleştirilir: “Cumartesi saat 22:00’de ana sanallaştırma kümesindeki depolama ünitesi tamamen devre dışı kaldı ve fidye yazılımı birincil yedekleri sildi.” Başarı kriteri (SLA) somut olarak yazılır: “WORM korumalı ikincil yedekleme havuzundan Active Directory, İmalat ERP Çözümleri veritabanı ve dosya sunucusunun maksimum 45 dakika (RTO) içinde ayağa kalkması ve en fazla 15 dakikalık (RPO) veri kaybıyla 5 departman temsilcisinin işlem yapabilmesi.”
2. İletişim Zincirinin ve Eskalasyonun İşletilmesi
Acil durum irtibat listesindeki (Call Tree) telefon numaralarının ve alternatif haberleşme kanallarının güncelliği test edilir. Nöbetçi mühendisin krizi fark etmesi, BT yöneticisine ulaşması, Kriz Komitesi Başkanından “Failover” onayı alması ve dış danışmanlara erişim süreleri kronometre ile dakika dakika kayıt altına alınır.
3. İzole Kurtarma, Bütünlük Doğrulama ve İş Mantığı Testi
Ortak Dosya Sunucusu ve Yedekleme havuzundaki en güncel değiştirilemez (Immutable) ZFS anlık görüntüsü, yedek sanallaştırma ana makinesine (Hypervisor) anında klonlanarak (Instant VM Recovery) bağlanır. Ancak sanal makinenin Windows veya Linux giriş ekranına gelmesi tatbikatın başarılı olduğu anlamına gelmez. Mutlaka şu üç doğrulama yapılır:
- Veritabanı Tutarlılık Kontrolü: MS SQL Server üzerinde
DBCC CHECKDBveya PostgreSQL üzerinde indeks/tablo doğrulama sorguları çalıştırılarak sayfa bozulması (page corruption) olmadığı kanıtlanır. - Uygulama ve Servis Bağımlılıkları: ERP yazılımının e-Fatura entegratörüne, el terminali RF servislerine ve aktif dizine (LDAP) sorunsuz bağlandığı doğrulanır.
- Son Kullanıcı Kabul Testi (UAT): Muhasebe ve üretim planlama sorumluları test ortamına bağlanarak kesintiden hemen önce girilmiş son irsaliyeyi, reçeteyi ve mizan bakiyesini bizzat kontrol eder.
4. Geri Dönüş (Failback) ve Senkronizasyon
Tam kesinti (Cutover) tatbikatlarında sistemleri yedek merkeze geçirmek (Failover) işin yalnızca yarısıdır; asıl zorluk tatbikat bittiğinde yedek sistemde oluşan yeni verileri kayıpsız şekilde tekrar ana sunuculara eşitleyip (Failback / Re-protection) normal düzene dönmektir. Tatbikat planında Failback adımları en az Failover kadar detaylı yer almalıdır.
4. Tatbikat Sonrası Değerlendirme Raporu (Post-Mortem) ve Denetim Kanıtları
Tatbikat tamamlanır tamamlanmaz tüm ekip toplanarak objektif bir değerlendirme (After-Action Review) yapar ve aşağıdaki soruları resmi rapora bağlar:
- Hedeflenen RTO (örneğin 60 dakika) süresi aşıldı mı? Eğer 110 dakika sürdüyse hangi adımda (ağ yönlendirmesi, disk bağlama, parola arama) vakit kaybedildi?
- Şifre kasası (Password Vault) veya yedekleme sunucusu 2FA erişim anahtarları çevrimdışı ortamda hazır mıydı?
- Savunma Sanayii ve İmalat Siber Güvenlik standartları kapsamında güvenlik duvarı kuralları yedek sunucu IP bloklarıyla uyumlu çalıştı mı?
Hazırlanan bu imzalı rapor, ekran görüntüleri ve log çıktılarıyla birlikte arşivlenir; ISO 27001, ISO 22301 ve müşteri tedarikçi denetimlerinde en güçlü uyumluluk kanıtı olarak sunulur. Kurumsal iş sürekliliği, yedekleme mimarisi ve felaket tatbikatı danışmanlığı için Ortak Dosya Sunucusu ve Yedekleme ve siber saldırı simülasyonları için Sızma Testi ve Pentest sayfalarımızı inceleyebilirsiniz.
Sıkça Sorulan Sorular
Felaket kurtarma tatbikatı yaparken canlı üretimdeki verilerin zarar görme veya silinme riski var mıdır?
Doğru kurgulanmış bir İzole Ağ Testinde (Sandbox / Bubble Test) canlı sistemlere ve üretim veritabanlarına kesinlikle dokunulmaz. Yedekleme sunucusu üzerindeki anlık görüntü (Snapshot) klonlanarak fiziksel ağdan tamamen izole edilmiş sanal bir switch (vSwitch) üzerinde başlatılır; bu sayede canlı sunucuyla IP veya isim çakışması yaşanmadan %100 güvenli bir şekilde kurtarma testi gerçekleştirilir.
Büyük boyutlu (örneğin 10 TB üzeri) veritabanlarını ve dosya sunucularını dakikalar içinde geri yüklemek nasıl mümkün olur?
Geleneksel yedeklemede 10 TB veriyi yedek sunucudan ana sunucuya ağ üzerinden kopyalamaya çalışırsanız saatler kaybedersiniz. Bunun yerine ZFS tabanlı yeni nesil depolama ve Instant Recovery (Anında Kurtarma) teknolojisi kullanılır; yedek imajı kopyalanmadan doğrudan yedekleme ünitesinin kendi NVMe/SSD önbelleği üzerinden Hypervisor’e (ESXi/Proxmox) bir veri deposu (Datastore) olarak bağlanır ve sanal sunucu 2-3 dakika içinde doğrudan yedek ünitesi üzerinde çalışmaya başlar, arka planda ise canlı taşıma (Storage vMotion) sessizce tamamlanır.
Habersiz (Unannounced) DR tatbikatı yapmak doğru bir yöntem midir?
Olgunluk seviyesi yüksek kurumlarda yılda bir kez habersiz masaüstü veya izole geri yükleme tatbikatı yapmak, ekibin gerçek hazırlık seviyesini görmek açısından çok değerlidir. Ancak ilk kez DR tatbikatı yapacak şirketlerin mutlaka planlı ve haberli masaüstü/sandbox testleriyle başlaması, Runbook dokümanındaki eksikleri giderdikten sonra habersiz kriz simülasyonlarına geçmesi önerilir.