Özet: Disaster recovery (DR), bir veri merkezi felaketi, siber saldırı veya insan hatası sonrası BT sistemlerini ve verileri tanımlanmış RTO/RPO hedefleri içinde tekrar ayağa kaldıran sistemli plandır. Yedekleme verinin kopyasıdır; DR ise sistemlerin, süreçlerin ve insanların koordinasyonunu kapsayan bütünleşik bir disiplindir. DRaaS modeli ilk yatırım yapmadan ikincil bir veri merkezine erişim sağladığı için kurumlar için ekonomik ve operasyonel olarak avantajlıdır.
Ana noktalar:
- DR ile yedekleme aynı şey değildir; yedek bir veri kopyasıdır, DR ise sistemleri ayağa kaldıran bütünsel plandır.
- RPO, kabul edilebilir veri kaybı süresini; RTO, kabul edilebilir kesinti süresini ifade eder.
- Ransomware'e karşı yalnızca replikasyon yetmez; immutable backup ile birlikte kullanılmalıdır.
- DR planı yılda en az bir kez ve her büyük altyapı değişikliği sonrasında güncellenmelidir.
- Bulut sağlayıcının yedekli mimari sunması, coğrafi olarak ayrı bir DR sitesi ihtiyacını ortadan kaldırmaz.
Bir veri merkezi yangını, hedefli bir ransomware saldırısı veya basit bir insan hatası — bunlardan biri yarın gerçekleşse, şirketiniz iş operasyonlarını kaç saat içinde tekrar ayağa kaldırabilirdi? Çoğu organizasyonun cevabı net değildir; çünkü disaster recovery (felaket kurtarma) planları çoğunlukla "yedek alıyoruz" diye basitleştirilen, ancak gerçek olay anında ciddi açıklar veren süreçlerdir. KVKK kapsamında zorunlu önlemlerin, BDDK gereksinimlerinin ve müşteri güveninin kesişiminde DR artık bir IT konusu değil, bir iş sürekliliği konusudur.
Bu rehber, CIO'lar, CISO'lar, BT yöneticileri ve iş sürekliliği sorumluları için yazıldı. RPO ve RTO metriklerinden DR stratejilerine, BIA'dan tatbikat planlamasına ve Türkiye'ye özel sismik bölge ile BDDK gereksinimlerine kadar tam bir uygulama yol haritası sunuyoruz. Amaç tehdit yaratmak değil, gerçek bir DR programının nasıl kurulduğunu somut adımlarla göstermektir.
Sonunda, kendi şirketinizin RPO/RTO hedeflerini belirleyebilecek, DRaaS'ı klasik DR yaklaşımıyla karşılaştırabilecek ve denetimde gösterilecek dokümantasyonun iskeletini çıkarabilecek bilgiye sahip olacaksınız.
ISO 22301 iş sürekliliği yönetim sistemi standardı, kurumsal DR planlarının uluslararası referans çerçevesidir (kaynak).
Disaster recovery (felaket kurtarma) nedir?
Disaster recovery, bir felaket sonrası BT sistemlerinin ve verilerin önceden tanımlanmış bir süre içinde geri yüklenmesini sağlayan stratejilerin, prosedürlerin ve teknolojilerin tamamıdır.
DR vs. Backup farkı
Yedek (backup) verinin kopyasını almak demektir; DR ise tüm iş sistemlerini operasyonel olarak ayağa kaldırmaktır. Yedek aldığınız 2 TB veriyi geri yüklemek günler sürebilir; DR planı bu süreyi saatler veya dakikalara indirmek üzere tasarlanır. Yedek DR'ın bir bileşenidir; DR'ı tek başına temsil etmez.
DR vs. Business Continuity Plan (BCP)
Business Continuity Plan (BCP), iş süreçlerinin felaket sırasında ve sonrasında devam etmesini sağlayan üst düzey strateji. DR ise BCP'nin teknoloji boyutuna odaklı alt kümesidir. BCP "müşteri sipariş alma süreci nasıl devam edecek?" sorusuna; DR "sipariş yönetim sistemi sunucusu nasıl ayağa kalkacak?" sorusuna cevap verir.
Neden her şirketin DR planı olmalı?
KVKK, ISO 27001, BDDK ve PCI-DSS gibi düzenleyici çerçeveler DR planını şart koşar. Müşteri sözleşmelerinde SLA garantisi de DR'ı zorunlu kılar. En önemlisi, DR planı olmayan şirketlerin büyük bir kısmı ciddi bir felaket sonrası ayağa kalkamaz; istatistikler, yedeği olmayan KOBİ'lerin önemli bir yüzdesinin bir kriz sonrası tamamen kapandığını gösteriyor.
DR'a yol açan tehdit türleri
DR planı hangi tehditlere karşı hazırlanır?
Doğal afetler (deprem, sel, yangın)
Türkiye, kuzey Anadolu fay hattı üzerinde bulunması nedeniyle ciddi sismik risk altında. İstanbul'daki olası bir büyük deprem senaryosu, tek bir veri merkezine bağımlı tüm iş yüklerini etkileyebilir. Sel, yangın ve fırtına da fiziksel altyapıyı tehdit eden ana doğal afetler.
Siber saldırılar ve ransomware
Son yıllarda ransomware (fidye yazılımı) saldırıları kurumsal DR planlarının en yoğun gerekçesi haline geldi. Saldırgan üretim verilerini şifreler ve fidye ister; etkili bir DR planı, immutable backup ile şifrelenemeyen yedek üzerinden 24 saat içinde yeniden ayağa kalkmayı mümkün kılar.
Donanım arızaları ve elektrik kesintileri
Disk arızası, RAID controller hatası, ağ ekipmanı arızası ve elektrik kesintileri DR'ı tetikleyen rutin nedenler. Tek bir veri merkezine bağımlı altyapılar için bu tür "küçük" olaylar bile saatler süren kesinti anlamına gelebilir.
İnsan kaynaklı hatalar
DR olaylarının önemli bir oranı kasıtlı saldırıdan değil, yanlış komut, eksik konfigürasyon veya yetkili bir kullanıcının dikkatsiz silme işleminden doğar. "Production veritabanını yanlışlıkla DROP ettim" senaryosu, deneyimli ekiplerin bile karşılaştığı bir durum.
RPO ve RTO: temel metrikler
DR planının iki temel metriği olmadan ne sözleşme ne de teknik tasarım yapılamaz.
RPO (Recovery Point Objective) nedir?
RPO, felaket sonrası kabul edilebilir maksimum veri kaybı süresidir. Saat 14:00'te olay olduysa ve RPO'nuz 1 saatse, kaybedebileceğiniz veri sadece son 1 saatlik veri olmalıdır; yedek frekansınız RPO ile uyumlu olmak zorundadır.
RTO (Recovery Time Objective) nedir?
RTO, felaket sonrası sistemlerin yeniden operasyonel hale gelmesi için kabul edilebilir maksimum süredir. Olay saat 14:00'teyse ve RTO'nuz 4 saatse, sistem en geç saat 18:00'de tekrar çalışıyor olmalıdır.
İş süreçlerine göre RPO/RTO hesaplama
| Süreç tipi | Tipik RPO | Tipik RTO |
|---|---|---|
| Çekirdek bankacılık | Saniyeler | Dakikalar |
| E-ticaret satış | Dakikalar | 1 saat |
| Kurumsal CRM | 1 saat | 4 saat |
| İç paylaşımlı dosya | 24 saat | 24-48 saat |
| Arşiv / yasal kayıt | 24 saat | 72 saat+ |
Bu rakamlar örnek niteliğindedir; gerçek değerleri Business Impact Analysis (BIA) belirler.
Maliyet vs. kurtarma süresi dengesi
RPO ve RTO ne kadar düşükse, gereken altyapı maliyeti üstel olarak artar. RPO=0 (sıfır veri kaybı) sürekli synchronous replication ister; RTO=0 (sıfır kesinti) aktif-aktif çok bölgeli altyapı gerektirir. İş için kritik olmayan sistemlerde gereksiz düşük RPO/RTO hedefleri belirlemek, bütçeyi boş yere yakar.
Disaster recovery stratejileri (4 seviye)
Endüstride dört temel DR seviyesi vardır.
Backup & Restore (en düşük maliyet)
Yedek alır, felaket sonrası boş bir altyapıya geri yüklersiniz. RPO genelde 24 saat, RTO 24-72 saat aralığındadır. En ekonomik, en yavaş seçenek. Düşük kritiklikli iş yükleri için uygundur.
Pilot Light
İkincil sitede yalnızca temel kritik bileşenler (veritabanı, kimlik servisleri) sürekli çalışır; uygulama katmanı felaket anında ayağa kalkar. RPO dakikalar, RTO 1-4 saat. Orta maliyet, dengeli seçenek.
Warm Standby
İkincil sitede sistemlerin tamamı küçültülmüş ölçekte ayakta tutulur; failover anında ölçeklenir. RPO dakikalar, RTO 30-60 dakika. Üst orta maliyet, üst orta hız.
Multi-site Active-Active
Birden fazla site eşit yükle aktif olarak hizmet verir; bir site düşse trafiği diğeri devralır. RPO sıfıra yakın, RTO sıfıra yakın. En yüksek maliyet, en yüksek dayanıklılık. Bankacılık, kritik telekom altyapısı için uygun.
Bu modeli desteklemek için uygulama mimarisi stateless olmalı veya state, dağıtık veritabanı (Cassandra, CockroachDB) ya da çoklu bölgeli replikasyonlu RDBMS ile yönetilmelidir. Aktif-aktif mimari yalnızca DR değil, performansı kullanıcıya coğrafi olarak yakınlaştırma faydası da sağlar.
DRaaS (Disaster Recovery as a Service) nedir?
DRaaS, klasik kurum içi DR yatırımının yerini alan bir bulut servis modelidir.
Geleneksel DR vs. DRaaS karşılaştırması
| Boyut | Geleneksel DR | DRaaS |
|---|---|---|
| İlk yatırım | Çok yüksek | Yok |
| Aylık maliyet | Düşük | Orta |
| RPO/RTO esnekliği | Yüksek ama maliyetli | Hazır paketler |
| Yönetim eforu | Yüksek | Minimum |
| Tatbikat kolaylığı | Kompleks | Tek tıkla |
DRaaS bileşenleri ve teknolojileri (Veeam, Zerto)
Veeam Cloud Connect, Zerto IT Resilience Platform ve Acronis Cyber Protect, DRaaS sağlayıcılarının yaygın olarak kullandığı yazılımlar. Sürekli veri replikasyonu (CDR), uygulama uyumlu yedek, ve hipervizör uyumlu (VMware, Hyper-V) failover sunarlar.
DRaaS hangi şirketler için uygun?
İkincil bir veri merkezi yatırımı yapmak istemeyen, ancak hızlı RTO/RPO isteyen orta ölçek şirketler için DRaaS doğru seçim. Aynı zamanda KOBİ'ler için, kendi DR uzmanlığı olmadan kurumsal düzeyde koruma sağlar.
Disaster recovery planı nasıl hazırlanır?
Etkili bir DR planı beş aşamalı bir süreçtir.
Business Impact Analysis (BIA)
Hangi iş süreçleri kritik? Bir saatlik kesinti gelirinizi ne kadar etkiler? BIA, her iş sürecinin kesinti maliyetini, RPO/RTO toleransını ve önceliklendirmesini ortaya çıkarır. DR planlamasının temel girdisidir.
Risk değerlendirmesi
BIA hangi sistemlerin korunması gerektiğini söyler; risk değerlendirmesi hangi tehditlere karşı korunmaları gerektiğini ortaya koyar. Tehdit olasılığı x etki matrisi ile risk skoru hesaplanır, kritik riskler için kontrol önlemleri tanımlanır.
Roller ve sorumluluklar (RACI)
DR olayı anında kim hangi karar yetkisine sahip? Kim hangi adımı yürütür? RACI (Responsible, Accountable, Consulted, Informed) matrisi bu sorumlulukları kayıt altına alır. Olay anında "kim ne yapacak?" sorusu yaşanmamalıdır.
Runbook ve iletişim planı
Runbook, DR olayında adım adım izlenecek prosedürleri içeren kılavuzdur: "X sistemi düştüyse, önce Y kontrol et, sonra Z komutu çalıştır." Aynı zamanda iletişim planı (müşteri, çalışan, regülatör bilgilendirme) olay anında kritik olur.
DR plan şablonu (indirilebilir)
Tipik bir DR plan şablonu şu bölümleri içerir: kapsam, RPO/RTO hedefleri, sistem envanteri, BIA, risk matrisi, RACI, prosedürler (runbook), iletişim planı, tatbikat takvimi, plan gözden geçirme tarihi. Bu şablonun şirket büyüklüğüne göre uyarlanmış sürümlerini Cloud4U Türkiye gibi yerel DR sağlayıcıları ücretsiz paylaşır.
DR testleri: planınızın çalıştığından nasıl emin olursunuz?
Test edilmemiş DR planı, planlanmamış kadar değersizdir.
Tabletop testleri
Masa başı senaryosu: ekip bir araya gelir, varsayımsal bir felaket senaryosu üzerinde adım adım tartışır. Düşük maliyetli, gerçek sistemleri etkilemeyen, ekip eğitimi için ideal. Yılda en az 2 kere yapılmalı.
Simülasyon ve fonksiyonel testler
Belirli bileşenlerin gerçek failover'ı yapılır; örneğin bir veritabanı replikasının ikincil siteye geçişi test edilir. Üretim sistemini etkilemeden DR mekanizmasının fiilen çalıştığı doğrulanır.
Tam failover tatbikatları
Tüm üretim trafiği ikincil siteye yönlendirilir, sistemler oradan hizmet verir. En değerli ama en riskli test türü. Yılda 1 kere, planlı bakım penceresinde yapılması önerilir.
Test sıklığı ve raporlama
ISO 27001 ve BDDK denetimleri, test sıklığını yıllık en az 1 kere ve sonuçların belgelenmesini şart koşar. Her testten sonra "ne iyi gitti, ne kötü gitti, ne iyileştirilmeli" raporu yazılmalıdır; bu rapor DR planının canlı kalmasını sağlar.
Türkiye'ye özel DR konuları
Coğrafi ve düzenleyici özelliklere dikkat.
Sismik bölge ve DR site mesafesi
İstanbul'daki bir veri merkezi için DR sitenin aynı sismik fay hattı üzerinde olmaması gerekir. Ankara, İzmir veya başka şehirlerdeki ikincil sitelerle aktif-pasif veya aktif-aktif mimari, deprem gibi geniş alana yayılan felaketler için kritik. Cloud4U Türkiye iki coğrafi farklı bölgede DC altyapısı sunar.
BDDK Bilgi Sistemleri Tebliği gereksinimleri
BDDK, bankalar ve aracı kurumların DR sitelerine, RPO/RTO hedeflerine ve yıllık test sürecine dair sıkı kurallar belirlemiştir. Tebliğ uyumu, DR sağlayıcısının BDDK denetimine girebilir altyapı sunması ile başlar.
KVKK ve veri yerelleştirme
DR sitesi yurt dışında ise, KVKK kapsamında "yurt dışına aktarım" hükmü devreye girer; açık rıza veya bağlayıcı kurumsal kurallar gerekir. Türkiye içinde ikincil site, bu yükümlülüğü ortadan kaldırır.
ISO 22301 uyumu
ISO 22301, iş sürekliliği yönetim sistemi için uluslararası standarttır. DR planının bu standartla uyumlu yapısı, müşteri sözleşmelerinde ve denetimlerde önemli bir referans noktası.
ENISA Tehdit Görünümü raporları, ransomware saldırılarının kurumsal verilerde son yıllarda önemli ölçüde arttığını belgeliyor (kaynak).
Sıkça sorulan sorular (SSS)
BDDK düzenlemeleri, finans sektörü için iş sürekliliği ve felaket kurtarma planlarını zorunlu tutuyor (kaynak).
DR planı yedekle aynı şey mi?
Hayır, DR planı ile yedekleme farklı kavramlardır; yedek verinin kopyasıdır, DR ise sistemleri ve süreçleri ayağa kaldıran bütünleşik bir plandır. Yedek olmadan DR olmaz; ancak yalnızca yedek bir DR planı anlamına gelmez.
DRaaS klasik DR'a göre daha mı pahalı?
Hayır, DRaaS klasik DR'a kıyasla ilk yatırım açısından çok daha ucuzdur çünkü ikincil veri merkezi inşa etmezsiniz. Toplam 3-5 yıl TCO'da DRaaS çoğunlukla daha düşük çıkar ve operasyonel basitlik avantajı sunar.
RPO'mu nasıl belirleyeyim?
RPO'yu, iş sürecinin saat başına gelir veya zarar etkisini hesaplayarak belirleyin. 1 saatlik veri kaybı milyon TL maliyet üretiyorsa RPO dakikalar mertebesinde olmalıdır; 24 saatlik kayıp katlanılabilir maliyetse RPO saat mertebesinde tutulabilir.
Ransomware'e karşı DR yeterli mi?
Hayır, ransomware'e karşı yalnızca DR yeterli değildir; immutable backup ile birlikte kullanılmalıdır. Sadece replikasyon yapan DR çözümü, şifrelenmiş veriyi de ikincil siteye taşıyabilir. Immutable backup yazma korumalı snapshot tutarak bu riski engeller.
DR testi gerçek üretim sistemini etkiler mi?
Hayır, doğru planlandığında DR testleri üretim sistemini etkilemez. Tabletop testleri sistem etkilemez; fonksiyonel testler izole ortamda yapılır; tam failover tatbikatları planlı bakım penceresinde yürütülür.
Kaç sıklıkta DR planımı güncellemeliyim?
DR planınızı en az yılda 1 kez ve her büyük altyapı değişikliği sonrasında güncellemelisiniz. Eski sistem envanteri içeren bir DR planı, gerçek bir olay anında işe yaramaz; bu yüzden değişiklik yönetim sürecine DR güncellemesi dahil edilmelidir.
Bulut altyapım zaten yedekli; ek DR gerekir mi?
Evet, sağlayıcının yedekli mimari sunması ek bir DR planı ihtiyacını ortadan kaldırmaz. Cluster bölgesel bir felakette tamamen düşebilir; ransomware aynı bölgeye replike edilmiş tüm verileri etkileyebilir. Coğrafi olarak ayrı bir DR sitesi her durumda gereklidir.
Cloud4U Türkiye Disaster Recovery ile iş sürekliliğinizi koruyun
İş sürekliliği artık bir "ileride bakarız" konusu değil, hem regülatif baskı hem de müşteri güveni nedeniyle bugün ele alınması gereken bir kurumsal öncelik. Cloud4U Türkiye Disaster Recovery hizmeti, İstanbul ve ikincil veri merkezi arasında coğrafi yedeklilik ile DRaaS modeli sunarak kurumların DR programlarını hızla hayata geçirmesini sağlar.
- İstanbul + ikincil veri merkezi ile farklı sismik bölgelerde coğrafi yedeklilik
- Tipik konfigürasyonda RPO 15 dakika, RTO 1 saatten az hedefleri
- KVKK + ISO 27001 + BDDK uyumlu altyapı, 7/24 Türkçe destek ve ücretsiz DR planı şablonu
Şirketinizin RPO/RTO hedeflerini netleştirip uygulanabilir bir DR planı kurmaya başlamak için Cloud4U Türkiye Disaster Recovery sayfasını ziyaret edin ve ekibimizden ücretsiz DR planı şablonu ile danışmanlık alın.
