RPO ve RTO tam olarak neyi ölçer?
RPO ve RTO, felaket kurtarma tasarımının iki temel hedefidir ve farklı sorulara cevap verir. RPO (Recovery Point Objective · kurtarma noktası hedefi) "en fazla ne kadarlık veri kaybını göze alabiliriz?" sorusunu yanıtlar; pratikte son geçerli yedeğe ne kadar geriye dönülebileceğini gösterir. RTO (Recovery Time Objective · kurtarma süresi hedefi) ise "hizmet ne kadar sürede yeniden ayakta olmalı?" sorusunu yanıtlar.
Bir örnekle: RPO 15 dakika ise, kesinti anındaki son 15 dakikanın verisi yeniden girilmeyi gerektirebilir. RTO 2 saat ise, sistemin kesintiden sonra en geç 2 saat içinde çalışır durumda olması hedeflenir. İkisi birlikte, bir kesintinin işe maliyetini somut zaman ölçüsüne çevirir.
Bu hedefler nasıl belirlenir?
Hedefler iş etki analiziyle (Business Impact Analysis) belirlenir. Bu analiz, her uygulama ve veri kümesi için kesintinin iş üzerindeki etkisini zaman ölçeğinde değerlendirir: bir saat kesinti neye mal olur, bir gün neye mal olur? Cevaplar, sistemleri kritiklik katmanlarına yerleştirir.
- Kritik katman: Gelir üreten, müşteriye dokunan ya da yasal yükümlülük taşıyan sistemler; en sıkı RPO ve RTO hedeflerini alır.
- Önemli katman: İş sürekliliği için gerekli, ancak kısa gecikmeyi tolere edebilen sistemler; orta seviye hedeflerle korunur.
- Standart katman: İç raporlama, arşiv ve destek nitelikli sistemler; daha esnek hedeflerle ve daha ekonomik yöntemlerle korunur.
Bu katmanlama, koruma bütçesinin işin gerçek önceliğine göre dağılmasını sağlar. Her sisteme aynı sıkı hedefi vermek yerine, yatırım en yüksek getiriyi ürettiği yere yoğunlaştırılır.
Hedefler mimariyi nasıl şekillendirir?
Belirlenen RPO ve RTO, doğrudan teknik tasarıma dönüşür. Sıkı bir RPO, yedekleme sıklığını ve çoğaltma yöntemini belirler: günlük yedek dakikalar düzeyinde bir RPO için yeterli olmaz, senkron ya da sık aralıklı çoğaltma gerekir. Sıkı bir RTO ise kurtarma yönteminin hızını belirler: yedekten geri yükleme mi, yoksa hazır bekleyen bir kopyaya devretme mi.
Bu yüzden RPO ve RTO, yedekleme ve felaket kurtarma kurgusunun girdisidir. Hedefler önce netleşir; mimari sonra bu hedefleri karşılayacak şekilde kurulur. Bu sıralama, hem eksik korumayı hem de gereğinden pahalı çözümü önler.
Sahada en sık gördüğümüz durum, hedeflerin hiç yazılı olmamasıdır: yedek alınır, ancak "ne kadar veri kaybını ve ne kadar kesintiyi kabul ediyoruz?" sorusu hiç sorulmamıştır. İş etki analizini birlikte yaptığımızda çoğu kurum, sistemlerinin büyük bölümünün aslında esnek bir katmana ait olduğunu, yalnızca birkaç sistemin sıkı hedef gerektirdiğini görüyor. Bu netlik, hem koruma açığını kapatıyor hem de bütçeyi doğru yere yönlendiriyor.
Hedefler ne sıklıkla gözden geçirilir?
RPO ve RTO, iş değiştikçe değişen hedeflerdir. Yeni bir uygulama devreye alındığında, bir sistem daha kritik hâle geldiğinde ya da veri hacmi büyüdüğünde hedefler yeniden değerlendirilir. Düzenli felaket kurtarma tatbikatları, belirlenen hedeflerin gerçekte karşılanıp karşılanmadığını doğrular ve tasarımdaki boşlukları görünür kılar.
Bu hedefleri, yedekleme ve felaket kurtarma kurgusunun temeli olarak belirliyor; toparlanmayı hizmet olarak sağlayan DRaaS seçeneğini ise ayrı bir notta ele alıyoruz. Tümü, veri merkezi ve sistem mimarisinin parçasıdır.
