RPO 15 Dakika Ne Zaman Gerçekten Gerekli?

Felaket kurtarma (Disaster Recovery, DR) planları hazırlanırken en sık düşülen tuzak, tüm sistemler için mümkün olan en agresif hedefi belirlemektir: "Her şey 15 dakika RPO ile korunsun." Kulağa güvenli gelir; ama gereksiz yere pahalıdır ve çoğu zaman kurumun asıl ihtiyacıyla örtüşmez. Doğru yaklaşım, her sistemin gerçek kritikliğini ölçüp ona uygun bir seviye seçmektir.

Bu yazıda RPO ve RTO kavramlarını netleştirip, 15 dakikalık bir kurtarma noktası hedefinin ne zaman gerçekten gerekli, ne zaman israf olduğunu ele alıyoruz.

Önce iki kavram: RPO ve RTO

Bu ikisi sık karıştırılır ama farklı soruları yanıtlar.

RPO (Recovery Point Objective — Kurtarma Noktası Hedefi): "Ne kadar veri kaybını göze alabilirim?" Bir felaket anında en son kurtarabileceğiniz noktanın, olay anından ne kadar geride olduğudur. RPO 15 dakika demek, en fazla son 15 dakikanın verisini kaybedebilirim demektir.

RTO (Recovery Time Objective — Kurtarma Süresi Hedefi): "Ne kadar sürede yeniden ayağa kalkmalıyım?" Sistemin kesintiden sonra tekrar çalışır hale gelmesi için kabul edilebilir azami süredir.

Bu iki hedef bağımsızdır. Bir sistem düşük RPO ama yüksek RTO isteyebilir (veri kaybı kabul edilemez, ama birkaç saat kapalı kalması sorun değil) ya da tam tersi.

RPO'yu düşürmenin maliyeti

RPO ne kadar küçükse, teknoloji o kadar karmaşık ve pahalı olur:

• Günlük yedek (RPO ~24 saat): En ekonomik seviye. Gecelik yedek alınır; bir felakette son yedekten bu yana geçen veri kaybedilir.

• Sık snapshot (RPO ~1–4 saat): Gün içinde birkaç kez alınan snapshot'lar. Orta maliyet, çoğu iş sistemi için yeterli.

• Asenkron replikasyon (RPO ~dakikalar): Veri, ikinci bir lokasyona sürekli ama gecikmeli kopyalanır. 15 dakika RPO genellikle bu kategoriye girer.

• Senkron replikasyon (RPO ~0): Her yazma işlemi iki lokasyonda aynı anda onaylanır. Sıfıra yakın veri kaybı; ama en yüksek maliyet, en düşük coğrafi mesafe toleransı ve performans etkisi.

Görüldüğü gibi RPO'yu 24 saatten 15 dakikaya çekmek, altyapı maliyetini ve karmaşıklığını katlar. Bu yüzden soru "en iyi RPO nedir" değil, "bu sistem için doğru RPO nedir" olmalıdır.

15 dakika RPO ne zaman gerçekten gerekli?

Agresif bir RPO, verinin her dakikasının parayla veya yasal yükümlülükle doğrudan ilişkili olduğu sistemler için haklıdır:

• Finansal işlem sistemleri: Ödeme, bankacılık, borsa işlemleri. Kaybolan her işlem doğrudan parasal kayıp ve mutabakat sorunu demektir.

• E-ticaret sipariş ve stok motoru: Yoğun dönemde 15 dakikalık sipariş verisi kaybı, hem gelir hem müşteri güveni kaybıdır.

• Sağlık kayıt sistemleri: Hasta verisinin kaybı yasal ve etik olarak kabul edilemez.

• Yüksek hacimli üretim/lojistik sistemleri: Sürekli veri üreten, geriye dönük yeniden girilemeyen operasyonlar.

Bu sistemlerin ortak özelliği: veri sürekli, hızlı ve geri konulamaz biçimde üretilir. Böyle bir sistemde 15 dakika (hatta daha düşük) RPO, maliyetine değer.

15 dakika RPO ne zaman israftır?

Aynı hedefi her yere uygulamak, çoğu sistemde parayı boşa harcamaktır:

• Kurumsal web sitesi / tanıtım portalı: İçerik nadiren değişir; gecelik yedek fazlasıyla yeterlidir.

• İç dokümantasyon, intranet, bilgi tabanı: Kaybolan birkaç saatlik değişiklik kolayca yeniden oluşturulabilir.

• Raporlama / analitik ortamları: Veri zaten kaynak sistemlerden yeniden üretilebilir.

• Geliştirme ve test ortamları: Genellikle hiç DR gerektirmez; koddan yeniden kurulabilir.

Bu sistemlere near-sync replikasyon uygulamak, bir bisikleti yarış arabası motoruyla donatmaya benzer: pahalı, gereksiz ve bakımı zor.

Doğru seviyeyi seçmenin yolu: kritiklik analizi

Sistemleri tek tek değerlendirmek yerine bir çerçeve kullanın:

1. İş etki analizi (BIA) yapın. Her sistem için sorun: "Bu 1 saat / 1 gün çalışmazsa ne olur? Son 15 dakikanın / son 24 saatin verisi kaybolsa ne olur?"

1. Sistemleri katmanlara ayırın. Örneğin: Katman 1 (kritik, RPO dakikalar), Katman 2 (önemli, RPO birkaç saat), Katman 3 (standart, RPO 24 saat).

1. Her katmana uygun teknolojiyi eşleştirin. Senkron/asenkron replikasyon yalnızca Katman 1'e; sık snapshot Katman 2'ye; gecelik yedek Katman 3'e.

1. RTO'yu ayrıca değerlendirin. Düşük RPO seçtiğiniz bir sistemin RTO'su da düşük olmalı ki agresif kurtarma noktası anlam kazansın.

1. Test edin. Kağıt üzerindeki RPO/RTO, tatbikatla doğrulanmadıkça bir varsayımdır.

Sonuç: hedefi işe göre belirleyin

"Her şey için en iyi koruma" hem bütçenizi hem operasyon ekibinizi gereksiz yere zorlar; üstelik her şeyi eşit önemde ele almak, gerçekten kritik olanın hak ettiği ilgiyi de dağıtır. Akıllı DR stratejisi, sistemleri kritikliklerine göre katmanlar ve her katmana ölçülü bir koruma uygular. 15 dakikalık RPO, onu hak eden sistemler için güçlü bir kalkandır; geri kalanı için gereksiz bir yüktür.

Network Kurumsal olarak yedekleme ve felaket kurtarma çözümlerimizi tam da bu mantıkla kuruyoruz: önce iş etki analiziyle sistemlerinizi katmanlıyor, sonra her katmana doğru RPO/RTO seviyesini eşleştiriyoruz. Böylece hem gereksiz maliyetten kaçınıyor hem de kritik verinizi hak ettiği seviyede koruyoruz.

DR seviyenizi birlikte doğru belirleyelim: İletişime geçin.

---

Yazar: Mehmet Demir — Veri Merkezi Operasyonları, Network Kurumsal