"Yedeğimiz var" cümlesini çok duyuyoruz ve arkasından gelen soru genelde cevapsız kalıyor: yedekten dönmek ne kadar sürüyor? Yedekleme veriyi korur, felaket kurtarma hizmetin devamlılığını korur. İkisi farklı sorulara cevap veriyor ve çoğu kurumda ikisine birden ihtiyaç var.
Kısa cevap
Silinen bir dosyayı, bozulan bir tabloyu ya da yanlış giden bir güncellemeyi geri almak istiyorsanız yedekleme. Bütün bir ortam kullanılamaz hale geldiğinde hizmeti başka bir yerde ayağa kaldırmanız gerekiyorsa felaket kurtarma. Yedekleme olmadan felaket kurtarma kurulmaz; felaket kurtarma olmadan yedekleme uzun kesinti demektir.
Karşılaştırma tablosu
| Ölçüt | Yedekleme (BaaS) | Felaket kurtarma (DRaaS) |
|---|---|---|
| Neyi korur | Veriyi | Çalışır durumu, veriyle birlikte |
| Tipik senaryo | Yanlışlıkla silme, bozulma, hatalı güncelleme | Ortamın tamamının kullanılamaz hale gelmesi |
| Geri dönüş süresi | Veri hacmine bağlı, saatler sürebilir | Hedeflenen RTO içinde |
| Veri kaybı | Son yedeğe kadar | Hedeflenen RPO içinde |
| Yedek ortam | Yok, geri yükleme mevcut ortama yapılır | Var, ayrı konumda hazır |
| Tatbikat | Geri yükleme testi | Tam senaryo tatbikatı |
| Maliyet | Daha düşük | Yedek ortam bekletildiği için daha yüksek |
Yedekleme ne zaman yeter
Kesintiye toleransınız saatler mertebesindeyse ve ortamın tamamının birden kaybolması gerçekçi bir senaryo değilse yedekleme tek başına yeterli olabilir. İç sistemler, raporlama ortamları ve geliştirme altyapıları genelde bu grupta.
Yedeklerin nerede ve nasıl durduğu burada belirleyici. Bizde yedekler ayrı bir depolama sisteminde, belirlenen saklama süresi boyunca değiştirilemez biçimde tutuluyor; sisteminize fidye yazılımı bulaşsa dahi yedekler silinemez veya şifrelenemez. Aynı sunucuda duran bir yedek, yedek sayılmaz. Ayrıntı için Backup as a Service sayfasına bakabilirsiniz.
Felaket kurtarma ne zaman gerekli
Hizmetin durması saatlik olarak ölçülebilir bir kayıp üretiyorsa felaket kurtarma gerekiyor. Fark şurada: yedekten dönmek, boş bir ortam kurup veriyi geri yüklemek demek ve bu süre veri hacmiyle birlikte büyüyor. Felaket kurtarmada yedek ortam hazır bekliyor, dolayısıyla geri dönüş süresi veri hacminden büyük ölçüde bağımsız.
Hedeflediğimiz değerler şunlar: RPO 15 dakika, saha dışı yedekleme devreye girdiğinde 24 saat; RTO kritik sunucularda 1 saat, kapsamdaki tüm sunucularda 2 saat. Bunlar hedef niteliğinde ve kapsam sözleşmede tanımlanıyor. Bu iki ölçütün ne anlama geldiğini RTO ve RPO nedir sayfasında, hizmetin kapsamını Disaster Recovery as a Service sayfasında bulabilirsiniz.
İkisi birlikte nasıl kurgulanıyor
Pratikte sistemler kademelendiriliyor. Hizmetin durmasının doğrudan maliyeti olan sistemler felaket kurtarma kapsamına giriyor; geri kalanlar için yedekleme yeterli sayılıyor. Her sistemi en yüksek seviyeye çekmek en pahalı ve çoğu zaman gereksiz seçenek.
Kapsam belirlenirken sorduğumuz soru şu: bu sistem iki saat çalışmazsa ne olur, ve son on beş dakikanın verisi kaybolursa ne olur? Cevaplar sistemden sisteme değiştiği için tek bir kurumsal seviye yerine sistem bazlı hedefler belirlemek daha gerçekçi sonuç veriyor.
Maliyeti neye göre kıyaslamalı
Felaket kurtarma, yedeklemeden pahalı. Bunun sebebi yedek ortamın hazır bekletilmesi: kullanılmadığı sürece de kapasite ayrılmış oluyor. Bu farkı değerlendirirken bakılacak sayı, hizmetin durmasının saatlik maliyeti.
Hesap basit: sistemin bir saat durmasının kaça mal olduğunu bulun, yedekten dönmenin tahmini süresiyle çarpın. Çıkan sayı, felaket kurtarmanın yıllık bedeliyle karşılaştırılabilir hale geliyor. Çoğu kurumda bu hesap birkaç kritik sistem için felaket kurtarmayı, geri kalan için yedeklemeyi işaret ediyor.
Hesabın en çok atlanan kısmı, kesintinin doğrudan gelir kaybı dışındaki maliyetleri: müşteri desteğine binen yük, sözleşmesel yükümlülükler ve kurtarma sırasında başka işe bakamayan ekip. Bunlar da saatlik maliyetin parçası.
Sık yapılan hata
Yedeği felaket kurtarma sanmak. En yaygın hata bu. Yedek varken bile ortamın sıfırdan kurulması gerekiyorsa kesinti süresi saatlerle ölçülür ve bu, çoğu ekibin beklediğinden uzun çıkar.
Geri dönüşü hiç denememek. Denenmemiş bir kurtarma planı, çalıştığı varsayılan bir plandır. Felaket kurtarma senaryosunu yılda iki kez, çalışan sistemleri kesintiye uğratmadan test ediyor ve sonucu raporluyoruz. Tatbikatın asıl çıktısı "çalıştı" değil, gerçekte ne kadar sürdüğü.
Kubernetes tarafında cluster durumunu unutmak. Uygulama verisi geri gelse bile cluster durumu gelmezse kurtarma yarım kalıyor. Nedenini etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık.
Taahhüt metninin tamamı için SLA politikasına, terimlerin kısa tanımları için sözlüğe bakabilirsiniz.
Nereden başlayacağınızı bilmiyorsanız en basit adım şu: elinizdeki en kritik sistem için bir geri yükleme denemesi yapın ve süreyi ölçün. Çıkan sayı, felaket kurtarmaya ihtiyacınız olup olmadığını çoğu tartışmadan daha net gösteriyor. Bu denemeyi birlikte de yapabiliriz; kapsam belirlemenin ilk adımı zaten budur. Ölçülen süre beklediğinizden uzun çıkarsa, sorun genelde yedeklemede değil geri yükleme yolunda oluyor.