DRaaS Nedir? Disaster Recovery as a Service Rehberi

Kısaca DRaaS Nedir?

DRaaS, şirketin kritik iş yüklerinin farklı bir veri merkezi veya bulut altyapısında güncel replikalarının tutulmasını ve kesinti yaşandığında bu replikaların önceden hazırlanmış kurtarma planına göre devreye alınmasını sağlayan hizmet modelidir.

DRaaS'ın temel amacı yalnızca veriyi geri yüklemek değil, uygulamaları, sunucuları, ağ yapılandırmalarını ve bağımlı servisleri çalışır halde yeniden sunmaktır.

• Kritik sistemlerin replikalarını farklı bir lokasyonda tutar.
• RPO hedeflerine göre veri değişikliklerini sürekli veya periyodik olarak aktarır.
• Kesinti anında sistemleri tanımlanan sırayla devreye alır.
• Kullanıcı trafiğini DR ortamına yönlendirmeyi destekler.
• Üretim ortamı düzeldiğinde kontrollü failback süreci sağlar.
• Felaket kurtarma planlarının üretimi etkilemeden test edilmesine imkan verir.
• Altyapı, kapasite ve günlük operasyon sorumluluğunun önemli bölümünü sağlayıcıya devreder.

DRaaS Nedir?

DRaaS - Disaster Recovery as a Service, bir şirketin kritik sistemlerinin, uygulamalarının ve verilerinin hizmet sağlayıcının altyapısına replike edildiği ve felaket anında bu altyapı üzerinde çalıştırılarak iş sürekliliğinin sağlandığı hizmet modelidir.

DRaaS kapsamında yalnızca dosya veya veri tabanı kopyaları saklanmaz. Korunan iş yükünün çalışması için gerekli olan sanal makineler, işletim sistemi yapılandırmaları, uygulamalar, veri tabanları, ağ ayarları ve kurtarma sırası da planlanır.

Felaket veya kesinti yaşandığında DR ortamındaki replikalar devreye alınır. Bu işleme failover adı verilir. Kullanıcılar ve sistem entegrasyonları geçici olarak DR ortamına yönlendirilir.

Ana altyapı yeniden güvenli ve kullanılabilir hale geldiğinde DR ortamında oluşan yeni veriler üretim ortamına geri taşınır. Sistemler kontrollü şekilde ana lokasyona döndürülür. Bu işlem ise failback olarak adlandırılır.

DRaaS, daha genel bir felaket kurtarma ve iş sürekliliği stratejisinin teknoloji ve operasyon katmanıdır. RPO ve RTO hedefleri doğru tanımlanmadan DRaaS hizmet seviyesi ve maliyeti sağlıklı biçimde belirlenemez.

DRaaS Ne İşe Yarar?

DRaaS, üretim altyapısı kullanılamaz hale geldiğinde kritik uygulamaların farklı bir ortamda çalışmaya devam etmesini ve şirketin kabul edilebilir kesinti süresi içinde operasyonlarına dönmesini sağlar.

DRaaS aşağıdaki senaryolarda kullanılabilir:

• Sunucu, storage veya sanallaştırma platformu arızaları
• Veri merkezi güç, soğutma veya bağlantı kesintileri
• Yangın, sel, deprem ve fiziksel lokasyon kaybı
• Fidye yazılımı ve yıkıcı siber saldırılar
• Hatalı güncelleme veya yapılandırma değişiklikleri
• Veri tabanı bozulması ve uygulama hataları
• Cloud veya SaaS servis kesintileri
• Ağ, internet veya operatör kaynaklı erişim problemleri
• Planlı bakım ve altyapı geçişleri

DRaaS yalnızca felaket gününde kullanılan bir sigorta değildir. Düzenli test, replikasyon sağlığı, bağımlılık yönetimi ve ölçülebilir RPO-RTO performansıyla sürekli işletilmesi gereken bir iş sürekliliği hizmetidir.

DRaaS ile Yedekleme Arasındaki Fark Nedir?

Yedekleme verinin bir kopyasını korur. DRaaS ise verinin yanında uygulamanın ve sistem altyapısının çalışır biçimde yeniden sunulmasını hedefler.

Bir yedekten geri dönüş sırasında yeni bir sunucu hazırlanması, işletim sisteminin kurulması, uygulama yapılandırmalarının yapılması, verinin geri yüklenmesi ve bağlantıların yeniden oluşturulması gerekebilir.

DRaaS modelinde ise sistemin replike edilmiş kopyası ve kurtarma planı önceden hazırdır. Kesinti anında iş yükleri farklı altyapıda başlatılarak kurtarma süresi önemli ölçüde azaltılabilir.

DRaaS ve BackupaaS birbirinin alternatifi değildir. BackupaaS veri koruma ve granüler geri yükleme sağlar. DRaaS ise kritik iş yüklerinin kısa sürede çalıştırılmasına odaklanır.

DRaaS ile High Availability Aynı Şey midir?

Hayır. High Availability kısa süreli bileşen arızalarına karşı aynı sistem veya lokasyon içinde kesintiyi azaltırken DRaaS tüm lokasyonun, altyapının veya güvenlik alanının kaybedildiği senaryolara karşı kurtarma sağlar.

High Availability - HA çözümleri genellikle cluster, load balancer, redundant storage ve yedekli ağ bileşenleri kullanır. Amaç tek bir bileşenin arızalanması halinde hizmetin kesilmemesidir.

Ancak aynı veri merkezi, aynı kimlik altyapısı veya aynı yönetim alanı saldırıdan ya da fiziksel felaketten etkilenirse HA mimarisi yeterli olmayabilir.

Kritik iş yükleri için doğru yaklaşım çoğu zaman HA ve DRaaS katmanlarının birlikte kullanılmasıdır.

DRaaS Nasıl Çalışır?

DRaaS, korunan sistemlerdeki değişikliklerin belirlenen RPO hedefine göre farklı bir altyapıya replike edilmesi ve kesinti anında bu replikaların önceden tanımlanmış kurtarma planıyla çalıştırılması prensibiyle çalışır.

1. İş Etki Analizi ve Kapsam Belirleme

İlk adım, hangi sistemlerin şirketin kritik faaliyetlerini doğrudan etkilediğini belirlemektir. ERP, ödeme sistemi, veri tabanı, dosya sunucusu, müşteri portalı ve kimlik sistemi aynı önceliğe sahip olmayabilir.

İş etki analizi sırasında aşağıdaki sorular yanıtlanır:

• Hangi iş süreçleri kesinti halinde durur?
• Bir saatlik kesintinin maliyeti nedir?
• Ne kadar veri kaybı kabul edilebilir?
• Sistem ne kadar sürede geri dönmelidir?
• Hangi uygulamalar birbirine bağımlıdır?
• Minimum işlevsel operasyon için hangi servisler gereklidir?

2. RPO ve RTO Hedeflerinin Tanımlanması

RPO - Recovery Point Objective, kabul edilebilir maksimum veri kaybı penceresini ifade eder. RTO - Recovery Time Objective ise sistemin ne kadar sürede yeniden kullanılabilir hale gelmesi gerektiğini tanımlar.

RPO ne kadar düşükse replikasyon o kadar sık yapılmalıdır. RTO ne kadar düşükse DR ortamında o kadar fazla hazır kapasite, otomasyon ve önceden hazırlanmış yapı gerekir.

Bu metriklerin detaylı açıklaması için RPO ve RTO Nedir? rehberi incelenebilir.

3. Uygulama ve Altyapı Bağımlılıklarının Haritalanması

DR başarısı yalnızca sunucuların açılmasına bağlı değildir. Bir uygulama; Active Directory, DNS, veri tabanı, dosya paylaşımı, API, load balancer, firewall ve üçüncü taraf servislere bağlı olabilir.

Uygulama sunucusu veri tabanından önce başlatılırsa veya DNS kayıtları doğru yönlendirilmezse teknik olarak çalışan sanal makineler hizmet üretemeyebilir.

Bu nedenle kurtarma planında sistemlerin başlangıç sırası, bekleme süreleri, doğrulama kontrolleri ve ağ bağımlılıkları tanımlanmalıdır.

4. İlk Veri Aktarımı

Korunacak sistemlerin ilk tam kopyası DR altyapısına aktarılır. Veri hacmi yüksekse bu işlem mevcut ağ bağlantısı üzerinden uzun sürebilir.

İlk aktarım için şu seçenekler değerlendirilebilir:

• İnternet veya özel hat üzerinden online aktarım
• Şifreli fiziksel veri taşıma
• Geçici yüksek kapasiteli bağlantı
• Direct cloud access veya özel bağlantı

İlk veri aktarımı tamamlandıktan sonra yalnızca değişen blokların gönderildiği artımlı replikasyon başlar.

5. Sürekli veya Periyodik Replikasyon

Korunan sistemlerde oluşan değişiklikler tanımlanan RPO hedefine göre DR ortamına aktarılır.

Replikasyon üç farklı biçimde uygulanabilir:

• Senkron replikasyon: Veri iki ortama aynı anda yazılır. Çok düşük RPO sağlar ancak düşük gecikmeli ve yüksek kapasiteli bağlantı gerektirir.
• Asenkron replikasyon: Değişiklikler kısa aralıklarla ikinci ortama aktarılır. Coğrafi mesafe için daha uygundur ancak belirli bir veri kaybı penceresi oluşabilir.
• Snapshot tabanlı replikasyon: Sistem durumu belirli aralıklarla kopyalanır. Daha yüksek RPO toleransı olan sistemler için kullanılabilir.

6. Replikasyon Sağlığının İzlenmesi

Replikasyonun yalnızca çalışıyor görünmesi yeterli değildir. Aşağıdaki metrikler sürekli izlenmelidir:

• Replication lag
• Son başarılı replikasyon zamanı
• Değişen veri miktarı
• Bağlantı ve bant genişliği kullanımı
• Replika bütünlüğü
• RPO ihlalleri
• Koruma kapsamı dışında kalan sistemler

7. Kurtarma Planı ve Orkestrasyon

Sistemlerin hangi sırayla başlayacağı, IP ve ağ eşlemeleri, DNS değişiklikleri, firewall politikaları ve doğrulama adımları runbook içinde tanımlanır.

Orkestrasyon, kriz anındaki manuel işlem sayısını azaltır ve kurtarma adımlarının tutarlı biçimde yürütülmesini sağlar.

8. Failover

Üretim altyapısı kullanılamaz olduğunda DR ortamındaki sistemler kurtarma planına göre başlatılır. Uygulama kontrolleri tamamlandıktan sonra kullanıcı ve entegrasyon trafiği DR ortamına yönlendirilir.

Failover iki biçimde gerçekleşebilir:

• Planlı failover: Bakım veya geçiş öncesinde kontrollü olarak yapılır. Son değişikliklerin aktarılması beklenebilir ve veri kaybı azaltılabilir.
• Plansız failover: Ani kesinti veya felaket sonrasında yapılır. Üretim sistemi erişilemez olduğu için son replikasyon noktasına dönülür.

9. DR Ortamında Operasyon

Failover sonrasında DR ortamı geçici üretim ortamı haline gelir. Bu sırada yeni veriler oluşur, kullanıcılar sisteme erişir ve iş süreçleri devam eder.

DR ortamının performans, güvenlik, lisans, izleme ve yedekleme politikaları gerçek üretim yükünü destekleyebilmelidir.

10. Failback

Ana altyapı yeniden kullanılabilir hale geldiğinde DR ortamında oluşan değişiklikler geri senkronize edilir. Sistemler kontrollü bir bakım penceresinde ana ortama taşınır.

Failback, failover kadar kritik bir süreçtir. Veri kaybı, çakışma, çift yazma veya uzun kesinti yaşamamak için önceden planlanmalı ve test edilmelidir.

Application-Consistent ve Crash-Consistent Replikasyon Arasındaki Fark Nedir?

Crash-consistent replikasyon, sistemin ani güç kesintisi yaşadığı andaki disk durumunu korur. Application-consistent replikasyon ise uygulama ve veri tabanı işlemlerini tutarlı noktaya getirerek kurtarma kopyası oluşturur.

Dosya sunucuları ve bazı stateless uygulamalar crash-consistent kopyalardan sorunsuz dönebilir. Ancak veri tabanları, ERP sistemleri ve işlem yoğun uygulamalar için transaction bütünlüğü önemlidir.

DRaaS değerlendirmesinde sağlayıcının yalnızca sanal makineyi replike edip etmediği değil, kritik uygulamalar için tutarlı kurtarma sağlayıp sağlamadığı sorgulanmalıdır.

DRaaS Hizmet Katmanları Nelerdir?

DRaaS hizmetleri, kurtarma hızı, hazır tutulan kaynak miktarı ve maliyet seviyesine göre hot, warm ve cold katmanlarda tasarlanabilir.

Hot DRaaS - Sıcak Bekleme

Hot DRaaS modelinde sistemlerin çalışır veya çalışmaya çok yakın kopyaları DR ortamında sürekli hazır tutulur. Gerekli işlem, bellek, ağ ve depolama kaynakları önceden ayrılmıştır.

Failover saniyeler veya dakikalar içinde tamamlanabilir. Bu model en düşük RTO'yu ancak en yüksek maliyeti sunar.

Aşağıdaki sistemler için değerlendirilebilir:

• Ödeme ve finansal işlem sistemleri
• Üretim hattını yöneten kritik uygulamalar
• 7/24 hizmet veren müşteri platformları
• Kimlik ve erişim sistemleri
• Kesintiye toleransı çok düşük veri tabanları

Warm DRaaS - Ilık Bekleme

Warm DRaaS modelinde replikalar güncel tutulur ancak işlem kaynaklarının tamamı sürekli çalışır durumda olmayabilir. Failover sırasında gerekli kaynaklar başlatılır ve uygulamalar aktive edilir.

RTO dakikalar veya birkaç saat düzeyinde olabilir. Maliyet ve kurtarma hızı arasındaki denge nedeniyle kurumsal iş yüklerinin büyük bölümü için uygun modeldir.

Cold DRaaS - Soğuk Bekleme

Cold DRaaS modelinde ağırlıklı olarak veri, imaj ve temel yapılandırmalar korunur. Felaket anında işlem kaynaklarının hazırlanması, sistemlerin kurulması ve verilerin bağlanması gerekir.

RTO saatler veya daha uzun olabilir. Kesinti toleransı yüksek ve maliyet hassasiyeti bulunan sistemler için kullanılabilir.

Pilot Light

Pilot light yaklaşımında veri tabanı, kimlik veya kritik çekirdek servisler düşük kapasiteyle sürekli çalışır. Diğer uygulama kaynakları felaket anında genişletilir.

Bu model, warm ve cold yaklaşım arasında maliyet-performans dengesi sunabilir.

Olgun bir DRaaS stratejisi tüm sistemleri aynı katmana yerleştirmez. İş etki analizine göre farklı hizmet seviyelerini birlikte kullanır.

RPO ve RTO'ya Göre DRaaS Katmanı Nasıl Seçilir?

DRaaS katmanı, uygulamanın kesinti toleransı, veri değişim hızı, iş etkisi ve kurtarma bütçesine göre seçilmelidir.

Bu değerler örnektir. Nihai RPO ve RTO hedefleri şirketin iş etki analizi, regülasyonları, veri hacmi ve operasyon modeli üzerinden belirlenmelidir.

DRaaS Mimarisi Hangi Bileşenlerden Oluşur?

DRaaS yalnızca ikinci bir sanal sunucu ortamından oluşmaz. Uçtan uca hizmet aşağıdaki bileşenleri kapsamalıdır:

Replikasyon Katmanı

Sanal makineler, fiziksel sunucular, veri tabanları ve uygulama verilerindeki değişiklikleri DR ortamına aktarır.

İşlem ve Sanallaştırma Katmanı

Failover sonrasında iş yüklerinin çalışacağı işlemci, bellek ve sanallaştırma kaynaklarını sağlar.

Depolama Katmanı

Replikaları, snapshot'ları, journal kayıtlarını ve kurtarma noktalarını saklar. Performans ve kapasite, RPO-RTO hedefleriyle uyumlu olmalıdır.

Ağ ve Güvenlik Katmanı

VLAN, subnet, routing, firewall, VPN, load balancer, DNS ve güvenlik politikalarının DR ortamında yeniden oluşturulmasını sağlar.

Kimlik ve Erişim Katmanı

Active Directory, DNS, MFA, ayrıcalıklı hesaplar ve servis hesapları kurtarma sırasının en kritik parçalarıdır.

Orkestrasyon Katmanı

Başlangıç sırası, bekleme süreleri, script'ler, ağ eşlemeleri ve doğrulama adımlarını otomatik veya yarı otomatik yürütür.

İzleme ve Raporlama Katmanı

Replikasyon sağlığı, RPO ihlalleri, kapasite, test sonuçları ve kurtarma performansını raporlar.

Operasyon ve Olay Yönetimi

Alarm takibi, eskalasyon, failover kararı, kriz iletişimi, test koordinasyonu ve failback operasyonlarını kapsar.

DRaaS İçin Ağ ve Bant Genişliği Nasıl Planlanır?

DRaaS başarısı yalnızca sunucu kapasitesine değil, değişen verinin RPO süresi içinde DR ortamına taşınmasını sağlayacak bağlantı kapasitesine bağlıdır.

Bant genişliği planlamasında toplam veri hacminden çok günlük değişim oranı önemlidir.

Değerlendirilmesi gereken başlıca değişkenler şunlardır:

• Korunan toplam veri hacmi
• Günlük ve saatlik veri değişim oranı
• Hedef RPO
• Replikasyon sıkıştırma oranı
• Deduplication etkisi
• Gün içindeki trafik yoğunluğu
• Mevcut internet veya özel hat kapasitesi
• Bağlantının gecikme ve paket kaybı seviyesi
• Failback sırasında taşınacak veri hacmi

Kritik sistemler için ana bağlantının yanında alternatif operatör, VPN veya özel bağlantı yolu planlanmalıdır. Ağ tamamen kesildiğinde kullanıcıların DR ortamına nasıl ulaşacağı da DR planının parçasıdır.

Ağ altyapısının kurtarma boyutu için Ağ Kurtarma Nedir? içeriği incelenebilir.

DRaaS'ın Kurumsal Avantajları Nelerdir?

1. İkinci Veri Merkezi Yatırımını Azaltır

DRaaS, şirketin ikinci lokasyonda kendi sunucu, depolama, ağ ve sanallaştırma altyapısını kurma ihtiyacını azaltır.

Donanım satın alma, veri merkezi alanı, enerji, soğutma, lisans, bakım ve yenileme maliyetleri hizmet modeli içinde yönetilebilir hale gelir.

2. CapEx Modelini OpEx Modeline Dönüştürür

Geleneksel DR modelindeki büyük başlangıç yatırımı yerine aylık, yıllık veya kapasite bazlı hizmet modeli kullanılabilir.

Bu yaklaşım bütçenin daha öngörülebilir olmasına ve kapasitenin iş yükü büyüdükçe genişletilmesine yardımcı olur.

3. Atıl Kapasiteyi Azaltır

Geleneksel ikincil site altyapısı yıl boyunca satın alınmış ve lisanslanmış durumda bekleyebilir. DRaaS, hizmet sağlayıcının ölçek ekonomisinden yararlanarak bu kapasiteyi daha verimli sunabilir.

4. Düzenli Test İmkanı Sağlar

Test edilmemiş DR planı, gerçek bir kurtarma güvencesi değildir. DRaaS hizmetinde izole test ortamları ve orkestre edilmiş planlar test sürecini kolaylaştırabilir.

5. Kurtarma Süresini Kısaltır

Replikaların ve ağ planlarının önceden hazır olması, sistemi yedekten sıfırdan kurmaya kıyasla RTO'yu azaltır.

6. İnsan Hatasını Azaltır

Başlangıç sırası, IP eşlemeleri ve doğrulama adımları otomatikleştirildiğinde kriz anındaki manuel işlem ve hata riski azalır.

7. Coğrafi Ayrışma Sağlar

DR ortamının üretim lokasyonundan fiziksel ve operasyonel olarak ayrılması, yangın, sel, deprem, enerji kesintisi ve bölgesel bağlantı sorunlarına karşı dayanıklılığı artırır.

8. Uzman Operasyon Desteği Sunar

Replikasyon yönetimi, alarm takibi, kapasite planlama, test ve failover operasyonları uzman sağlayıcı tarafından yürütülebilir.

9. Ölçeklenebilirlik Sağlar

Yeni iş yükleri ve artan veri hacmi, fiziksel donanım yenileme süreci beklenmeden hizmet kapsamına eklenebilir.

10. Denetim ve Raporlamayı Güçlendirir

Test sonuçları, gerçek RTO süreleri, RPO ihlalleri, koruma kapsamı ve replikasyon sağlığı düzenli raporlarla görünür hale getirilebilir.

DRaaS Ransomware ve Siber Saldırılara Karşı Yeterli midir?

DRaaS hızlı kurtarma kapasitesi sağlar; ancak replike edilen sistem saldırıdan etkilenmişse kirli veya şifrelenmiş verinin DR ortamına taşınması mümkündür. Bu nedenle DRaaS tek başına cyber recovery garantisi değildir.

Replikasyon kaynak sistemdeki değişiklikleri ikinci ortama taşır. Bu değişiklik ransomware şifrelemesi, zararlı yazılım veya veri bozulmasıysa aynı durum DR ortamına da yansıyabilir.

Siber saldırı senaryosu için DRaaS aşağıdaki katmanlarla desteklenmelidir:

• Immutable backup
• Air-gapped veya izole veri kopyası
• Birden fazla kurtarma noktası
• Anomali tespiti
• Threat monitoring ve threat hunting
• Temiz kurtarma noktası analizi
• Clean room veya izole kurtarma ortamı
• Kimlik sisteminin güvenli şekilde kurtarılması
• Malware ve bütünlük kontrolleri

DRaaS sistemleri hızlı şekilde ayağa kaldırır. Immutable backup ise saldırganın değiştiremeyeceği temiz veri kopyalarının korunmasına yardımcı olur.

Rubrik tabanlı veri güvenliği ve temiz kurtarma yaklaşımı için Rubrik ile Zero Trust Data Security içeriği değerlendirilebilir.

Daha geniş kurumsal çerçeve için Siber Dayanıklılık Nedir? rehberi incelenebilir.

DRaaS ile Cyber Recovery Arasındaki Fark Nedir?

DRaaS altyapının farklı bir ortamda çalıştırılmasına odaklanır. Cyber recovery ise saldırıdan etkilenmemiş verinin bulunmasına, doğrulanmasına ve güvenli bir ortamda geri getirilmesine odaklanır.

Modern iş sürekliliği tasarımında DRaaS ve cyber recovery birlikte düşünülmelidir.

DRaaS'ın Paylaşılan Sorumluluk Modeli Nedir?

DRaaS hizmetinde teknoloji ve altyapı sağlayıcı tarafından sunulsa da iş kritikliği, uygulama bilgisi, kurtarma önceliği ve kriz kararları şirketin sorumluluğunda kalır.

Sözleşmede görev ve sorumlulukların açık tanımlanmaması, kriz anında gecikmeye ve yetki belirsizliğine yol açabilir.

DRaaS Testi Nasıl Yapılır?

DRaaS testi, üretim sistemlerini etkilemeden replikaların ayağa kaldırılması, uygulama bağımlılıklarının doğrulanması ve gerçek RPO-RTO performansının ölçülmesidir.

Kapsamlı bir test aşağıdaki aşamalardan oluşur:

1. Test kapsamı ve başarı kriterleri belirlenir.
2. İzole test ağı hazırlanır.
3. Replikalar kurtarma planına göre başlatılır.
4. Kimlik, DNS ve ağ servisleri doğrulanır.
5. Veri tabanları ve uygulamalar kontrol edilir.
6. Kullanıcı kabul testleri yapılır.
7. Gerçek RPO ve RTO süreleri ölçülür.
8. Başarısız adımlar ve bağımlılık sorunları kaydedilir.
9. Runbook ve kurtarma planı güncellenir.
10. Yönetim ve denetim raporu oluşturulur.

Test yalnızca sanal makinelerin açılmasıyla tamamlanmış sayılmamalıdır. Uygulamanın kullanıcı işlemi gerçekleştirebildiği, entegrasyonların çalıştığı ve verinin tutarlı olduğu doğrulanmalıdır.

DRaaS Testi Ne Sıklıkla Yapılmalıdır?

Test sıklığı iş yükünün kritikliği, değişim hızı ve regülasyon gereksinimine göre belirlenmelidir.

• Kritik finansal ve üretim sistemleri için üç veya altı ayda bir
• Orta kritik uygulamalar için yılda en az bir kez
• Büyük uygulama veya altyapı değişikliklerinden sonra
• Ağ, kimlik veya güvenlik mimarisi değiştiğinde
• Yeni iş yükü DR kapsamına alındığında
• Gerçek bir olay veya başarısız test sonrasında

Test sonuçları yalnızca teknik ekipte kalmamalı; risk, iş sürekliliği, denetim ve yönetim ekiplerine ölçülebilir sonuçlarla raporlanmalıdır.

DRaaS Maliyeti Nasıl Hesaplanır?

DRaaS maliyeti yalnızca replike edilen veri miktarına göre değil, korunan işlem kapasitesi, hedef RPO-RTO, hazır bekleyen kaynak seviyesi, test kapsamı ve operasyon desteğine göre hesaplanır.

Maliyet hesabında şu kalemler değerlendirilmelidir:

• Korunacak sanal makine ve fiziksel sunucu sayısı
• Toplam işlemci ve bellek kapasitesi
• Replike edilen toplam veri hacmi
• Günlük veri değişim oranı
• Hot, warm veya cold hizmet katmanı
• Hedef RPO ve RTO
• DR ortamında ayrılan sürekli kaynaklar
• Replikasyon bağlantısı
• İlk veri aktarımı
• Lisans kapsamı
• Yıllık test sayısı
• Failover ve failback operasyonu
• DR ortamında gerçek kullanım süresi
• 7/24 izleme ve destek
• Immutable backup ve uzun saklama gereksinimi

DRaaS TCO Karşılaştırmasında Neler Hesaplanmalıdır?

DRaaS ile geleneksel DR karşılaştırılırken yalnızca aylık hizmet bedeli ve donanım satın alma maliyeti karşılaştırılmamalıdır.

DRaaS Hangi Şirketler İçin Uygundur?

DRaaS özellikle aşağıdaki profile sahip şirketler için değerlendirilebilir:

• Kritik uygulamaları 7/24 çalışan şirketler
• İkinci veri merkezi yatırımı yapmak istemeyen şirketler
• Sınırlı IT ve felaket kurtarma uzmanlığı bulunan ekipler
• Düşük RPO-RTO hedeflerine sahip sektörler
• Finans, sağlık, üretim, e-ticaret ve SaaS şirketleri
• Veri egemenliği ve denetim gereksinimi bulunan kurumlar
• Private cloud veya hibrit bulut kullanan şirketler
• Birden fazla lokasyonda hizmet veren kurumlar
• Düzenli DR testi ve raporlama ihtiyacı bulunan şirketler

DRaaS Sağlayıcısı Seçerken Nelere Dikkat Edilmelidir?

DRaaS sağlayıcıları arasındaki gerçek fark; altyapı kapasitesinden çok SLA detaylarında, test politikasında, veri lokasyonunda, failover yetkinliğinde ve operasyon kapsamındadır.

1. Sistem Bazlı RPO ve RTO

RPO ve RTO değerlerinin tüm hizmet için genel değil, kritik iş yükleri bazında tanımlanması gerekir.

2. Ölçülebilir SLA

SLA içinde replikasyon sağlığı, failover başlatma süresi, altyapı erişilebilirliği, destek yanıt süresi ve test sıklığı bulunmalıdır.

3. Veri Merkezi Lokasyonu

DR altyapısının hangi şehir, ülke ve veri merkezinde bulunduğu net olmalıdır. Ana lokasyonla coğrafi, enerji, operatör ve afet riski açısından yeterli ayrışma sağlanmalıdır.

4. Veri Egemenliği

Replikaların ve yedeklerin hangi ülkede saklandığı, kişisel ve regülasyona tabi veriler açısından sözleşme öncesinde değerlendirilmelidir.

5. Replikasyon Teknolojisi

Desteklenen sanallaştırma platformları, fiziksel sunucular, veri tabanları, public cloud iş yükleri ve application-consistent replikasyon seçenekleri incelenmelidir.

6. Ağ ve Güvenlik Kapsamı

Firewall, VPN, IP planı, DNS, load balancer, VLAN ve routing yapılandırmalarının failover sırasında nasıl uygulanacağı netleştirilmelidir.

7. Test Politikası

Yıllık test sayısı, test kapsamı, izole ortam desteği, kullanıcı kabul testi ve raporlama hizmete dahil olmalıdır.

8. Failover Yetkilendirmesi

Failover kararını kimin vereceği, onay süreci, acil durum iletişim listesi ve eskalasyon zinciri tanımlanmalıdır.

9. Failback Süreci

DR ortamında oluşan verilerin üretime nasıl geri taşınacağı, planlanan kesinti süresi ve ek ücretler netleştirilmelidir.

10. 7/24 Operasyon

Replikasyon problemleri mesai saatleri dışında da oluşabilir. İzleme, alarm, müdahale ve eskalasyon süreçlerinin 7/24 çalışması gerekir.

11. Immutable Backup Entegrasyonu

Ransomware senaryosu için yalnızca güncel replika yeterli değildir. Sağlayıcının immutable ve izole veri koruma katmanları sunması değerlendirilmelidir.

12. Raporlama ve Denetim

RPO ihlalleri, son başarılı replikasyon, test sonuçları, gerçek RTO ve açık aksiyonlar raporlanmalıdır.

DRaaS Seçimi İçin Kurumsal Checklist

İş Gereksinimleri

• Kritik iş süreçleri belirlendi mi?
• Bir saatlik kesinti maliyeti hesaplandı mı?
• Minimum işlevsel operasyon tanımlandı mı?
• Sistem bazlı RPO ve RTO onaylandı mı?

Teknik Kapsam

• Fiziksel ve sanal iş yükleri destekleniyor mu?
• Veri tabanları application-consistent korunuyor mu?
• Cloud ve SaaS iş yükleri kapsama alınabiliyor mu?
• Uygulama bağımlılıkları otomatik keşfedilebiliyor mu?
• Başlangıç sırası orkestre edilebiliyor mu?

Ağ ve Bağlantı

• Mevcut bant genişliği hedef RPO için yeterli mi?
• Alternatif operatör veya bağlantı var mı?
• VPN ve DNS yönlendirmesi planlandı mı?
• Firewall ve load balancer politikaları DR ortamında hazır mı?

Güvenlik

• DR ortamı üretim kimliklerinden ayrıştırılmış mı?
• MFA ve rol bazlı erişim kullanılıyor mu?
• Immutable backup mevcut mu?
• Temiz kurtarma noktası belirlenebiliyor mu?
• İzole kurtarma ortamı sunuluyor mu?

Lokasyon ve Uyumluluk

• DR verisi hangi ülkede tutuluyor?
• Ana ve DR lokasyonları yeterince ayrışıyor mu?
• Veri işleme sözleşmesi mevcut mu?
• KVKK ve sektörel gereksinimler değerlendirildi mi?

Operasyon

• Replikasyon 7/24 izleniyor mu?
• RPO ihlalinde otomatik alarm üretiliyor mu?
• Failover kararı ve iletişim zinciri tanımlı mı?
• Failback prosedürü dokümante mi?
• Gerçek RTO düzenli ölçülüyor mu?

Test

• Yılda kaç test hizmete dahil?
• Test üretimden izole ortamda mı yapılıyor?
• İş birimleri kullanıcı kabul testine katılıyor mu?
• Test raporu ve aksiyon listesi sunuluyor mu?

DRaaS Projesi Nasıl Hayata Geçirilir?

Başarılı DRaaS projesi teknoloji kurulumu değil, iş kritikliği ve bağımlılıkları temel alan aşamalı bir dönüşüm programıdır.

Adım 1: Mevcut Durum Analizi

Sunucular, veri tabanları, uygulamalar, ağ yapısı, veri hacmi ve mevcut yedekleme süreçleri analiz edilir.

Adım 2: İş Etki Analizi

Kritik iş süreçleri, kesinti maliyetleri ve kabul edilebilir kesinti süreleri belirlenir.

Adım 3: Sistemleri Katmanlandırma

İş yükleri Tier 1, Tier 2 ve Tier 3 gibi kritik seviyelere ayrılır. Hot, warm, cold veya yalnızca BackupaaS modeli seçilir.

Adım 4: DR Mimarisi Tasarımı

Replikasyon teknolojisi, DR lokasyonu, kapasite, bağlantı, ağ, güvenlik ve lisans modeli belirlenir.

Adım 5: İlk Veri Aktarımı ve Replikasyon

İlk kopyalar oluşturulur, artımlı replikasyon başlatılır ve RPO performansı izlenir.

Adım 6: Runbook ve Orkestrasyon

Başlangıç sırası, IP eşlemeleri, kontrol adımları ve sorumluluklar tanımlanır.

Adım 7: Pilot Test

Önce sınırlı kapsamda test yapılır. Ağ, uygulama ve veri tutarlılığı sorunları giderilir.

Adım 8: Tam Kapsamlı DR Testi

Kritik sistemler izole ortamda ayağa kaldırılır, gerçek RPO-RTO ölçülür ve iş birimi kabul testleri yapılır.

Adım 9: Canlı Operasyon

Replikasyon, kapasite ve RPO performansı 7/24 izlenir. Değişen sistemler kurtarma planına eklenir.

Adım 10: Sürekli İyileştirme

Her test, altyapı değişikliği ve gerçek olay sonrasında plan güncellenir.

DRaaS Projelerinde Sık Yapılan Hatalar

1. Tüm Sistemleri Aynı Kritiklikte Görmek

Her sistemi hot DRaaS ile korumak maliyeti gereksiz artırır. Tüm sistemleri cold katmana almak ise kritik uygulamalarda kabul edilemez kesinti yaratır.

2. Sadece Sanal Makineleri Replike Etmek

Ağ, kimlik, DNS, veri tabanı ve entegrasyon bağımlılıkları planlanmazsa açılan sanal makineler hizmet üretemeyebilir.

3. RPO ve RTO'yu Teknik Ekibin Tek Başına Belirlemesi

RPO ve RTO iş hedefidir. IT ekibi teknik ve maliyet fizibilitesini sunar; nihai tolerans iş birimi ve yönetim tarafından onaylanmalıdır.

4. DRaaS'ı Yedekleme Yerine Kullanmak

Replikasyon yanlışlıkla silinen veya şifrelenen veriyi de ikinci ortama taşıyabilir. Granüler ve uzun süreli veri koruma için BackupaaS gerekir.

5. Test Yapmamak

Test edilmeyen kurtarma planındaki bağımlılık ve erişim sorunları ancak gerçek felaket sırasında ortaya çıkabilir.

6. Failback Sürecini Unutmak

Sistemlerin DR ortamında çalışması geçici çözüm olabilir. Ana ortama geri dönüş planlanmadığında veri senkronizasyonu ve uzun süreli maliyet sorunları oluşur.

7. Bant Genişliğini Yanlış Boyutlandırmak

Günlük değişim miktarı RPO süresi içinde taşınamıyorsa sözleşmedeki hedef kağıt üzerinde kalır.

8. Son Replikayı Temiz Kabul Etmek

Ransomware veya sessiz veri bozulması son replikaya taşınmış olabilir. Siber olaylar için temiz kurtarma noktası analizi gerekir.

9. Lokasyon Riskini Yeterince Ayırmamak

Aynı enerji, operatör, afet veya yönetim alanına bağlı iki lokasyon gerçek coğrafi dayanıklılık sağlamayabilir.

10. Sözleşme Kapsamını Belirsiz Bırakmak

Test, failover, failback, veri transferi, lisans ve gerçek kullanım ücretleri sözleşmede açıkça tanımlanmalıdır.

DRaaS İçin Takip Edilmesi Gereken KPI'lar Nelerdir?

• RPO uyum oranı: İş yüklerinin hedef veri kaybı penceresini karşılama oranı
• Gerçek RTO: Test veya olay sırasında sistemin kullanılabilir hale gelme süresi
• Replication lag: Üretim ile DR ortamı arasındaki veri gecikmesi
• Replikasyon başarı oranı: Başarıyla tamamlanan replikasyon işlerinin oranı
• Koruma kapsamı: DR kapsamındaki kritik iş yüklerinin toplam kritik iş yüklerine oranı
• Test başarı oranı: Başarı kriterlerini karşılayan testlerin oranı
• Failover başlatma süresi: Olay onayından teknik işlemin başlamasına kadar geçen süre
• Uygulama doğrulama süresi: Sistemlerin açılmasından iş birimi kabulüne kadar geçen süre
• Failback süresi: DR ortamından ana altyapıya geri dönüş süresi
• Açık aksiyon kapanma süresi: Testlerde bulunan sorunların giderilme süresi
• Kapasite kullanım oranı: Ayrılan DR kaynaklarının kullanım ve yeterlilik durumu
• Cyber RTO: Siber saldırı tespitinden güvenli üretim dönüşüne kadar geçen süre

DRaaS ve KVKK İlişkisi

Kişisel veri içeren sistemlerin DR ortamına replike edilmesi, veri işleme ve saklama süreçlerinin DRaaS sözleşmesinde açıkça tanımlanmasını gerektirir.

Değerlendirilmesi gereken başlıca konular şunlardır:

• Replikaların hangi ülkede ve veri merkezinde saklandığı
• DRaaS sağlayıcısının veri işleyen rolü
• Veri işleme sözleşmesi
• Alt yükleniciler ve üçüncü taraf sağlayıcılar
• Veri aktarımında ve depoda şifreleme
• Şifreleme anahtarlarının yönetimi
• Erişim yetkileri ve yönetici hesapları
• Loglama ve denetim kayıtları
• Saklama ve silme politikaları
• Hizmet sonlandırıldığında verinin güvenli silinmesi

DRaaS teknolojisi tek başına KVKK uyumluluğu sağlamaz. Teknik mimari, sözleşme, politika ve operasyon süreçleri birlikte değerlendirilmelidir.

Ixpanse ile DRaaS Yaklaşımı

Ixpanse, DRaaS yaklaşımını yalnızca sanal makinelerin ikinci bir ortama kopyalanması olarak değil; veri koruma, özel bulut, colocation, ağ, güvenlik ve yönetilen operasyon katmanlarından oluşan uçtan uca iş sürekliliği mimarisi olarak ele alır.

Ixpanse'in Veri Koruma yaklaşımı yedekleme, felaket kurtarma ve tehdit analizi süreçlerini; Yönetilen Hizmetler yaklaşımı ise 7/24 izleme, sanal sunucu yönetimi ve replikasyon operasyonunu destekler.

Özel Bulut ve Sunucu Barındırma katmanları, şirketlerin ihtiyaç duyduğu işlem, depolama, bağlantı ve fiziksel altyapının farklı hizmet modelleriyle tasarlanmasına imkan verir.

Ixpanse yaklaşımında DRaaS aşağıdaki bileşenlerle birlikte konumlandırılabilir:

• İş etki analizi ve sistem katmanlandırma
• RPO-RTO bazlı DR mimarisi
• Coğrafi olarak ayrılmış replikasyon altyapısı
• Hot, warm ve cold kurtarma katmanları
• Uygulama bağımlılıklarının haritalanması
• Failover ve failback runbook'ları
• İzole DR testleri
• 7/24 replikasyon ve altyapı izleme
• BackupaaS ve immutable backup entegrasyonu
• Rubrik teknolojisiyle güçlendirilmiş veri güvenliği
• RPO, RTO ve test performansı raporlaması

Bu yaklaşımda temel soru yalnızca "İkinci bir veri merkezimiz var mı?" değildir. Asıl soru şudur:

"Kritik sistemlerimiz kullanılamaz hale geldiğinde, hangi veriden, hangi altyapıda, hangi sırayla ve ne kadar sürede operasyonlarımıza dönebiliriz?"

Felaket kurtarma stratejinizi, mevcut RPO-RTO hedeflerinizi ve DRaaS hizmet modelini değerlendirmek için Ixpanse uzman ekibiyle iletişime geçebilirsiniz.

Sonuç

DRaaS, felaket kurtarmayı yüksek sermaye yatırımı gerektiren ikinci veri merkezi projesinden, ölçeklenebilir, test edilebilir ve yönetilen bir hizmet modeline dönüştürür.

Ancak DRaaS'ın gerçek değeri yalnızca sistemleri ikinci ortamda açabilmesinde değildir. Başarılı bir hizmet; doğru RPO-RTO hedefleri, uygulama bağımlılıkları, ağ tasarımı, düzenli test, ölçülebilir SLA ve kontrollü failback süreciyle birlikte çalışmalıdır.

• DRaaS veriyi değil, çalışan sistemleri ve iş sürekliliğini korumaya odaklanır.
• BackupaaS, DRaaS ve high availability farklı ihtiyaçları karşılar ve birlikte kullanılabilir.
• Hot, warm, pilot light ve cold katmanlar iş kritikliği bazında seçilmelidir.
• RPO-RTO hedefleri teknoloji ekibiyle birlikte iş birimleri tarafından belirlenmelidir.
• Ağ, kimlik, DNS ve uygulama bağımlılıkları kurtarma planına dahil edilmelidir.
• Failover kadar failback süreci de önceden tasarlanmalıdır.
• Ransomware senaryolarında DRaaS, immutable backup ve cyber recovery ile desteklenmelidir.
• Test edilmeyen DRaaS hizmeti gerçek kurtarma kapasitesini kanıtlamaz.
• Sağlayıcı seçiminde fiyat kadar veri lokasyonu, SLA, test ve operasyon kapsamı sorgulanmalıdır.

Felaket kurtarma planının değeri kriz anında yazılan prosedürlerde değil, krizden önce tamamlanan son başarılı testin ölçülmüş sonuçlarında görülür.

DRaaS Hakkında Sıkça Sorulan Sorular

DRaaS nedir?

DRaaS, kritik sistemlerin, uygulamaların ve verilerin farklı bir altyapıya replike edildiği ve kesinti halinde bu ortamda çalıştırıldığı yönetilen felaket kurtarma hizmetidir.

Disaster Recovery as a Service ne işe yarar?

Üretim altyapısı kullanılamaz hale geldiğinde kritik iş yüklerinin farklı bir veri merkezi veya bulut ortamında yeniden çalıştırılmasını ve iş süreçlerinin devam etmesini sağlar.

DRaaS ile BackupaaS arasındaki fark nedir?

BackupaaS veriyi yedekler ve geri yükler. DRaaS ise uygulamaları, sunucuları, ağ yapılandırmalarını ve bağımlı servisleri çalışır biçimde devreye almayı hedefler.

DRaaS ile high availability aynı şey midir?

Hayır. High availability yerel bileşen arızalarında kesintiyi azaltır. DRaaS ise tüm lokasyonun veya üretim altyapısının kullanılamadığı daha geniş felaket senaryolarına karşı kurtarma sağlar.

Failover nedir?

Failover, üretim sistemleri kullanılamaz olduğunda iş yüklerinin DR ortamında başlatılması ve kullanıcı trafiğinin bu ortama yönlendirilmesidir.

Failback nedir?

Failback, ana altyapı düzeldikten sonra DR ortamında oluşan verilerin geri senkronize edilmesi ve operasyonun kontrollü biçimde ana sisteme döndürülmesidir.

Hot, warm ve cold DRaaS arasındaki fark nedir?

Hot DRaaS sürekli hazır kaynaklarla en hızlı kurtarmayı sunar. Warm DRaaS replikaları hazır tutar ancak kaynakları failover sırasında başlatır. Cold DRaaS ise veri ve imajları korur, altyapıyı ihtiyaç anında hazırlar.

DRaaS gerçekten dakikalar içinde çalışır mı?

Hot veya uygun tasarlanmış warm DRaaS, doğru replikasyon, güncel runbook ve düzenli testlerle sistemleri dakikalar içinde devreye alabilir. Gerçek süre uygulama bağımlılıklarına ve hizmet katmanına bağlıdır.

DRaaS veri kaybını tamamen önler mi?

Hayır. Olası veri kaybı RPO değerine bağlıdır. Son başarılı replikasyon ile kesinti anı arasındaki değişiklikler kaybedilebilir.

Her sistemi DRaaS kapsamına almak gerekir mi?

Hayır. Kritik sistemler DRaaS ile, kesinti toleransı yüksek sistemler BackupaaS veya cold katmanla korunabilir. Doğru model iş etki analiziyle belirlenmelidir.

DRaaS ransomware saldırılarında yeterli midir?

Tek başına yeterli olmayabilir. Şifrelenmiş veya zararlı veri DR ortamına replike edilmiş olabilir. DRaaS'ın immutable backup, tehdit analizi ve temiz kurtarma noktasıyla desteklenmesi gerekir.

DRaaS testi neden önemlidir?

Test, replikaların gerçekten açılabildiğini, uygulama bağımlılıklarının çalıştığını ve gerçek RPO-RTO hedeflerinin karşılandığını kanıtlar.

DRaaS testi üretimi etkiler mi?

Doğru tasarlanmış DRaaS hizmetinde testler izole ağ ve kaynaklar üzerinde gerçekleştirilerek üretim sistemi üzerindeki etki sınırlandırılabilir.

İnternet bağlantısı kesilirse DRaaS nasıl kullanılır?

Kullanıcıların DR ortamına alternatif operatör, VPN, özel bağlantı veya DNS yönlendirmesiyle erişmesi planlanmalıdır. Bağlantı mimarisi DR tasarımının ayrılmaz parçasıdır.

DRaaS maliyeti neye göre belirlenir?

Maliyet; işlem kapasitesi, veri hacmi, değişim oranı, RPO-RTO hedefleri, hot-warm-cold katmanı, test sayısı, bağlantı, lisans ve operasyon kapsamına göre belirlenir.

DRaaS verileri nerede saklanır?

Veriler hizmet sağlayıcının veri merkezi, özel bulut veya public cloud altyapısında saklanabilir. Ülke, şehir, veri merkezi ve veri işleme koşulları sözleşmede açıkça belirtilmelidir.

DRaaS KVKK uyumluluğu sağlar mı?

DRaaS tek başına KVKK uyumluluğu sağlamaz. Veri lokasyonu, erişim, şifreleme, sözleşme, alt yükleniciler ve saklama politikaları uyumluluk sürecinin parçasıdır.

Ixpanse DRaaS için nasıl destek sağlar?

Ixpanse; veri koruma, özel bulut, colocation, yönetilen hizmetler, replikasyon, BackupaaS ve 7/24 izleme katmanlarıyla şirketlerin RPO-RTO hedeflerine uygun felaket kurtarma mimarisi oluşturmasına destek olur.

İlgili İçerikler

• Felaket Kurtarma Nedir?
• RPO ve RTO Nedir?
• BackupaaS Nedir?
• Immutable Backup Nedir?
• Rubrik ile Zero Trust Data Security
• Siber Dayanıklılık Nedir?
• Fidye Yazılımı Nedir?
• Veri Kaybının Maliyeti
• Ağ Kurtarma Nedir?
• Yedekleme Nedir?
• Veri Koruma Hizmetleri
• Yönetilen Hizmetler
• Özel Bulut Hizmetleri
• Sunucu Barındırma ve Colocation