RTO ve RPO, bir kesintiden sonra ne kadar sürede ayağa kalkacağınızı ve ne kadar veriyi kaybetmeyi göze aldığınızı tanımlayan iki hedef. Sık karıştırılırlar ama farklı şeyleri ölçerler: biri zaman, diğeri veri.
İkisi arasındaki fark
RTO (Recovery Time Objective) süreyi ölçer: kesinti anından sistemin yeniden çalışır hale gelmesine kadar geçen kabul edilebilir zaman. Dört saatlik bir RTO, en kötü durumda dört saat hizmet veremeyeceğinizi göze aldığınız anlamına gelir.
RPO (Recovery Point Objective) veriyi ölçer: kabul edilebilir azami veri kaybı. On beş dakikalık bir RPO, en kötü durumda son on beş dakikanın verisinin kaybolabileceği anlamına gelir.
Bir örnekle: yedeğiniz gece yarısı alınıyorsa ve sistem öğlen çöküyorsa, RPO'nuz gerçekte on iki saattir; sabahtan öğlene kadar girilen her şey gider. Sistemi geri yüklemek üç saat sürüyorsa RTO'nuz üç saattir. İki ölçüt birbirinden bağımsızdır: kısa RTO'lu ama uzun RPO'lu bir kurulum mümkündür, tersi de.
Nasıl belirlenir
Bu iki sayıyı teknik ekip belirlemez. Belirleyen şey işin kendisidir. Sorulacak soru şu: bu sistem çalışmadığında saatte ne kaybediyorsunuz, ve kaybolan son yarım saatlik veri geri getirilemezse ne olur?
Cevap her sistem için farklı çıkar. Bir sipariş veri tabanının on beş dakikalık kaybı ciddi bir sorundur; bir raporlama ortamının bir günlük kaybı çoğu zaman kabul edilebilir. Bu yüzden tek bir kurumsal RTO ve RPO yerine sistem bazında hedefler belirlemek daha gerçekçi.
Uygulamada sıkça karşılaştığımız durum, herkesin en kısa süreyi istemesi ve maliyeti görünce geri adım atması. Bu normal; asıl amaç sayıyı küçültmek değil, hangi sistemin hangi hedefi hak ettiğine bilinçli karar vermek.
Hedefi sıkılaştırmanın maliyeti
RPO'yu kısaltmak, yedekleme sıklığını ve çoğaltma yoğunluğunu artırmak demek. Gecelik yedekten sürekli çoğaltmaya geçmek hem depolama hem bant genişliği hem de işletim maliyeti ekler.
RTO'yu kısaltmak, yedek ortamın hazır bekletilmesi demek. Yedekten sıfırdan kurmak ucuz ama yavaştır; kapasitesi hazır bekleyen bir yedek ortam hızlıdır ama kullanılmadığı sürece de para harcar.
Bu yüzden hedefleri kademelendirmek işe yarıyor: kritik sistemler için kısa, ikincil sistemler için gevşek. Hepsini aynı seviyeye çekmek, en pahalı ve en az gerekli seçenek.
Bizim hedeflediğimiz değerler
Felaket kurtarma hizmeti alan müşteriler için hedeflediğimiz değerler şunlar: RPO 15 dakika; birincil kurtarma yolunun kullanılamadığı durumlarda devreye giren saha dışı yedekleme için bu değer 24 saat. RTO kritik sunucular için 1 saat, kapsamdaki sunucuların tamamı için 2 saat.
Bunlar hedef niteliğindedir ve teknik makullük çerçevesinde uygulanır; kapsam ile değerler sözleşmenizde tanımlanır. Metnin tamamını SLA politikamızda bulabilirsiniz. Hizmetin kapsamı için Disaster Recovery as a Service sayfasına bakabilirsiniz.
Yedekler ayrı bir depolama sisteminde, saklama süresi boyunca değiştirilemez biçimde tutulur; fidye yazılımı bulaşsa dahi silinemez veya şifrelenemez. Yedekleme planı ve saklama süresinin nasıl belirlendiği Backup as a Service sayfasında.
Yedekleme sıklığı ile RPO aynı şey değil
Yaygın bir varsayım var: "saatte bir yedek alıyoruz, demek ki RPO'muz bir saat." Bu çoğu zaman doğru değil. Yedeğin alınmış olması, ondan geri dönülebileceğini garanti etmiyor. Yedek bozuksa, eksikse ya da geri yükleme hiç denenmemişse gerçek RPO son doğrulanmış yedeğe kadar geriye gidiyor.
İkinci bir incelik daha var: yedeğin alındığı an ile verinin tutarlı olduğu an aynı olmayabilir. Çalışan bir veri tabanının diskini olduğu gibi kopyalamak, yarım kalmış işlemleri de kopyalar. Geri yüklendiğinde veri teknik olarak oradadır ama uygulama açısından tutarsızdır. Bu yüzden veri tabanı yedekleri uygulamanın kendi tutarlı yedek mekanizmasıyla alınır.
Bu iki nokta, RPO'yu bir yedekleme ayarı değil bir doğrulama meselesi haline getiriyor. Sıklığı artırmak kolay; alınan yedeğin gerçekten geri dönülebilir olduğunu düzenli olarak kanıtlamak asıl iş.
Tatbikat yapılmayan hedef, hedef değildir
En sık karşılaştığımız durum bu: yedekler alınıyor, hedefler yazılı, ama geri dönüş hiç denenmemiş. Denenmemiş bir kurtarma planı, çalıştığı varsayılan bir plandır ve varsayım ilk gerçek olayda test edilir.
Felaket kurtarma senaryosunu yılda iki kez, çalışan sistemleri kesintiye uğratmadan test ediyor ve sonucu raporluyoruz. Tatbikatın çıktısı yalnızca "çalıştı" değil, gerçekte ne kadar sürdüğü. Ölçülen süre ile hedeflenen süre arasındaki fark, planın nerede düzeltilmesi gerektiğini gösteriyor.
Kubernetes tarafında bu işin ayrı bir boyutu var: 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.
Yedekleme ile felaket kurtarmanın aynı şey olmadığını bu karşılaştırmada açtık; terimlerin kısa tanımları için sözlüğe bakabilirsiniz.