Felaket kurtarma projelerinde toplantı masasında sık duyulan cümle şudur: “DRaaS aldık, artık her şey hazır.” Oysa hizmet olarak felaket kurtarma, yedeklemenin ötesinde ikincil bir ortamda sistemleri ayağa kaldırma kapasitesi sunar. Hangi uygulamaların kapsama girdiği, ağ ve kimlik adımlarının kimin işi olduğu ve tatbikat sıklığı sözleşmede yazılmadığında boşluk kalır.
Bu metin DRaaS ürün sayfasını destekler. Ticari paket satışı yapmaz. Yedekleme odaklı modelin sınırlarını BaaS nedir yazısında, iş sürekliliği planı ile teknik kurtarma ayrımını Ankara iş sürekliliği rehberi içinde ele aldık.
Hızlı Özet
DRaaS, üretim ortamı kullanılamaz hale geldiğinde seçili sistemleri ikincil bir veri merkezinde veya bulut bölgesinde çalıştırmayı amaçlayan hizmet modelidir. Yedek dosyayı indirip yeni donanıma kurmak yerine replike edilmiş sanal makineler, ağ segmentleri ve erişim yolları önceden tanımlanır. Model güçlüdür, ancak otomatik olarak tüm uygulama portföyünü, tüm bağımlılık zincirini ve tüm kullanıcı trafiğini kapsamaz.
Veri kaybı penceresi ve toparlanma süresi hedefleri proje ve sağlayıcı dokümantasyonu ile hedef olarak değerlendirilir. Kesin sayı taahhüdü bu yazıda verilmez. Leon-X altyapı sahibi değildir. DRaaS seçeneğini gereksinimlere göre değerlendirir, bağımlılık haritasını ve runbook adımlarını birlikte kurgular.
İçindekiler
- DRaaS Modeli Pratikte Ne Sunar
- BaaS ve Klasik DR Projesinden Farkı
- Ürün Paketinde Sık Görülen Sınırlar
- Sözleşme ve Sorumluluk Çizgisi
- Tatbikat Olmadan DRaaS Yeterli Sayılmaz
- Yaygın Yanlış Anlamalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, veri merkezinde çalışan teknisyen.
DRaaS Modeli Pratikte Ne Sunar
DRaaS kısaltması Disaster Recovery as a Service ifadesinden gelir. Türkçede hizmet olarak felaket kurtarma olarak anılır. Temel fikir, üretim ortamındaki sanal makinelerin ve kritik verilerin ikincil bir siteye sürekli veya periyodik replike edilmesi ve kesinti anında bu kopyaların iş yükü olarak başlatılmasıdır.
Yerel yedekleme bandında kopya vardır, ancak büyük arızada sunucuyu sıfırdan kurmak saatler sürebilir. DRaaS tarafında ise önceden boyutlandırılmış compute, depolama ve ağ kabuğu bekler. Yedek ortama geçiş kararı verildiğinde sanal makineler ikincil ortamda açılır. DNS yönlendirme, TLS kimlik belgesi geçerliliği ve uygulama katmanı testleri ayrı adımlar olarak planlanmalıdır.
Kapsam genelde kritik sistem listesi ile sınırlıdır. ERP, ana veritabanı ve kimlik servisi pakete dahil edilirken raporlama sunucusu veya geliştirme ortamı dışarıda kalabilir. Liste güncellenmezse yeni açılan servisler felaket anında kapsam dışı kalır.
BaaS ve Klasik DR Projesinden Farkı
BaaS yalnızca veriyi güvenli depoda tutar. Geri dönüş için indirme, kurulum ve doğrulama süreci müşteri operasyonuna kalır. DRaaS ise çalışan sistem beklentisi taşır. İkisi birbirinin yerine geçmez.
Klasik DR projesinde şirket ikinci veri merkezini, donanımını ve lisanslarını kendisi işletir. DRaaS modelinde bu kabuk hizmet sağlayıcı tarafından sunulur. Müşteri yine de uygulama sahibi, veri sınıflandırması ve erişim politikalarından sorumludur. 3-2-1 yedekleme kuralı ile bulut katmanını konumlandırırken DRaaS katmanını ayrı bir karar olarak ele almak gerekir.
Hypervisor tabanlı ortamlarda replikasyon mantığı yerel DR projelerindeki adımlarla örtüşür. DRaaS paketi bu adımların bir kısmını ürünleştirilmiş akışa taşır, ancak uygulama tutarlılığı ve sıra bağımlılıkları yine müşteri runbookunda tanımlanmalıdır.
Ürün Paketinde Sık Görülen Sınırlar
Sahada tekrar eden sınır türleri şunlardır.
Kapsam listesi. Paket yalnızca sözleşmede adı geçen VM sayısı veya CPU bellek kotası ile sınırlı olabilir. Kotayı aşan geçici kapasite artışı ek süreç ister.
Ağ ve kimlik. İkincil ortamda VLAN, firewall kuralı ve VPN tüneli her zaman pakete dahil değildir. Active Directory veya LDAP replikasyon gecikmesi yedek ortama geçişten sonra oturum açma sorunları üretir.
Lisans taşınması. Üretim lisansının DR ortamında ikinci kopya hakkı olmayabilir. Tatbikat sırasında lisans uyarısı alınması sık görülür.
Veri yerleşimi ve uyumluluk. Verinin hangi bölgede tutulacağı proje öncesinde doğrulanır. Genel bir uyumluluk taahhüdü bu yazıda iddia edilmez.
Üretime geri dönüş. Ana siteye dönüş adımları yedek ortama geçiş kadar net yazılmazsa tatbikat sonrası veri sapması yaşanır. Geri dönüş planı ayrı bir runbook maddesi olmalıdır.
Bu sınırlar yedekleme testi olmadan BaaS geri yükleme kontrol listesindeki disiplinle aynı mantığı paylaşır. Kanıt üretmeden yeşil panel yeterli sayılmaz.
Sözleşme ve Sorumluluk Çizgisi
Paylaşılan sorumluluk modeli DRaaS’te de geçerlidir. Sağlayıcı ikincil platformun erişilebilirliğini, replikasyon kanalının çalışmasını ve sözleşmede tanımlı hizmet çerçevesini yürütür. Müşteri kritik sistem envanterini güncel tutar, erişim bilgilerini güvenli paylaşır ve yedek ortama geçiş kararını iş sürekliliği politikasına göre verir.
Sözleşmede şu maddelerin açık olması önerilir.
- Replikasyon sıklığı ve tutarlılık penceresi nasıl tanımlanıyor
- Yedek ortama geçiş tetikleme yetkisi kimde
- Test ortamında yılda kaç kez tatbikat yapılacağı
- Üretime geri dönüş süreci ve veri senkronizasyonu kimin sorumluluğunda
- Destek kanalı ve olay sınıflandırması
Veri kaybı penceresi ve toparlanma süresi terimleri hedef olarak değerlendirilir. Sayısal vaat yalnızca imzalı sözleşme ve sağlayıcı dokümantasyonu ile netleşir. Leon-X bu süreçte gereksinim toplar ve teknik tasarımı koordine eder, altyapı sahibi değildir.
Tatbikat Olmadan DRaaS Yeterli Sayılmaz
DRaaS aboneliği aktif olsa bile yılda bir kez masa başı senaryo yeterli değildir. Gerçekçi tatbikat DNS değişikliği, uygulama smoke testi ve kullanıcı erişim doğrulaması içermelidir. Tatbikat raporunda başlangıç ve bitiş zamanı, kapsanan sistem listesi ve bulunan eksikler kayıt altına alınır.
Tatbikat sırasında üretim trafiğine etki riski olduğu için bakım penceresi ve geri alma planı önceden onaylanır. İlk denemede tüm uygulama yığını yerine kısmi uygulama grubu ile başlamak sahada daha güvenli ilerler.
Yaygın Yanlış Anlamalar
DRaaS satın alındığında BCP belgesinin de otomatik tamamlandığı varsayımı yanlıştır. BCP iş süreçleri ve iletişim zincirini kapsar, DRaaS teknik kurtarma katmanıdır.
Tüm sanal makinelerin aynı toparlanma süresiyle ayağa kalkacağı beklentisi gerçekçi değildir. Veritabanı ve ön yüz katmanları sıralı başlatma ister.
Replikasyon yeşil göründüğü için uygulama tutarlılığının kesin olduğu düşüncesi tehlikelidir. Uygulama seviyesinde tutarlılık ayrı test ister.
Bulut DRaaS ile fiziksel tape yedeklemenin aynı işi gördüğü kanısı da sık görülür. Uzun süreli arşiv ve anlık yedek ortam devreye alma farklı ihtiyaçlardır.
Kontrol Listesi
- Kritik sistem envanteri ve bağımlılık haritası güncel
- DRaaS kapsam listesi sözleşmede VM veya servis adıyla eşleşiyor
- Veri kaybı penceresi ve toparlanma süresi hedefleri yazılı ve yönetim onaylı
- DNS, TLS kimlik belgesi ve kimlik adımları runbookta ayrı satır
- Yıllık yedek ortam ve geri dönüş tatbikatı takvime işlendi
- DRaaS seçeneği gereksinimlerle karşılaştırıldı
Leon-X ile Sonraki Adım
Leon-X felaket kurtarma gereksinimlerinizi iş öncelikleriyle eşleştirir. DRaaS paketini BaaS ve yerel replikasyon seçenekleriyle yan yana değerlendirir, bağımlılık haritası ve runbook taslağını çıkarır. Tatbikat planını ve üretime dönüş adımlarını operasyon ekibinizle koordine eder. Altyapı sahibi değildir. Keşif için iletişime geçin.
Sık Sorulan Sorular
DRaaS her felaket senaryosunu çözer mi?
Hayır. Yangın, fidye yazılımı veya bölgesel kesinti farklı tetikleyicilerdir. DRaaS teknik kurtarma kapasitesi sunar. İletişim planı, yedek ofis ve tedarik zinciri BCP kapsamındadır.
Yedek ortam tatbikatı üretimi etkiler mi?
Doğru planlanmazsa etkiler. İzole ağ segmentinde kısmi test veya salt okunur doğrulama ile başlamak riski düşürür. Test penceresi ve geri alma adımları önceden yazılmalıdır.
DRaaS varken yerel yedek gerekir mi?
Çoğu kurumda evet. Günlük dosya geri dönüşleri ve uzun süreli arşiv için yerel veya BaaS katmanı DRaaS ile birlikte düşünülür. Dosya bazlı ve imaj bazlı yedek ayrımını proje öncesinde netleştirin.
Leon-X DRaaS altyapısını işletir mi?
Leon-X Bulutistan altyapısının sahibi değildir. DRaaS seçeneğini değerlendirir, entegrasyon ve tatbikat süreçlerini danışmanlık ve operasyon koordinasyonu ile destekler.
Sonuç
DRaaS, felaket anında sistemleri ikincil ortamda çalıştırma kapasitesi sunan güçlü bir ürün modelidir. Paket adı tek başına her uygulamayı kapsama veya kesin taahhüt anlamına gelmez. Kapsam listesi, ağ ve kimlik adımları, lisans ve üretime dönüş maddeleri sözleşmede netleşmeden “hazırız” demek erken olur. Yedekleme disiplini, düzenli tatbikat ve güncel runbook ile birleştiğinde DRaaS gerçek değer üretir.
Kaynaklar
- Bulutistan DRaaS ürün sayfası (kapsam proje bazında doğrulanır)
- Leon-X iç claim ledger C-05 nötr dil
