Etki Analizi ve RTO/RPO
Hangi sistemin kaç saat durabileceğini ve ne kadar veri kaybını kaldırabileceğini iş birimleriyle birlikte belirleriz. Tüm tasarım bu iki rakamın üzerine kurulur.
Felaket Kurtarma
Veri geri gelir, peki iş ne zaman başlar?
Yedeğiniz sağlam olabilir; ancak sunucular, ağ ve uygulamalar yoksa veri tek başına iş üretmez. Felaket kurtarma, veriyi değil çalışma ortamının tamamını ikinci bir lokasyonda ayağa kaldırmakla ilgilidir. Ölçüsü de tek bir rakamdır: ne kadar sürede yeniden iş yapabiliyorsunuz?
Neden Önemli?
Yedekten dönmek günler sürebilir.
Bir veri merkezini kaybettiğinizde sıra yedekten dönmeye geldiğinde iş çoktan durmuştur. Sunucuları yeniden kurmak, ağı ayağa kaldırmak, terabaytlarca veriyi geri yazmak ve uygulamaları doğru sırayla başlatmak günler alabilir. Çoğu kurum için asıl maliyet kaybolan veri değil, o günlerdir.
Felaket kurtarma bu süreyi baştan kısaltmakla ilgilidir: kritik sistemler ikinci bir lokasyona sürekli kopyalanır, geçiş adımları önceden yazılır ve düzenli tatbikatla denenir. Veluva bu yapıyı kurumun gerçek RTO hedefine göre kurgular; ikinci veri merkezi yatırımı yapamayan kurumlar için bulut tabanlı, kullanıldıkça ödenen bir model tasarlarız.
-
Ölçülmüş RTO
Kurtarma süresi tahmin değil, tatbikatla kayda geçmiş bir rakamdır.
-
Yatırımsız ikinci lokasyon
Bulut tabanlı DR ile ikinci veri merkezi kurmadan koruma sağlanır.
-
Yazılı geçiş planı
Kriz anında kimin ne yapacağı, hangi sırayla, önceden bellidir.
Yetenekler
Planı değil, çalıştığı kanıtlanmış bir yapıyı teslim ederiz.
Replikasyondan tatbikata kadar felaket kurtarmanın tüm bileşenlerini kurar ve düzenli olarak doğrularız.
Sürekli Replikasyon
Kritik sanal makineleri ve verileri ikinci lokasyona sürekli kopyalarız. Dakikalar mertebesinde RPO gerektiren sistemlerde blok düzeyinde replikasyon kullanılır.
Bulut Tabanlı DR
İkinci veri merkezi yatırımı yerine Azure Site Recovery gibi çözümlerle bulutta bekleyen bir kurtarma ortamı kurarız. Kaynak yalnızca felaket ya da tatbikat anında ücretlendirilir.
Uygulama Sırası ve Bağımlılık
Sistemleri doğru sırayla ayağa kaldırırız: önce dizin ve veritabanı, sonra uygulama katmanı. Bağımlılıklar haritalanmazsa geçiş yarıda takılır.
Ağ ve Erişim Geçişi
Kullanıcıların ikinci lokasyona nasıl bağlanacağını, DNS ve yönlendirme değişikliklerini önceden tasarlarız. Sunucular çalışsa da erişim yoksa iş başlamaz.
Tatbikat ve Raporlama
Failover senaryosunu üretimi etkilemeden izole biçimde çalıştırır, süreyi ölçer ve aksayan adımları düzeltiriz. Sonuç, yönetime sunulabilir bir raporla belgelenir.
Ne Zaman İhtiyaç Duyarsınız?
Felaket kurtarma planı için tipik işaretler.
Aşağıdakilerden biri bile tanıdık geliyorsa, bir veri merkezi kaybında ne olacağı bugün belirsiz demektir. Kısa bir değerlendirmeyle gerçek kurtarma sürenizi ortaya çıkarabiliriz.
- Tüm sunucularınız tek bir lokasyonda duruyor.
- Bir gün kesinti iş açısından kabul edilemez.
- Felaket planı var ama hiç denenmemiş.
- Sistemlerin hangi sırayla açılacağını yalnızca birkaç kişi biliyor.
- Müşteri ya da denetçi süreklilik planı belgesi talep ediyor.
- İkinci veri merkezi yatırımı bütçeyi aşıyor.
Nasıl Kuruyoruz
Kâğıt üzerinde plan değil, denenmiş bir geçiş.
Felaket kurtarmayı dört adımda kurar; teslimden önce en az bir kez gerçekten çalıştırırız.
01
Etki Analizi
Kritik sistemler, bağımlılıklar ve RTO/RPO hedefleri belirlenir.
02
Tasarım
İkinci lokasyon, replikasyon yöntemi ve geçiş adımları planlanır.
03
Kurulum
Replikasyon devreye alınır, geçiş planı yazılır ve otomatikleştirilir.
04
Tatbikat
Failover izole ortamda denenir, süre ölçülür, plan güncellenir.
Öne Çıkan Platformlar
Markadan değil, kurtarma hedefinden başlarız.
Felaket kurtarma platformlarında sertifikalı deneyime sahibiz. Doğru çözümü RTO hedefiniz, veri hacminiz ve bütçeniz belirler.
- Azure Site Recovery
- Veeam Replication
- Zerto
- VMware
- Commvault
Sık Sorulanlar
Merak edilenler
Yedeğimiz var, ayrıca felaket kurtarmaya gerek var mı?
Yedek veriyi geri getirir; ancak sunucuları kurmak, ağı ayağa kaldırmak ve terabaytları geri yazmak günler sürebilir. Bu süre işiniz için kabul edilebilirse yedekleme yeterlidir. Değilse, sistemlerin ikinci lokasyonda hazır beklediği bir yapı gerekir. Kararı biz değil, kabul ettiğiniz kesinti süresi verir.
İkinci bir veri merkezi kurmamız gerekir mi?
Hayır. Bulut tabanlı felaket kurtarma tam da bu yatırımı gereksiz kılar. Sanal makineleriniz buluta sürekli kopyalanır ama çalışır durumda beklemez; ciddi bir maliyet oluşturmadan hazır durur. Kaynak yalnızca gerçek felaket ya da tatbikat anında ücretlendirilir.
Tatbikat üretimi etkiler mi?
Hayır. Tatbikatı izole bir ağda çalıştırırız: sistemler kurtarma ortamında ayağa kalkar, açılış ve veri doğrulanır, süre ölçülür; üretim tarafında hiçbir şey değişmez. Bu, gerçek kesinti anına hazırlanmanın tek dürüst yoludur.
Tüm sistemleri kapsama almak zorunda mıyız?
Hayır ve genellikle gerekmez. Kritik sistemleri kapsama alır, kalanını daha uzun kurtarma süresiyle yedekten dönecek şekilde bırakırız. Her sistemi en yüksek koruma seviyesine almak, çoğu kurum için gereksiz maliyet demektir.
Failover kararını kim verir?
Bu teknik değil, iş kararıdır ve kriz anında tartışılmamalıdır. Planda karar verme yetkisinin kimde olduğunu, hangi eşikte devreye gireceğini ve iletişimin nasıl yürüyeceğini önceden tanımlarız.
Felaket geçtikten sonra geri dönüş nasıl oluyor?
Failback de planın parçasıdır ve çoğu kurumun atladığı yer burasıdır. İkinci lokasyonda üretilen veriyi kaybetmeden birincil sisteme geri dönmeyi tasarlar, bu adımı da tatbikat kapsamında denemeyi öneririz.
İlgili Çözümler
Kurtarmayı tamamlayan katmanlar
Sonraki Adım
Kurtarma sürenizi tahminden çıkaralım.
Kısa bir değerlendirmeyle kritik sistemlerinizi, hedef kurtarma sürenizi ve bugünkü gerçek durumunuzu karşılaştıralım. Bağlayıcı taahhüt yok.