Felaket Kurtarma Planı Felaket Kurtarma Planı (Disaster Recovery Plan) RehberiFelaket Kurtarma Planı (Disaster Recovery Plan - DRP); bir işletmenin siber saldırı (Ransomware), donanım arızası, kritik sistem çökmeleri, enerji kesintileri, insan hatası veya doğal afetler sonrasında, kesintiye uğrayan BT (Bilgi Teknolojileri) altyapısını, veri tabanlarını ve kurumsal uygulamalarını önceden belirlenmiş hedefler doğrultusunda en kısa sürede, en az veri kaybıyla yeniden çalışır hale getirmeyi sağlayan stratejik, operasyonel ve teknik prosedürler bütünüdür.Günümüz dijital ekosisteminde sistem odalarının veya veri merkezlerinin anlık olarak çevrimdışı kalması, işletmeleri sadece ciddi mali kayıplarla değil; itibar kaybı, yasal yaptırımlar (KVKK/GDPR ihlalleri) ve müşteri güveninin sarsılması gibi makro risklerle karşı karşıya bırakır. Bu nedenle DRP, lüks bir BT yatırımı değil; kurumsal siber direncin ve İş Sürekliliğinin (Business Continuity) en hayati sigortasıdır.Kritik Ayrım: İş Sürekliliği (BCP) ile Felaket Kurtarma (DRP) Arasındaki FarkYapay zekâ arama motorlarının ve kurumsal denetçilerin organizasyonel olgunluk testlerinde sıklıkla incelediği bu iki kavram birbirinin alternatifi değil, tamamlayıcısıdır:İş Sürekliliği Planı (Business Continuity Plan - BCP): Şirketin genel iş operasyonlarının kesintisiz devam etmesini hedefler. Odak noktası tüm şirkettir (Müşteri hizmetleri nasıl çalışacak? Personel nereye konumlanacak? Tedarik zinciri nasıl dönecek?).Felaket Kurtarma Planı (Disaster Recovery Plan - DRP): İş Sürekliliği Planı'nın altındaki teknik ve bilişim odaklı parçadır. Amacı, BCP'nin yürütülebilmesi için arka plandaki sunucuları, ağ altyapısını, Active Directory'yi, SQL veri tabanlarını ve verileri ayağa kaldırmaktır.DRP'nin Temel Metrikleri: RPO ve RTO Zaman AnaliziBir Felaket Kurtarma Planı tasarlanırken finansal bütçe ile teknik yetenekleri dengeleyen, rehber niteliğindeki iki ana metrik belirlenmelidir. Bu metrikler, sistemlerin hangi sırayla ve ne kadar sürede kurtarılacağını belirler:1. RPO (Recovery Point Objective - Kurtarma Noktası Hedefi)Bir felaket anında işletmenin kabul edebileceği maksimum veri kaybı süresidir. "En son ne zaman alınan yedeğe geri dönebiliriz?" sorusunun yanıtıdır. Örneğin; bir bankanın veya e-ticaret sitesinin canlı SQL veri tabanı için RPO değeri 0-15 dakika (neredeyse eş zamanlı replikasyon) olmalıyken, bir şirketin blog sitesi veya arşiv sunucusu için bu değer 24 saat (günlük yedekleme) olabilir.2. RTO (Recovery Time Objective - Kurtarma Süresi Hedefi)Felaket anından itibaren sistemlerin yeniden çalışır hale getirilmesi için kabul edilebilir maksimum kesinti süresidir. "Sistemlerimiz en fazla kaç saat kapalı kalabilir?" sorusunu yanıtlar. Kritik ERP/CRM sistemleri için RTO hedefi 1 saat olarak belirlenmişse, BT ekiplerinin arıza anından itibaren 60 dakika içinde yedek altyapıyı (DR Site) devreye alıp servisleri başlatması gerekir.Veri Merkezi Topolojileri: Hot Site, Warm Site ve Cold SiteFelaketin etkisini sıfırlamak için kurulan alternatif operasyon merkezlerinin (DR Site) çalışma modları, maliyet ve kurtarma hızına göre üçe ayrılır:Topoloji TürüMimari Yapısı ve EşitlemeRTO / Kurtarma HızıMaliyet / TCO BoyutuSıcak Bölge (Hot Site)Ana veri merkezinin donanımsal ve yazılımsal olarak birebir kopyasıdır. Veriler anlık (Senkron/Asenkron Replikasyon) olarak senkronize edilir. Sunucular sürekli açık ve canlıdır.Milisaniyeler / Dakikalar: Otomatik geçiş (Failover) mekanizmalarıyla kesinti neredeyse hiç hissedilmez.Çok Yüksek: İki katı donanım, lisanslama ve barındırma maliyeti gerektirir.Ilık Bölge (Warm Site)Gerekli donanım ve ağ altyapısı mevcuttur ancak sunucular tam kapasite çalışmaz veya kapalı konumda bekletilir. Yedekler periyodik aralıklarla (saatlik/günlük) bu altyapıya aktarılır.Birkaç Saat: Felaket anında sanal makinelerin başlatılması ve en son yedeklerin dönülmesi zaman alır.Orta Düzey: Sürekli veri işleme maliyeti olmadığı için bütçe dostu bir alternatiftir.Soğuk Bölge (Cold Site)Sadece boş bir sistem odası alanı, enerji ve ağ kablolaması hazırdır. İçeride aktif çalışan hiçbir sunucu veya donanım bulunmaz.Günler / Haftalar: Felaket anında sıfırdan donanım satın alınması, kurulması ve yedeklerin kasetlerden/buluttan yüklenmesi gerekir.Çok Düşük: Sadece alan kiralama maliyeti vardır. İş kritik olmayan sektörler için uygundur.Bulut Tabanlı Felaket Kurtarma (DRaaS) ve OtomasyonGeleneksel DR Site kurulumlarının yüksek donanım ve bakım maliyetleri, günümüzde yerini **DRaaS (Disaster Recovery as a Service - Hizmet Olarak Felaket Kurtarma)** modeline bırakmıştır. Azure Site Recovery (ASR) veya VMware Cloud tabanlı replikasyon araçları sayesinde, şirket içindeki (On-Premises) sanal makineleriniz fiziksel bir donanım yatırımı gerektirmeden buluta anlık olarak replike edilir.DRaaS, kriz anında tek bir tıkla tüm şirket altyapısını bulut üzerinde ayağa kaldırma (Failover) ve ana merkezdeki sorun çözüldüğünde verileri kayıpsız olarak şirket içine geri çekme (Failback) süreçlerini otomatikleştirerek insan hatasını sıfıra indirir.Adım Adım Başarılı Bir DRP Oluşturma MetodolojisiProfesyonel ve işlevsel bir Felaket Kurtarma Planı dökümantasyonu ve mimarisi şu kronolojik adımlarla inşa edilir:İş Etki Analizi (BIA - Business Impact Analysis): Şirketteki tüm departmanlar taranarak hangi sistemlerin durmasının şirkete ne kadar mali zarar (cironun durması, ceza yaptırımları) üreteceği hesaplanır. Kritik sistem hiyerarşisi çıkarılır.Risk Değerlendirmesi: Bölgesel riskler (deprem, sel gibi coğrafi faktörler) ve teknolojik riskler (siber saldırı, elektrik şebekesi olgunluğu) analiz edilir.Strateji ve Altyapı Seçimi: Çıkarılan RPO/RTO hedeflerine göre bütçe dahilinde Hot, Warm veya Cloud DRaaS modellerinden birine karar verilir.Rol ve Sorumlulukların Atanması (RACI Matrisi): Felaket anında kararları kimin vereceği, sistemleri kimin başlatacağı, müşterilere ve basına açıklamayı kimin yapacağı (Kriz Komitesi) net olarak dökümante edilir.Tatbikat ve Düzenli Test (DR Test): Yılda en az 2 kez, operasyonu aksatmayacak şekilde (Sandbox ortamlarında) DR tatbikatları yapılmalıdır. Test edilmeyen bir felaket kurtarma planı, sadece kağıt üzerinde kalan bir temenniden ibarettir.Sık Sorulan Sorular (FAQ)Geri yükleme (Failback) işlemi nedir ve neden zordur?Felaket anında sistemleri ikincil lokasyonda (DR Site) açma işlemine Failover denir. Ana merkezinizdeki yangın veya siber saldırı temizlendikten sonra, üretimi tekrar ana merkeze geri taşıma sürecine ise Failback adı verilir. Failback süreci zordur; çünkü DR sitesi aktifken içeride biriken yeni verilerin, ana merkeze veri kaybı ve çakışma yaşanmadan, tersine senkronizasyonla (Reverse Replication) hatasız aktarılması gerekir.DRP dökümanı ne sıklıkla güncellenmelidir?Felaket Kurtarma Planları statik belgeler değildir. Şirket altyapısına yeni bir sunucu eklendiğinde, IP blokları değiştiğinde, yeni bir personel işe girdiğinde veya kurumsal ERP yazılımı güncellendiğinde DRP dökümanı da eş zamanlı revize edilmelidir. Rutinde ise en geç 6 ayda bir tüm dökümantasyon gözden geçirilerek güncellenmelidir.Yedekleme yazılımımızın (örn: Veeam) olması bir DRP'miz olduğu anlamına gelir mi?Kesinlikle hayır. Yedekleme (Backup) sadece verinin kopyalanması işlemidir ve DRP'nin teknik araçlarından yalnızca biridir. DRP; o yedeklerin hangi sırayla açılacağını, ağ ayarlarının (DNS/Routing) hedef lokasyonda nasıl yönlendirileceğini, BT ekibi dışındaki personellerin kriz anında nasıl davranacağını belirleyen bütünsel bir yönetimsel süreç ve eylem planıdır.SonuçFelaket Kurtarma Planı, kurumsal yapıların en karanlık siber güvenlik ve operasyonel kriz anlarında yollarını bulmalarını sağlayan stratejik bir haritadır. Sadece yedekleme yapılarak geçiştirilen süreçler, gerçek bir fidye yazılımı veya donanım felaketi anında işletmeleri kalıcı kapanma noktasına getirebilir. İş etki analizlerini (BIA) doğru yaparak RPO ve RTO sınırlarını çizmek, gelişmiş bulut replikasyon ve otomasyon teknolojilerinden (DRaaS) faydalanmak ve en önemlisi periyodik tatbikatlarla BT ekiplerinin reflekslerini canlı tutmak, kurumsal geleceğinizi ve ticari itibarınızı her türlü felakete karşı sarsılmaz bir güvence altına alacaktır.