Kritik bir sunucunun kopyasını ikinci bir lokasyonda hazır tutmak, felaket kurtarmanın en etkili yollarından biridir. Ama ikinci bir sistem odası kurmak; donanım, lisans, soğutma, bağlantı ve bakım demektir. Çoğu küçük ve orta ölçekli işletme için bu maliyet, korunan sistemlerin değerini aşar. DRaaS (Disaster Recovery as a Service, hizmet olarak felaket kurtarma) bu ikilemi çözmek için ortaya çıktı: sistemlerinizin kopyası bir hizmet sağlayıcının altyapısında tutulur, felaket anında orada çalıştırılır. Bu yazıda DRaaS’ın nasıl çalıştığını, neyi çözüp neyi çözmediğini ve bir sağlayıcıya hangi soruları sormanız gerektiğini anlatıyoruz. Felaket kurtarmanın genel çerçevesi için felaket kurtarma sayfamıza bakabilirsiniz.
Yedek lokasyon türleri
DRaaS’ı anlamak için önce klasik yedek lokasyon kavramlarına bakmak işe yarar. NIST’in acil durum planlama rehberi SP 800-34 üç tür tanımlar:
| Tür | NIST tanımının özeti | Tipik geri dönüş hızı |
|---|---|---|
| Soğuk lokasyon | Elektrik ve fiziksel altyapısı hazır, ama bilgisayar donanımı yerinde olmayan tesis | Günler, haftalar |
| Ilık lokasyon | Bilgi sistemleri ve iletişim donanımıyla kısmen donatılmış çalışma alanı | Saatler, günler |
| Sıcak lokasyon | Donanım ve yazılımıyla tamamen çalışır durumdaki uzak tesis | Dakikalar, saatler |
DRaaS, bu lokasyonu sizin yerinize bir sağlayıcının işletmesidir. Sıcak lokasyonun hızına yaklaşırken, sistemler normal zamanda çalışmadığı için ödeme çoğu zaman depolama ve hazır bekleyen kaynaklar üzerinden yapılır.
DRaaS nasıl çalışır?
1. Kopyalama
Korunan sunucuların verisi, sağlayıcının altyapısına sürekli ya da belirli aralıklarla gönderilir. Bu, sürekli replikasyonla ya da sık alınan yedeklerin buluta aktarılmasıyla yapılır. Yöntem, kabul edebileceğiniz veri kaybını, yani RPO’yu belirler.
2. Hazırlık
Felaket anında hangi sunucunun hangi sırayla açılacağı, hangi ağa bağlanacağı ve hangi kaynakları kullanacağı önceden tanımlanır. Etki alanı denetleyicisi önce, veritabanı sonra, uygulama sunucusu en son açılır gibi. Bu sıralama genellikle bir kurtarma planı (runbook) olarak yazılır.
3. Yük devretme
Ana lokasyon kullanılamaz hâle geldiğinde sistemler sağlayıcının altyapısında başlatılır. Kullanıcıların bu sistemlere ulaşması için DNS kayıtları güncellenir ya da şubeler ve uzaktaki çalışanlar VPN ile yeni lokasyona bağlanır.
4. Geri dönüş
Ana lokasyon onarıldığında, bu sürede bulutta oluşan veriler geri taşınır ve sistemler asıl yerine döner. Bu adım çoğu zaman unutulur, ama en az yük devretme kadar planlama ister. Birkaç gün bulutta çalışan bir ERP’nin veritabanı, o sürede girilen tüm siparişleri içerir; geri taşıma sırasında hiçbirinin kaybolmaması gerekir. Geri dönüş genellikle mesai dışında, kısa ve planlı bir kesintiyle yapılır.
Hizmet modelleri
- Kendi kendine hizmet: Sağlayıcı altyapıyı ve aracı sunar; planlama, test ve yük devretme sizin ekibinizdedir.
- Destekli: Planı birlikte hazırlarsınız; felaket anında sağlayıcı teknik destek verir.
- Yönetilen: Planlama, izleme, test ve yük devretme sağlayıcının sorumluluğundadır.
Bazı yedekleme platformları, yedeklemeyi ve buluta yük devretmeyi aynı konsolda sunar. Örneğin Acronis, felaket kurtarma eklentisiyle kritik sistemlerin Acronis bulutuna yük devredilebildiğini belirtir. Hangi araç kullanılırsa kullanılsın, asıl belirleyici olan planın ve testlerin kalitesidir.
Kimler için uygun?
DRaaS her işletme için doğru cevap değildir, ama bazı durumlarda öne çıkar:
- Tek lokasyonlu işletmeler: Tüm sunucuları tek bir sistem odasında duran ve ikinci bir binası olmayan firmalar için yedek lokasyon kurmanın en pratik yoludur.
- Az sayıda kritik sistemi olanlar: Bir ERP, bir veritabanı ve bir etki alanı denetleyicisi için ikinci bir sistem odası kurmak orantısız bir yatırımdır.
- BT ekibi küçük olanlar: Yönetilen modelde yük devretme ve testlerin bir kısmı sağlayıcıya devredilir.
Buna karşılık çok sayıda sunucusu, büyük veri hacmi ya da düşük gecikme isteyen üretim sistemleri olan işletmelerde, kendi ikinci lokasyonu ya da bir veri merkezinde barındırılan hedef sunucular daha öngörülebilir bir maliyet sunabilir. Karar, korunan sistemlerin değeri ile hazırlığın maliyeti arasındaki dengeye göre verilmelidir.
DRaaS neyi çözmez?
- Yedeğin yerini tutmaz. Replikasyon, silinen ya da şifrelenen veriyi de kopyalar. Geçmişe dönmek için ayrıca yedekleme gerekir. Farkı yedekleme ile felaket kurtarma arasındaki fark yazımızda anlattık.
- Ağ sorununu kendiliğinden çözmez. Sistemler bulutta açılsa bile kullanıcıların oraya nasıl bağlanacağı, IP adreslerinin nasıl değişeceği ve güvenlik duvarı kurallarının nasıl taşınacağı ayrıca planlanmalıdır.
- Her sistemi kapsamaz. Özel donanıma bağlı sistemler, örneğin bir üretim hattının makine kontrol bilgisayarları, bulutta çalıştırılamayabilir.
- Test edilmeden çalışmaz. Hiç denenmemiş bir yük devretme, felaket anında sürprizlerle dolu olur.
Sağlayıcıya sorulacak sorular
- Verilerim hangi ülkede, hangi veri merkezinde tutuluyor? Kişisel veriler açısından bu, KVKK ile ilgili önemli bir sorudur.
- Hangi RPO ve RTO değerleri hangi koşullarda sağlanabiliyor? Bu değerler sözleşmede yazıyor mu?
- Canlı sistemleri etkilemeden, yılda kaç kez test yapabiliyorum? Testin ek maliyeti var mı?
- Yük devretme sırasında çalışan sistemlerin kaynak ve lisans maliyeti nasıl hesaplanıyor?
- Geri dönüş nasıl yapılıyor, ne kadar sürüyor?
- Kullanıcılar ve şubeler bulutta açılan sistemlere nasıl bağlanıyor?
- Felaket anında kiminle, hangi kanaldan iletişim kuracağım?
DRaaS mi, kendi ikinci lokasyonunuz mu?
DRaaS tek seçenek değildir. Kritik sistemlerinizi gerçek zamanlı replikasyonla ikinci bir lokasyondaki hedef sunucuya kopyalamak da aynı amaca hizmet eder. Bu hedef, kendi şubeniz ya da bir veri merkezinde barındırılan bir sunucu olabilir. Bu yapıda OpenText Availability (Carbonite) ile bayt düzeyinde replikasyon ve otomatik yük devretme kuruyoruz. Sanal sunucu ağırlıklı ortamlarda Veeam replikasyonu da bir seçenektir. Hangi yolun uygun olduğu; korunacak sistem sayısına, hat kapasitesine ve hedeflenen geri dönüş süresine bağlıdır. Bulut ile şirket içini birlikte kullanma konusunu hibrit buluta geçiş yazımızda ele aldık.
Nereden başlamalı?
Önce hangi sistemlerin gerçekten dakikalar ya da saatler içinde geri gelmesi gerektiğini belirleyin. Bunun için RTO ve RPO hedefleri iyi bir başlangıçtır. Ardından bu sistemler için yedek lokasyonun nerede olacağına ve felaket anında kullanıcıların oraya nasıl bağlanacağına karar verin.
- Önce dinleriz. Sistemlerinizi iş etkisine göre sıralar, hangilerinin yedek lokasyona ihtiyaç duyduğunu birlikte belirleriz.
- Birlikte planlarız. Hedef lokasyonu, replikasyon yöntemini, ağ bağlantısını ve FortiGate ile güvenli yönlendirmeyi tasarlarız.
- Kurar ve yazılı hâle getiririz. Altyapıyı kurar, yük devretme ve geri dönüş adımlarını anlatan planı hazırlarız.
- Test ederiz, yanınızda kalırız. Planı canlı sistemleri etkilemeden düzenli olarak test eder, sonuçları sizinle paylaşırız.
Testin nasıl yapılacağını felaket kurtarma testi yazımızda anlattık. Kendi yapınızı değerlendirmek için bize ulaşabilirsiniz.


