Felaket Kurtarma (DRaaS)

DRaaS felaket kurtarma merkezinde RPO ve RTO nasıl belirlenir?

Felaket kurtarma hizmetinin (DRaaS) tasarımı iki hedefle başlar. RPO (kurtarma noktası hedefi), bir kesintide geriye dönük ne kadar verinin kaybedilmesinin kabul edilebileceğini gösterir. RTO (kurtarma süresi hedefi), sistemin felaket kurtarma merkezinde ne kadar sürede yeniden hizmet vermesi gerektiğini tanımlar. Bu değerler teknolojiden önce iş tarafında belirlenir; her uygulama için aynı hedefi koymak ya gereksiz maliyet ya da yetersiz koruma doğurur.

MAV Cloud’da RPO ve RTO değerleri proje bazında, sistemlerin kritiklik sınıfına göre tanımlanır. Tipik bir sınıflandırma şöyledir:

• Kritik sistemler: ERP, üretim ve satış uygulamaları; sürekli replikasyon ve öncelikli failover sırası.
• Önemli sistemler: dosya sunucuları, iç uygulamalar; belirli aralıklarla replikasyon.
• Destek sistemleri: test ortamları, arşiv; yedekten geri yükleme yeterli olabilir.

Hedeflerin ve senaryoların belgeye nasıl döküleceği felaket kurtarma planı nasıl hazırlanır rehberinde adım adım anlatılır.

Hizmet güvencesi: Felaket anında açılan bir talep kritik öncelikte ele alınır; hizmet seviyesi sözleşmesinde bu öncelik için ilk müdahale hedefi 15 dakikadır. Failover kararından iş birimlerine bilgi verilmesine kadar süreç, MAV Cloud’un ISO 22301 belgeli iş sürekliliği ve ISO/IEC 27001 belgeli bilgi güvenliği yönetim sistemleriyle uyumludur (sertifikalarımız).

MAV Cloud’un CDP (sürekli veri koruma) tabanlı felaket kurtarma altyapısında kritik sistemler için hedef RPO 15–60 saniye, hedef RTO 5–15 dakikadır. Bu değerler taahhüt değil hedeftir; her projede sistem yapısına göre belirlenir ve failover testiyle doğrulanması planlanır. Felaket kurtarma hizmeti verilen kurumlar arasında Sardis Portföy Yönetimi yer alır.

Failover ve failback test süreci

Test edilmemiş bir felaket kurtarma planı, gerçek bir kesintide beklenen sonucu vermeyebilir. Test süreci aşağıdaki adımlarla yürütülür:

1. Kapsam ve sıra: hangi sanal makinelerin hangi sırayla açılacağı, bağımlılıklar (örneğin önce Active Directory, sonra veritabanı, en son uygulama sunucusu) belirlenir.
2. İzole test: replikalar üretim ağından ayrılmış bir ortamda açılır; üretim sistemi çalışmaya devam eder.
3. Doğrulama: uygulamanın açıldığı, veri tutarlılığı ve kullanıcı erişimi kontrol edilir; ölçülen süre RTO hedefiyle karşılaştırılır.
4. Failback provası: ana lokasyona dönüşte yalnızca kesinti süresince değişen verinin geri aktarılması planlanır.
5. Raporlama: sapmalar, eksik adımlar ve güncellenmesi gereken runbook maddeleri kayda alınır.

Testlerin sıklığı, altyapıdaki değişim hızına bağlıdır. Yeni bir uygulamanın devreye alınması, ağ yapısının değişmesi ya da sanal makine sayısının artması, planın yeniden sınanmasını gerektirir. Failover anında DNS kayıtlarının, dış erişim adreslerinin ve VPN bağlantılarının nasıl yönlendirileceği de runbook’ta yazılı olmalıdır; teknik olarak açılan bir sistem, kullanıcılar ona ulaşamıyorsa hizmet vermiş sayılmaz. Karar yetkisi de önceden netleştirilir: failover kararını kimin vereceği, iletişimin hangi kanaldan yürütüleceği ve iş birimlerine nasıl bilgi verileceği plana eklenir. ISO 22301 iş sürekliliği yaklaşımında da bu rol ve iletişim adımları, teknik adımlar kadar önemli kabul edilir.

Felaket kurtarma merkezi yaklaşımlarının karşılaştırması

Yaklaşım	Kurtarma hızı	Yatırım ve işletme yükü
Yalnızca yedekten geri yükleme	Veri hacmine bağlı, görece uzun	Düşük; ancak hedef donanımın hazır olması gerekir
Kurum içi ikinci veri merkezi	Hızlı	Yüksek; donanım, lisans, alan ve personel yükü
DRaaS	Hızlı; replikasyon ve sıralı failover ile	Kaynaklar hizmet olarak kullanılır, işletme yükü sağlayıcıdadır

Yalnızca yedekten geri yükleme, destek sistemleri için makul bir seçenektir; ancak kritik sistemlerde geri yükleme süresi veri hacmiyle birlikte uzar ve hedef donanımın o anda hazır olması gerekir. Kurum içi ikinci veri merkezi hız sağlar, fakat kullanılmadığı dönemlerde de donanım, lisans ve bakım maliyeti üretir. DRaaS modelinde ikinci lokasyonun kaynakları hizmet olarak kullanılır; replikasyon, izleme ve test süreçleri sağlayıcının operasyonuna dahildir.

DRaaS’ın altyapısı veri replikasyonu üzerine kurulur. Olay anındaki ilk müdahale hedefleri SLA sayfasında tanımlanmıştır.

Bir kesintinin saatlik ve olay başına maliyetini tahmin etmek için kesinti maliyeti hesaplayıcı kullanılabilir; sonuç, kurtarma hedefi ve bütçe kararında karşılaştırma zemini sağlar.

Felaket kurtarma merkezi nedir, nasıl seçilir?

Felaket kurtarma merkezi, ana veri merkezi kullanılamaz hale geldiğinde kritik sistemlerin çalıştırıldığı ikincil lokasyondur. Doğru merkez; ana lokasyonla aynı riski paylaşmayan bir yerde bulunan, veriyi sürekli güncel tutan ve düzenli testlerle çalıştığı kanıtlanan merkezdir.

Seçimde ilk bakılan konu lokasyondur. İkincil merkez ana lokasyonla aynı binada, aynı enerji hattında ya da aynı operatör bağlantısında olduğunda, tek bir olay iki tarafı birden etkileyebilir. Mesafe ise iki yönlü bir değişkendir: uzaklık bölgesel riskleri azaltır, ancak replikasyon trafiğinin gecikmesini ve bant genişliği ihtiyacını artırır. İkinci konu replikasyon yöntemidir. Belirli aralıklarla alınan kopyalar dakikalar veya saatler seviyesinde veri kaybı demektir; sürekli veri koruma (CDP) ise değişiklikleri neredeyse anlık olarak aktarır. MAV Cloud’un CDP tabanlı altyapısında kritik sistemler için hedef RPO 15–60 saniye, hedef RTO 5–15 dakikadır; bu değerler taahhüt değil, proje bazında belirlenen hedeflerdir.

Üçüncü konu kapasitedir. Felaket kurtarma merkezinde kritik sistemleri ayağa kaldıracak işlem gücü, bellek ve depolamanın gerçekten ayrılmış olması gerekir; kâğıt üzerinde tanımlı ama olay anında başka müşterilerle paylaşılan kaynak, RTO hedefini anlamsız kılar. Son konu ise testtir: izole ortamda yapılan failover denemeleri, ölçülen sürenin hedefle karşılaştırılmasını sağlar. Ağ tarafı da seçimin parçasıdır; failover sonrasında kullanıcıların, şubelerin ve dış servislerin ikincil merkeze hangi adres ve bağlantılarla ulaşacağı önceden tanımlanmamışsa, sistemler açılsa bile hizmet kesintisi sürer.

Felaket kurtarma, yedekleme ve yüksek erişilebilirlik farkı

Bu üç kavram birbirinin yerine kullanılsa da farklı sorulara yanıt verir. Yüksek erişilebilirlik (HA) aynı lokasyondaki bir sunucu arızasında hizmetin kesilmemesini, yedekleme verinin geçmiş bir ana geri alınabilmesini, felaket kurtarma ise lokasyonun tamamı kaybedildiğinde sistemlerin başka bir merkezde çalışmasını hedefler.

Bir kümelenmiş sanallaştırma ortamı tek bir donanım arızasını tolere edebilir, ancak bina genelinde bir enerji veya bağlantı sorununda tüm küme birlikte durur. Yedekler fidye yazılımı ya da yanlışlıkla silinen veri için vazgeçilmezdir; fakat terabaytlarca verinin geri yüklenmesi saatler sürebilir ve hedef donanımın o anda hazır olmasını gerektirir. Felaket kurtarma bu iki katmanın yerini almaz, üzerine eklenir. Replikasyon bozulmuş veya şifrelenmiş veriyi de karşı tarafa taşıyabileceği için, replikanın yanında ayrı bir yedek zinciri tutulması ve 3-2-1 kuralının uygulanması gerekir.

Felaket kurtarma hizmeti seçiminde sorulacak sorular

Teklifler karşılaştırılırken teknik özellik listesinden çok işletme ayrıntıları belirleyici olur:

• İkincil lokasyon nerede ve ana lokasyonla hangi altyapıyı paylaşıyor?
• Replikasyon sürekli mi, zamanlanmış mı; RPO ve RTO değerleri hedef mi, taahhüt mü?
• Failover anında kaynaklar ayrılmış mı, paylaşımlı mı?
• Test sıklığı nedir, izole test ortamı sağlanıyor mu, sonuçlar raporlanıyor mu?
• Failback nasıl yapılıyor, yalnızca değişen veri mi geri aktarılıyor?
• Olay anında ilk müdahale süresi nedir? MAV Cloud hizmet sözleşmesinde bu hedef kritik öncelik için 15 dakika, yüksek için 1 saat, orta için 4 saat, düşük için 1 iş günüdür.

Planın belgelenmesi için felaket kurtarma planı nasıl hazırlanır rehberi, kesintinin işletmeye maliyetini görmek için kesinti maliyeti hesaplayıcı kullanılabilir; yedek katmanının temeli 3-2-1 yedekleme kuralı yazısında yer alır.