Rehber · Bulut Teknolojileri
Bulut Yedekleme ile Felaket Kurtarma Arasındaki Fark: RTO, RPO ve İş Sürekliliği
Bulut yedekleme ve felaket kurtarma arasındaki farkları RTO, RPO, geri dönüş testi ve iş sürekliliği açısından açıklayan rehber.
Yayın · Güncelleme · İyi Bilişim
Kısa cevap
Bulut yedekleme verinin bir kopyasını ofis dışında saklar ve 'veriyi geri alabilir miyim?' sorusunu cevaplar. Felaket kurtarma (DR) ise sunucuların, uygulamaların ve bağlantıların belirli bir sürede yeniden çalışır hale gelmesini sağlar ve 'işime ne kadar sürede dönerim?' sorusunu cevaplar. Yedekleme RPO'yu, felaket kurtarma ise RTO'yu yönetir; ikisi birbirinin yerine geçmez.
Bulut yedeklemesi olduğu için 'felaket senaryosuna hazırız' düşüncesinin doğru olup olmadığını anlamak ve iş sürekliliği planına doğru yatırım yapmak isteyen işletmeler için hazırlanmıştır.
- OKRPO kaybedilebilecek veri miktarını, RTO işin durabileceği süreyi tanımlar.
- OKBulutta 2 TB yedeğiniz olsa bile, internetten geri indirmek ve sunucuları yeniden kurmak günler sürebilir.
- OKFelaket kurtarma; çoğaltma, yedek bir çalışma ortamı, ağ planı ve yazılı bir geri dönüş prosedürü gerektirir.
- OKHer sistem için aynı DR seviyesi gerekmez; kritiklik sınıflandırması maliyeti belirler.
'Verilerimiz bulutta yedekli' cümlesi doğru olabilir ama bir felaket anında yöneticinin asıl sorusu farklıdır: Muhasebe programı yarın sabah çalışacak mı? Bu yazı, bulut yedekleme ile felaket kurtarma arasındaki farkı RTO, RPO ve gerçek iş etkisi üzerinden açıklar.
01RPO ve RTO: iki farklı soru
RPO (Recovery Point Objective), olay anında geriye doğru ne kadar veri kaybını kabul edebileceğinizi ifade eder; gece yedeği alan bir işletmenin RPO'su yaklaşık 24 saattir. RTO (Recovery Time Objective) ise sistemlerin yeniden kullanılabilir olması için kabul edilen azami süredir. Bir e-ticaret sisteminin RTO'su 1 saat, arşiv dosya sunucusunun RTO'su 2 gün olabilir. Bu iki değer yönetimle birlikte belirlenmeden alınan her teknoloji kararı ya gereğinden pahalı ya da yetersiz olur.
02Bulut yedekleme neyi sağlar, neyi sağlamaz?
Bulut yedekleme; verinin şifreli bir kopyasını ofis dışında, çoğu zaman sürüm geçmişiyle saklar. Fidye yazılımı, yangın veya donanım arızasında verinin tamamen kaybolmasını önler. Ancak geri dönüş süresini kendi başına kısaltmaz: 1-2 TB verinin standart bir iş yeri internet bağlantısıyla geri indirilmesi saatler, hatta günler sürebilir. Üstüne yeni donanım temini, işletim sistemi kurulumu ve uygulama yapılandırması eklendiğinde fiili kesinti RTO hedeflerini kolayca aşar.
03Felaket kurtarma nedir?
Felaket kurtarma, kritik sistemlerin ana lokasyon kullanılamaz hale geldiğinde alternatif bir ortamda çalıştırılmasıdır. Bu ortam ikinci bir ofis, bir veri merkezi veya bulut platformu (ör. Azure) olabilir. DR'ın bileşenleri; sanal sunucuların düzenli olarak hedef ortama çoğaltılması, hedefte yeterli işlem kapasitesi, kullanıcıların yeni ortama nasıl bağlanacağını belirleyen ağ ve VPN planı, DNS değişiklikleri ve adım adım yazılmış bir geri dönüş prosedürüdür (runbook).
04Seçenekler: yedekten geri yüklemeden sıcak yedeğe
DR seviyeleri maliyete göre kademelenir. Yedekten geri yükleme: en ucuz yöntemdir, RTO günler mertebesindedir. Bulutta doğrudan çalıştırma: bazı yedekleme çözümleri yedeği bulutta sanal makine olarak açabilir; RTO saatlere iner. Çoğaltma (replikasyon) ile sıcak yedek: sunucular dakikalar seviyesinde hedefe kopyalanır, RTO ve RPO dakikalara iner ama sürekli maliyet doğar. DRaaS (hizmet olarak felaket kurtarma) bu altyapıyı bir sağlayıcının işletmesiyle sunar.
05Kritiklik sınıflandırması ile bütçeyi doğru kullanın
Tüm sistemleri en yüksek DR seviyesinde korumak gereksiz maliyettir. Sistemleri üç gruba ayırmak pratik bir yöntemdir: Kritik (ERP, muhasebe veritabanı, kimlik sunucusu; RTO 1-4 saat), önemli (dosya sunucusu, iç uygulamalar; RTO 1 gün) ve ertelenebilir (arşiv, test ortamları; RTO birkaç gün). Kritik sistemler çoğaltma veya bulutta çalıştırma ile, diğerleri klasik yedek ve geri yükleme ile korunur. Bu yaklaşım hem bütçeyi hem de test yükünü yönetilebilir tutar.
06Bağımlılıkları unutmayın
Bir uygulamayı DR ortamında açmak, kullanıcıların onu kullanabileceği anlamına gelmez. ERP sunucusu Active Directory'ye, lisans sunucusuna ve veritabanına bağlıysa hepsi doğru sırayla ayağa kalkmalıdır. Kullanıcılar evden veya geçici bir lokasyondan nasıl bağlanacak, IP adresleri değişecek mi, e-posta ve telefon hizmetleri nasıl yönlendirilecek gibi sorular runbook'ta cevaplanmalıdır. Bağımlılık haritası çıkarılmadan yapılan DR planı genellikle ilk testte eksik çıkar.
07Test etmeyen felaket planı yalnızca bir belgedir
DR planı yılda en az bir kez, mümkünse altı ayda bir canlı sistemi etkilemeyen izole bir testle denenmelidir. Testte ölçülmesi gerekenler: sistemlerin açılma süresi, verinin hangi ana kadar güncel olduğu, kullanıcı erişiminin çalışıp çalışmadığı ve ana sisteme geri dönüş (failback) adımlarıdır. Ölçülen süreler hedef RTO ve RPO ile karşılaştırılır, farklar bir sonraki dönemde kapatılacak aksiyonlar olarak kaydedilir.
Uygulama kontrol listesi
- OKKritik sistemler için RPO ve RTO yönetimle birlikte yazıldı mı?
- OKSistemler kritik, önemli ve ertelenebilir olarak sınıflandırıldı mı?
- OKBüyük veri setlerinin buluttan geri dönüş süresi hesaplandı mı?
- OKAlternatif çalışma ortamı (bulut, ikinci lokasyon) belirlendi mi?
- OKUygulama bağımlılıkları ve açılış sırası belgelendi mi?
- OKKullanıcı erişimi, VPN ve DNS değişiklikleri runbook'ta yazılı mı?
- OKSon DR testi tarihi ve ölçülen süreler kayıtlı mı?
Sık yapılan hatalar
- WARNBulut yedeği olduğu için felaket kurtarma planına gerek görmemek
- WARNRTO hedefini teknik ekibin tahminine bırakmak
- WARNGeri dönüş süresini internet hızıyla hiç hesaplamamak
- WARNDR ortamında kimlik ve DNS bağımlılıklarını unutmak
- WARNAna sisteme geri dönüş (failback) adımlarını planlamamak
Sık sorulan sorular
Küçük bir işletme için felaket kurtarma gerekli mi?
Gerekli olan, en azından kritik sistemlerin ne kadar sürede geri döneceğinin bilinmesidir. Birkaç kullanıcılı bir ofiste bu, yedekten bulutta sanal makine açabilen bir çözüm ve yazılı bir prosedürle düşük maliyetle sağlanabilir.
RTO ve RPO değerlerini kim belirlemeli?
Teknik ekip seçenekleri ve maliyetleri sunar; kabul edilebilir kesinti ve veri kaybı ise iş tarafının kararıdır. Bir saatlik kesintinin satış, üretim veya itibar maliyeti bu kararın temelidir.
Azure felaket kurtarma için kullanılabilir mi?
Evet. Azure Site Recovery ile şirket içi sanal sunucular Azure'a çoğaltılabilir ve gerektiğinde orada çalıştırılabilir. Kullanılmadığı dönemde çoğunlukla depolama ve çoğaltma maliyeti oluşur; işlem kapasitesi yalnızca devreye alındığında ücretlendirilir.
Felaket kurtarma testi canlı sistemi etkiler mi?
Doğru tasarlanmış testler izole bir ağda yapılır ve canlı sistemi etkilemez. Test planında hangi sistemlerin, hangi ağda ve kimin onayıyla açılacağı önceden yazılmalıdır.