İçeriğe atla
Bilgi Merkezi/Makale
Makale

DRaaS Nedir? Hizmet Olarak Felaket Kurtarma Nasıl Çalışır?

DRaaS'ın nasıl çalıştığını, türlerini, RPO ve RTO'ya etkisini, BaaS ve felaket kurtarma merkeziyle farkını ve sağlayıcı seçerken sorulacakları anlattık.

Oğuzhan Gerçek··8 dk okuma
DRaaS Nedir? Hizmet Olarak Felaket Kurtarma Nasıl Çalışır?

Kısa cevap: DRaaS (disaster recovery as a service, hizmet olarak felaket kurtarma), sunucuların ve verinin bir sağlayıcıya replike edildiği, felakette sistemlerin orada çalıştırıldığı felaket kurtarma modelidir. Normal zamanda hedefte replikasyonu sürdürecek kadar kaynak bekler; felakette sunucular bir kurtarma noktasından açılır (failover), sorun giderilince birincil merkeze dönülür (failback). BaaS yalnızca veriyi korur; DRaaS sunucuları da hazır tuttuğu için kurtarma dakikalarla ölçülebilir. Seçimde verinin konumu, bant genişliği, test raporu, failback planı ve fidye yazılımına karşı temiz kopya belirleyicidir.

DRaaS nedir, ne demek?

IBM'in tanımıyla DRaaS (disaster recovery as a service), veri koruma ve felaket kurtarma yeteneğini internet üzerinden, ihtiyaç anında ve kullandıkça öde modeliyle sunan üçüncü taraf bir çözümdür; fiziksel ve sanal sunucuları replike edip barındırır. Google Cloud'a göre kriz anında DR planını sağlayıcı uygular.

NIST'in beklenmedik durum planlama rehberine (SP 800-34 Rev. 1) göre yedek merkez kurumun kendi işlettiği bir tesis de olabilir, sözleşmeyle kullanılan ticari bir tesis de; DRaaS, ikinci seçeneğin hizmet olarak alınan biçimi sayılabilir. Terimin kısa tanımı sözlüğümüzde var; yedek merkez türlerini felaket kurtarma yazımızda anlattık.

DRaaS nasıl çalışır?

Hizmet üç parçadan oluşur:

  1. Replikasyon: AWS Elastic Disaster Recovery'de kaynak sunucudaki ajan diske yazılan blokları hemen hedef hesaptaki staging alanına (staging area) kopyalar. Azure Site Recovery Azure ve VMware sanal makinelerini sürekli, Hyper-V'yi 30 saniyeye kadar inen aralıklarla replike ediyor; Veeam'de servis sağlayıcı snapshot tabanlı replikasyonun yanında sürekli veri koruma (CDP) da verebiliyor.
  2. Hazır bekleyen hedef: AWS'ye göre staging alanı replikasyonu ucuz depolama ve asgari işlem gücüyle sürdürür; tam kapasiteli sunucular için yalnızca tatbikat ve kurtarma sırasında ödeme yapılır.
  3. Kurtarma noktaları: Sunucular en güncel durumdan ya da geçmişteki bir noktadan açılabilir. Ekim 2026 itibarıyla AWS'de günlük kurtarma noktaları varsayılan olarak 7 gün tutuluyor, süre 365 güne uzatılabiliyor.

Failover, failback ve runbook

Katmanlı uygulamada açılış sırası önemlidir: Microsoft'un örneğinde önce SQL arka ucu, sonra ara katman, en son web ön yüzü başlar. Kurtarma planı (recovery plan) makineleri gruplara ayırır; adımlar runbook'larla ya da betiklerle otomatikleşir, kalan işler için manuel adım konur. Microsoft'a göre otomasyon RTO'yu kısaltır; Well-Architected rehberi ise DNS güncellemesi ve trafik yönlendirmesi gibi failover sonrası işlerin yazılmasını istiyor.

Failback'te veri ters yönde replike edilir. Azure Site Recovery'de özgün makineye dönülürken yalnızca değişiklikler gönderilir; özgün makine artık yoksa dönüş başka bir konuma yapılır ve verinin tamamı yeniden kopyalanır.

Yalıtılmış test: DR tatbikatı

Microsoft'a göre test failover süren replikasyonu ve üretimi etkilemez; testin, üretimin kurtarma ağından yalıtılmış bir ağda yapılması öneriliyor. Test ağında Active Directory kopyası ve DNS ayarı da gerekir. AWS'de tatbikat replikasyonu durdurmaz.

Microsoft, uygulamalar ve bağımlılıkları sık değiştiği için her uygulamaya üç ayda bir test failover öneriyor. NIST SP 800-34 ise yüksek etkili sistemlerde yedek lokasyona failover içeren tam ölçekli bir tatbikat istiyor; her tatbikatın sonucu bir değerlendirme raporuna (after-action report) yazılır. Testin adımlarını felaket kurtarma testi yazısında verdik.

DRaaS'ın RPO ve RTO'ya etkisi

NIST'in tanımıyla RPO, kesintiden sonra verinin geri getirilmesi gereken zaman noktası; RTO ise bilgi sistemi bileşenlerinin, kurumun misyonunu ya da iş süreçlerini olumsuz etkilemeden kurtarma aşamasında kalabileceği toplam süre. AWS'ye göre Elastic Disaster Recovery'de RPO genellikle saniyenin altında kalıyor; RTO dakikalarla ölçülüyor ve büyük ölçüde işletim sisteminin açılış süresine bağlı. IBM'e göre BaaS'ta saatler ve günlerle ölçülen RPO ve RTO, DRaaS'ta dakikalara, bazen saniyelere iner.

Bunlar tipik değerler; kurumun hedefi iş maliyetinden türetilir (RPO ve RTO nasıl hesaplanır), hedefin tutup tutmadığını tatbikat gösterir.

DRaaS türleri: self-service, destekli ve tam yönetilen

IBM, sağlayıcının üstlendiği işe göre üç tür sayıyor:

  • Self-service: Sağlayıcı araç ve kaynak verir, planı kurum kurar ve işletir; kendi BT ekibi güçlü kurumlara uyar.
  • Destekli (assisted): Sağlayıcı planın kurulmasına, test edilmesine ve iyileştirilmesine yardım eder; kontrol ile dış destek arasında denge arayan kurumlar içindir.
  • Tam yönetilen (managed): Planın geliştirilmesi ve uygulanması tümüyle sağlayıcıya geçer; IBM'e göre çoğu zaman en pahalı tür de budur.

Türü ne olursa olsun felaketi kimin ilan edeceği yazılı olmalı; NIST, sözleşmede felaket sayılacak durumların ve bildirim prosedürlerinin tanımlanmasını istiyor.

DRaaS, BaaS ve felaket kurtarma merkezi farkı

  • BaaS (backup as a service): IBM'e göre BaaS yalnızca veriyi, DRaaS altyapıyı da korur; replikasyon yazılımı ve işlem gücü ödenmediği için BaaS belirgin biçimde ucuzdur (BaaS yazımız).
  • Kendi felaket kurtarma merkeziniz: Tesis kurumundur; Google Cloud ikinci bir fiziksel veri merkezini kurması ve sürdürmesi pahalı bir yatırım olarak tarif ediyor.
  • DRaaS: İkinci tesis sağlayıcıdadır; IBM'e göre başka bir lokasyonda olduğu için kurumu vuran olaydan etkilenme olasılığı çok daha düşüktür.

Kendi felaket kurtarma merkezini kurmakla DRaaS arasındaki kararı kurumsal felaket kurtarma stratejisi yazısında ele aldık.

DRaaS sağlayıcısı seçerken sorulacaklar

NIST SP 800-34'ün yedek merkez sözleşmesi maddeleri ve bulutun getirdiği sorular şunlar:

  1. Veri nerede duruyor? Replikanın ve kurtarma noktalarının ülkesi ve tesisi yazılı olmalı. NIST yedek merkezin, birincil merkezi etkileyen tehlikeden etkilenmesi olası olmayan bir bölgede olmasını istiyor; Google Cloud'a göre uyum kuralları kurtarılan sisteme de uygulanır. Yurt dışındaki kopya için KVKK'nın aktarım şartlarını ayrı bir yazıda anlattık.
  2. Bant genişliği yetiyor mu? AWS'ye göre hat, aynı yoldan replike edilen sunucuların toplam yazma hızını aşmalı; %20 pay bırakılması ve yazma hızının en az 24 saat ölçülmesi öneriliyor.
  3. Test ne sıklıkla yapılıyor, raporu kimde? NIST test takviminin ve süresinin sözleşmeye yazılmasını istiyor; raporda ölçülen RPO ile RTO ve aksayan adımlar bulunmalı.
  4. Failback nasıl yapılacak? Dönüşün hattı, süresi ve onayı failover kadar açık yazılmalı.
  5. Temiz kopya var mı? CISA'ya göre birçok fidye yazılımı türü erişebildiği yedekleri silmeye ya da şifrelemeye çalışıyor. Microsoft yedekteki değişikliği MFA gibi bant dışı bir onaya bağlamayı, en güçlü koruma olarak da değiştirilemez ya da çevrim dışı saklamayı öneriyor. Doğru noktanın seçimi fidye yazılımı kurtarma planı yazısında.
  6. Kapasite kimlerle paylaşılıyor, çıkış nasıl olacak? NIST'in listesinde aynı kaynaklara abone diğer müşteriler ve sözleşmenin sona erme koşulları da var. Veeam'de sağlayıcı birden fazla müşteriyi aynı kaynak setine (hardware plan) abone edebiliyor ve her abone setin tamamını kullanabiliyor.

Sınırları ve ödünleşimleri

  • Yedeğin yerini tutmaz: Microsoft'a göre replikasyon veri kaybına ve bozulmaya karşı korumaz; silme işlemi de her replikaya taşınır (replikasyon yazımız). Uzun geçmiş yedeklemenin işi.
  • Sürekli maliyet: AWS'de ücret replike edilen sunucu başına saatlik alınır; staging diskleri ve snapshot'lar ayrıca faturalanır.
  • Bağlantı ve güvenlik: Google Cloud'a göre felakette buluta erişim yolu kullanılamayabilir, ikinci bir yol gerekir; üretimdeki güvenlik denetimleri de kurtarılan sisteme uygulanmalı.
  • BT dışını kapsamaz: Google Cloud'a göre felaket kurtarma, iş sürekliliğinin BT sistemlerine odaklanan alt kümesi; geri kalanı iş sürekliliği planının konusu.

Kurgunun tasarımını felaket kurtarma ve iş sürekliliği mühendisliği, yedek ve replikasyon işletimini yedekleme, replikasyon ve kurtarma, hazırlığın ölçülmesini replikasyon ve kurtarmaya hazırlık hizmetlerimizde ele alıyoruz.

Sık sorulan sorular

DRaaS ne demek? Hizmet olarak felaket kurtarma demek; İngilizcesi disaster recovery as a service. Sunucular ve veri bir sağlayıcıya replike edilir, felakette sistemler orada çalışır.

DRaaS ile BaaS arasındaki fark nedir? BaaS yalnızca veriyi yedekler; geri dönüş saatler ya da günler sürebilir. DRaaS sunucuları da hazır tutar, kurtarma dakikalarla ölçülür ama maliyeti daha yüksektir.

DRaaS'ta RPO ve RTO ne kadar olur? Sürekli replikasyonda RPO saniyelere, RTO dakikalara inebilir. Geçerli olan, tatbikatta ölçülen süredir.

DRaaS fiyatı neye göre değişir? Korunan sunucu sayısına, disk hacmine, saklama süresine ve tatbikat ya da kurtarmada çalışan kaynaklara göre değişir. Hedefler küçüldükçe maliyet genellikle artar.

DRaaS hizmeti veren firmalar nasıl karşılaştırılır? Aynı ölçütlerle karşılaştırılmalı: verinin konumu, tatbikatta ölçülen RPO ve RTO, test raporu, failback planı, temiz kopya ve çıkış koşulları.

Kaynaklar