Bir kesinti planlaması yapılırken iki ayrı soru sorulur ve sık sık tek soruymuş gibi ele alınır. Oysa farklı şeyleri ölçerler, farklı teknolojiler gerektirirler ve maliyetleri birbirinden bağımsızdır.
İki tanım
RPO (kurtarma noktası hedefi) geriye bakar: olaydan önceki hangi ana dönebilirsiniz? Yani ne kadar veri kaybını göze alıyorsunuz.
RTO (kurtarma süresi hedefi) ileriye bakar: hizmet ne kadar sürede yeniden çalışır? Yani ne kadar kesintiyi göze alıyorsunuz.
Somut örnek: gece 02:00’de yedek alan bir sistemde saat 16:00’da arıza olursa 14 saatlik veri kaybedilir — bu RPO’dur. Geri yükleme 6 saat sürerse kesinti 6 saattir — bu RTO’dur. İkisi birbirinden bağımsızdır.
RPO neyi belirler
RPO doğrudan yedekleme sıklığını ve teknolojiyi belirler. Merdiven kabaca şöyledir.
Günlük yedek 24 saatlik RPO verir. Saatlik artımlı yedek bir saate iner. Günlük nakli ya da sürekli anlık görüntü dakikalara indirir. Eşzamansız çoğaltma saniyelere iner. Sıfır kayıp isteniyorsa eşzamanlı çoğaltma gerekir.
Aşağı indikçe maliyet ve karmaşıklık artar. Sıfır RPO ise fiziğe çarpar: eşzamanlı çoğaltmada her yazma ikinci sitenin onayını bekler ve mesafe doğrudan gecikmeye yansır.
Bu merdiveni kendi rakamlarınızla görmek için kurtarma hedefi planlayıcı aracını kullanabilirsiniz.
RTO sandığınızdan uzundur
En yaygın hata, RTO’yu yalnızca geri yükleme süresi sanmaktır. Oysa saat, olay olduğunda başlar ve kullanıcı yeniden çalışabildiğinde durur.
Arada altı adım vardır: olayın fark edilmesi, onarma mı devralma mı kararının verilmesi, hedef ortamın hazırlanması, verinin geri yüklenmesi, sonucun doğrulanması ve kullanıcıların yeni adrese yönlendirilmesi.
Geri yükleme çoğu zaman bunların yalnızca yarısıdır. Nöbet düzeni zayıfsa fark etme süresi tek başına en büyük kalem olabilir. DNS TTL uzunsa yönlendirme saatler alabilir.
Bu yüzden “dört saatte ayağa kalkarız” cümlesi, altı adımın toplamı hesaplanmadan söylendiğinde neredeyse her zaman iyimserdir.
Çoğaltma yedek değildir
Sıfır RPO isteyen kurumların düştüğü tuzak budur. Eşzamanlı çoğaltma bir donanım arızasına karşı korur — ama silinen bir tabloyu, şifreleyen bir fidye yazılımını ya da bozuk bir dağıtımı anında ikinci siteye kopyalar.
Yani çoğaltma, mantıksal hatalara karşı hiçbir koruma sağlamaz. Geriye dönüş yalnızca yedekten yapılır.
Pratik sonuç: düşük RPO isteyen her sistemin ayrıca geriye dönülebilir ve tercihen değiştirilemez bir yedeği olmalıdır. Fidye yazılımı zincirinde yedeklerin neden önce hedef alındığı fidye yazılımı nasıl bulaşır yazısında.
Her sistem aynı hedefi hak etmez
Tüm sistemlere sıfır RPO ve on beş dakikalık RTO vermek teknik olarak mümkündür ama maliyeti karşılanamaz.
Doğru yaklaşım katmanlamadır: sistemleri iş etkisine göre gruplayın ve her gruba ayrı hedef verin. Ödeme alan sistem ile iç raporlama aracı aynı sınıfta olmamalıdır.
Bu ayrım aynı zamanda bir olay anında hangi sırayla kurtarılacağını da belirler — ki o sıralama, plan yazılırken en çok atlanan şeydir.
Hedefleri iş birimiyle konuşmanın yolu RPO ve RTO’yu iş birimiyle konuşmak rehberinde.
Bağımlılık zinciri
Bir uygulamanın RTO’su, bağımlı olduğu her şeyin RTO’sundan uzundur.
Uygulama dört saatte dönüyor ama kimlik sağlayıcısı sekiz saatte dönüyorsa gerçek RTO sekiz saattir. Aynı şey DNS, sertifika yetkilisi, lisans sunucusu ve dosya paylaşımı için de geçerlidir.
Bu yüzden hedefler sistem başına değil hizmet zinciri başına belirlenmelidir. Zinciri çıkarmak, plan yazmanın ilk adımıdır.
Hesap değil ölçüm
Kâğıt üzerindeki geri yükleme hızı neredeyse her zaman iyimserdir. Yedek deposunun okuma hızı, ağ, hedef diskin yazma hızı ve çok sayıda küçük dosyanın birer birer yazılması — hepsi düşürür.
Tek gerçek yöntem tatbikattır: yılda en az bir kez gerçek bir geri yükleme yapıp süreyi ölçmek. O ölçüm, tahminin yerini alır.
Kapasite tarafındaki hesap için yedekleme kapasitesi, aktarım süresi için aktarım süresi aracı var. Geri dönüşün test edilmemesinin bedeli Azure Backup: geri dönüşü test etmeden yedek saymayın rehberinde.
Kısaca
RPO veri kaybını, RTO kesintiyi ölçer. RPO yedekleme sıklığını ve çoğaltma teknolojisini belirler; RTO ise altı adımın toplamıdır ve geri yükleme bunun yalnızca bir parçasıdır.
İkisini de her sisteme aynı sıkılıkta uygulamayın, bağımlılık zincirini hesaba katın ve rakamları tahminle değil tatbikatla doğrulayın.