İş sürekliliği konuşmalarının tamamı er ya da geç iki kısaltmaya gelir: RTO ve RPO. İkisi de teknik terim gibi görünür ama aslında birer iş kararıdır — ve bu kararı BT departmanı tek başına veremez.
İki tanım, iki farklı soru
RPO (Recovery Point Objective) — "ne kadar veri kaybını kabul edebiliriz?" Zaman olarak ölçülür ve geriye bakar: son yedek ya da son replikasyon anıyla kesinti anı arasındaki fark. RPO'nuz 1 saatse, en kötü durumda son 1 saatin verisini kaybedersiniz.
RTO (Recovery Time Objective) — "ne kadar süre çalışamadan kalabiliriz?" İleriye bakar: kesintinin başlangıcıyla sistemin yeniden kullanılabilir hâle gelmesi arasındaki süre.
Bunları karıştırmamanın kolay yolu: RPO geçmişte ne kadar kaybettiğinizi, RTO gelecekte ne kadar bekleyeceğinizi söyler.
Neden BT kararı değil, iş kararı?
Çünkü ikisinin de cevabı "sıfır" olmak ister ama sıfıra yaklaşmanın maliyeti üstel olarak artar. Günlük yedekten saatlik yedeğe geçmek belirli bir maliyettir; saatlikten sürekli replikasyona geçmek başka bir ligdir.
Bu yüzden doğru soru "en iyi RTO nedir?" değil, şudur: bir saatlik kesinti bize kaça mal olur? Cevabı bilen bir işletme, ne kadar harcayacağına kolay karar verir. E-ticaret sitesi için saatlik maliyet yüksektir; ayda bir çalışan bir raporlama sunucusu için düşüktür.
Her sistem aynı RTO'yu hak etmez
En sık gördüğümüz hata, tüm sistemlere tek bir hedef koymak. Oysa sistemler katmanlanmalı:
- Kritik. Durduğunda iş durur — sipariş sistemi, üretim takibi, ana veritabanı. Kısa RTO, dakikalar mertebesinde RPO.
- Önemli. Bir gün olmadan idare edilir ama zorlanır — dosya sunucusu, iç uygulamalar.
- Destekleyici. Birkaç gün beklenebilir — test ortamları, arşiv.
Bu katmanlama, bütçeyi doğru yere koymanızı sağlar. Her şeyi kritik ilan etmek, pratikte hiçbir şeyi kritik ilan etmemekle aynı sonucu verir.
RTO hesabında unutulan kalemler
RTO'yu yalnızca "veriyi geri yükleme süresi" sanmak, hedefi baştan kaçırmaktır. Gerçek süre şunların toplamıdır:
- Kesintinin fark edilmesi — izleme yoksa bu süre saatlere çıkabilir.
- Karar verilmesi — "DR'a geçelim mi?" kararını kim, hangi yetkiyle verir?
- Sistemlerin ayağa kaldırılması — doğru sırayla: kimlik doğrulama, veritabanı, sonra uygulama.
- Doğrulama — sistem açıldı ama gerçekten çalışıyor mu?
- Kullanıcıların yönlendirilmesi — DNS, VPN, entegrasyonlar.
Bu adımların hepsi ölçülmediği sürece RTO bir tahmindir. Ölçmenin tek yolu tatbikattır — bir DR tatbikatında saat saat ne yaşandığını ayrı bir yazıda anlattık.
Hedefe teknoloji nasıl bağlanır?
Belirlediğiniz RPO ve RTO, doğrudan mimariyi seçer:
- RPO 24 saat → gecelik tam yedek yeterlidir.
- RPO birkaç saat → gün içi artımlı yedek gerekir.
- RPO dakikalar → sürekli replikasyon şarttır; yedekleme tek başına yetmez.
- RTO günler → yedekten yeniden kurulum kabul edilebilir.
- RTO saatler → hazır bekleyen bir DR ortamı gerekir.
- RTO dakikalar → çalışır durumda bekleyen ve otomatik devralan bir sistem.
Yedekleme çözümlerimizdeki örnek plan 15 dakikalık artımlı veritabanı yedeğiyle çalışıyor; DR tarafında ise sürekli replikasyon ve sözleşmeyle taahhüt edilen 4 saatlik RTO sunuyoruz.
Taahhüt edilmeyen hedef, hedef değildir
Bir sağlayıcı size RTO söylüyorsa, bunun sözleşmede yazılı olup olmadığını sorun. Yazılı değilse o bir hedef değil, temennidir. Aynı şekilde: son tatbikatın ne zaman yapıldığını ve sonucunun paylaşılıp paylaşılmadığını sorun.
Ölçülmeyen bir RTO, kesinti gününe kadar doğru sanılır.
DR çözümlerimizi inceleyebilir, kendi RTO ve RPO hedeflerinizi birlikte belirlemek için teklif formundan ulaşabilirsiniz.