RTO ve RPO Nedir, Nasıl Belirlenir

RTO ve RPO, felaket kurtarma planlarının iki temel sayısıdır ve ikisi de tek bir soruyu cevaplar: kötü bir şey olduğunda ne kadarını kaybetmeyi göze alabilirsin? RTO zaman cinsinden hizmetin ne kadar süre kapalı kalabileceğini, RPO ise yine zaman cinsinden ne kadar verinin kaybolabileceğini söyler. Bu iki sayıyı belirlemeden alınan her yedekleme ve yüksek erişilebilirlik kararı, aslında tahmine dayalıdır.

Bu yazıda önce iki kavramı somut örneklerle netleştireceğiz, sonra bunları nasıl belirleyeceğini — teknik hevesle değil, iş etkisiyle — anlatacağım. Ardından en önemli kısma geleceğiz: belirlediğin hedeflerin teknik karşılığı nedir? RPO'yu 24 saatten 5 dakikaya indirmek yedekleme stratejini nasıl değiştirir, RTO'yu 4 saatten 5 dakikaya çekmek hangi mimariyi zorunlu kılar? Sonunda da gerçek RTO'nu nasıl ölçeceğini ve bu konuda en sık yapılan hataları ele alacağız.

RTO Nedir: Ne Kadar Sürede Ayağa Kalkmalısın#

RTO (Recovery Time Objective, kurtarma süresi hedefi), bir kesintinin başlangıcından hizmetin yeniden çalışır hale gelmesine kadar geçmesine izin verilen azami süredir. "Sistemimiz en fazla 2 saat kapalı kalabilir" cümlesi, RTO'nun 2 saat olduğunu söyler.

Dikkat edilmesi gereken nokta, RTO'nun yalnızca teknik geri yükleme süresi olmadığıdır. Gerçek RTO şu adımların toplamıdır:

1. Arızanın fark edilmesi — izleme sistemi uyarı üretiyor mu, yoksa müşteri mi haber veriyor?
2. Doğru kişiye ulaşılması — gece 03:00'te nöbetçi var mı?
3. Teşhis — ne olduğunu anlamak.
4. Karar — onarmak mı, yedeğe geçmek mi?
5. Uygulama — geri yükleme ya da devretme.
6. Doğrulama — sistemin gerçekten düzgün çalıştığını teyit etmek.

Ekipler genellikle yalnızca 5. adımı ölçer ve "geri yükleme 20 dakika sürüyor" der. Oysa arızayı bir saat sonra fark ediyor, ilgili kişiye 30 dakikada ulaşıyor ve teşhise 40 dakika harcıyorsan gerçek RTO'n 20 dakika değil, üç saatin üzerindedir. RTO'yu kısaltmanın en ucuz yolu genellikle daha hızlı disk değil, daha iyi izleme ve net bir nöbet düzenidir.

RPO Nedir: Ne Kadar Veri Kaybını Göze Alabilirsin#

RPO (Recovery Point Objective, kurtarma noktası hedefi), kabul edilebilir azami veri kaybını zaman cinsinden ifade eder. "En fazla 1 saatlik veri kaybını göze alabiliriz" cümlesi RPO'nun 1 saat olduğunu söyler.

RPO'nun zaman cinsinden ölçülmesi ilk başta tuhaf gelebilir ama son derece pratiktir. Çünkü RPO doğrudan yedekleme ya da çoğaltma sıklığını belirler: son yedeğinle arıza anı arasındaki süre, kaybettiğin veridir. Günde bir kez saat 02:00'de yedek alıyorsan ve arıza saat 17:00'de olduysa, 15 saatlik veriyi kaybettin demektir — yani RPO'n pratikte 24 saattir.

Bu, çoğu ekibin farkında olmadan yaşadığı bir gerçektir: "günlük yedeğimiz var" demek, "24 saate kadar veri kaybını kabul ediyoruz" demektir. Bir e-ticaret sitesi için bu, bir günlük tüm siparişlerin kaybı anlamına gelir ve neredeyse hiçbir işletme bunu bilerek kabul etmez — sadece hesabını hiç yapmamıştır.

RPO'yu belirlerken sorulacak soru şudur: bu veriyi kaybedersek yeniden üretebilir miyiz? Bazı veriler yeniden üretilebilir (yeniden hesaplanan raporlar, önbellek, dönüştürülmüş görseller) ve bunlar için yüksek RPO sorun değildir. Bazıları ise geri gelmez: müşteri siparişi, ödeme kaydı, kullanıcı içeriği, muhasebe kaydı. Bu ikinci grup için RPO'yu olabildiğince küçük tutmak gerekir.

İkisini Birlikte Okumak#

RTO ve RPO birbirinden bağımsız değişkenlerdir ve farklı teknolojilerle karşılanırlar. Bunu bir zaman çizgisi üzerinde düşünmek en açıklayıcısıdır: arıza anını merkeze koy, RPO geriye doğru (ne kadarını kaybettim), RTO ileriye doğru (ne kadar sürede döndüm) uzanır.

   son yedek                 ARIZA                    hizmet geri geldi
       |<------- RPO ------->|<-------- RTO --------->|
       |    kaybedilen veri  |    kesinti süresi      |

İki hedefin farklı olması çok normaldir ve genellikle olması gerekendir. Örneğin bir kurumsal web sitesinde RPO 24 saat (içerik nadiren değişir) ama RTO 1 saat olabilir (site kapalıysa itibar kaybı var). Tam tersine bir muhasebe sisteminde RPO 5 dakika (hiçbir kaydı kaybedemezsin) ama RTO 8 saat olabilir (mesai dışında kimse kullanmıyor).

Bu tabloyu kendi sistemlerine uyarlarken tek bir hedef belirlemek yerine katmanlandırmanı öneririm. Her sistem aynı öneme sahip değildir; ödeme veritabanına uyguladığın RPO'yu log arşivine uygulamak, bütçeni değer üretmeyen yere harcamak demektir.

RTO ve RPO Nasıl Belirlenir#

Bu iki sayı teknik ekibin tek başına vereceği kararlar değildir; iş tarafıyla birlikte belirlenir. İzlenecek yol şudur:

1. Sistemleri listele ve önceliklendir. Envanterdeki her uygulamayı üç kademeye ayır: kritik (durursa iş durur), önemli (durursa aksar), destekleyici (durursa fark edilmez). Bu kademelendirme sonraki tüm kararların temelidir.

2. Kesintinin saatlik maliyetini hesapla. Kaybedilen ciro, boşa geçen personel zamanı, sözleşme cezaları, müşteri kaybı ve itibar zararını topla. Kaba bir tahmin bile hiç tahmin yapmamaktan çok daha iyidir.

3. Farklı hedeflerin maliyetini çıkar. RTO'yu 8 saatten 1 saate indirmek sana ne kadara mal olur? Bu iki sayıyı yan yana koyduğunda karar kendiliğinden netleşir: kesinti maliyeti saatte 20.000 TL ise, yıllık 60.000 TL'lik bir yedek altyapı tek bir olayda kendini amorti eder.

4. Yasal ve sözleşmesel gereklilikleri ekle. Bazı sektörlerde veri saklama ve kurtarma süreleri mevzuatla belirlenir; müşteri sözleşmelerindeki SLA maddeleri de bağlayıcıdır. Bunlar pazarlık konusu değildir, alt sınırdır.

5. Yazılı hale getir ve gözden geçir. Belirlenen hedefleri belgeye dök, ilgili herkesin onayını al ve yılda bir kez tekrar değerlendir. İş büyüdükçe kabul edilebilir kayıp küçülür.

Hedeflerini uptime yüzdesiyle karşılaştırmak istersen uptime SLA hesaplayıcı aracı yıllık ve aylık kesinti bütçesini doğrudan gösterir. Belirlediğin hedeflerin hangi mimariyi gerektirdiğini görmek içinse yüksek erişilebilirlik mimarisi yazısındaki dokuzlar tablosuna bakabilirsin.

Hedeflerin Teknik Karşılığı#

Burası işin somutlaştığı yer. Belirlediğin her hedef, belirli bir teknoloji kümesini zorunlu kılar; hedefi yazıp altyapıyı değiştirmemek en yaygın kendini kandırma biçimidir.

RPO'nun karşılığı yedekleme ve çoğaltma sıklığıdır:

PostgreSQL'de RPO'yu dakikalar seviyesine indirmenin yolu sürekli arşivlemedir:

# postgresql.conf
wal_level = replica
archive_mode = on
# WAL segmentini arşive kopyala (üzerine yazmayı engelle)
archive_command = 'test ! -f /arsiv/wal/%f && cp %p /arsiv/wal/%f'
# Segment dolmasa bile en fazla 5 dakikada bir kapat ve arşivle
archive_timeout = 300

archive_timeout = 300 satırı doğrudan RPO'nu belirler: en kötü senaryoda 5 dakikalık veriyi kaybedersin. MySQL tarafında karşılığı ikili kayıt (binary log) arşivlemedir:

[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
# Her işlemde diske yaz — güvenli ama yavaş; RPO ~0 için gerekli
sync_binlog = 1
binlog_expire_logs_seconds = 1209600   # 14 gün

RTO'nun karşılığı ise geri yükleme mekanizmasıdır:

RTO hesaplarken en çok atlanan şey veri hacminin geri yükleme süresine etkisidir. 500 GB'lık bir yedeği 1 Gbit/s bağlantı üzerinden çekmeyi düşün: gerçekçi bir 100 MB/s hızda bu yaklaşık 83 dakika sürer, üstüne açma ve doğrulama süresi eklenir. RTO'n 30 dakika ise, ne kadar iyi yedeğin olursa olsun bu hedefi geri yüklemeyle tutturamazsın — hazır bekleyen bir yedek sunucuya ihtiyacın var. Bağlantı hızına göre süre hesabı yapmak için bant genişliği hesaplayıcı aracını kullanabilirsin.

Yedekleme tarafını pratikte nasıl kuracağını Borg ile sunucu yedekleme yazısında ayrıntılı anlatıyoruz; devretme tarafı içinse Keepalived ve VRRP ile failover yazısına bakabilirsin.

Gerçek RTO'nu Nasıl Ölçersin#

Hedef belirlemek kolaydır; gerçekte o hedefi tutturup tutturamadığını bilmek için tek bir yol vardır: tatbikat yapmak. Kağıt üzerindeki RTO ile ölçülmüş RTO arasında genellikle iki-üç kat fark çıkar ve bu farkı ancak deneyerek görürsün.

Tatbikatı gerçekçi kur: üretim ortamının bir kopyasını sıfırdan ayağa kaldır, kronometreyi arıza anında başlat, doğrulama bitene kadar durdurma.

#!/bin/bash
# Geri yükleme tatbikatı — her adımın süresini ölç
BASLANGIC=$(date +%s)
olc() { echo "[$(( $(date +%s) - BASLANGIC ))s] $1"; }

olc "yedek indiriliyor"
borg extract /yedek/depo::son-yedek

olc "veritabani geri yukleniyor"
psql -U postgres -d uygulama -f /geri/dump.sql

olc "servisler baslatiliyor"
systemctl start nginx php8.3-fpm

olc "duman testi"
curl -fsS -o /dev/null http://127.0.0.1/saglik && olc "SAGLIK OK"

echo "Olculen RTO: $(( $(date +%s) - BASLANGIC )) saniye"

Tatbikatta hangi adımın ne kadar sürdüğünü kaydetmek, nereye yatırım yapman gerektiğini doğrudan gösterir. Sürenin çoğu yedek indirmede geçiyorsa çözüm daha yakın bir yedek kopyasıdır; veritabanı geri yüklemede geçiyorsa fiziksel yedekleme yöntemine geçmek gerekir; kurulum adımlarında geçiyorsa otomasyon eksiktir.

Ölçmen gereken ikinci şey RPO'nun gerçekten tutup tutmadığıdır. Yedek işi sessizce başarısız oluyorsa RPO'n kağıt üzerinde 1 saat, gerçekte haftalar olabilir. Yedeklerin yaşını düzenli kontrol et:

# En son yedek kaç saat önce alındı
borg list /yedek/depo --last 1 --format '{time}{NL}'

# Yedek 26 saatten eskiyse uyarı üret (cron ile çalıştır)
find /yedek/gunluk -name '*.tar.zst' -mmin -1560 | grep -q . \
  || logger -p user.err "UYARI: son 26 saatte yedek alinmamis"

Sık Yapılan Hatalar#

Hedefleri hiç belirlememek. "Yedeğimiz var" cümlesi bir hedef değildir. Sayı yoksa yeterli olup olmadığını değerlendiremezsin.

RTO'yu yalnızca geri yükleme süresi sanmak. Fark etme, ulaşma ve teşhis süreleri çoğu zaman geri yüklemeden uzundur. Toplamı ölçmezsen gerçek RTO'nu bilemezsin.

Yedeği hiç geri yüklememek. Denenmemiş yedek, yedek değildir. Bozuk bir arşivi ancak ihtiyacın olduğu gün keşfetmek en pahalı senaryodur.

Çoğaltmayı yedekleme yerine koymak. Çoğaltma anlık bir aynadır: silinen bir tablo saniyeler içinde yedek düğüme de yansır. RPO'yu koruyan şey zaman içinde geriye gidebilmendir, ki bunu yalnızca sürüm tutan yedekler sağlar.

Tüm sistemlere aynı hedefi uygulamak. Log arşivine ödeme veritabanı kadar yatırım yapmak bütçeyi boşa harcar; tersini yapmak ise gerçek riski açıkta bırakır.

Yedeği kaynağın yanında tutmak. Aynı sunucudaki ya da aynı lokasyondaki yedek, o lokasyonu etkileyen bir olayda birlikte gider. En az bir kopya uzakta olmalıdır.

Hedefleri bir kez belirleyip unutmak. İş büyüdükçe kesintinin maliyeti artar. İki yıl önce makul olan 8 saatlik RTO bugün kabul edilemez olabilir; yılda bir kez gözden geçir.

Sıkça Sorulan Sorular#

RTO ve RPO arasındaki fark nedir#

RTO hizmetin ne kadar süre kapalı kalabileceğini, RPO ise ne kadar verinin kaybolabileceğini gösterir. Zaman çizgisinde RPO arıza anından geriye, RTO ise ileriye doğru uzanır. İkisi farklı teknolojilerle karşılanır: RPO'yu yedekleme ve çoğaltma sıklığı belirler, RTO'yu ise geri yükleme ya da devretme mekanizmasının hızı belirler.

RPO sıfır olabilir mi#

Teorik olarak sıfıra çok yaklaşabilirsin ama tam sıfır pratikte ulaşılamaz bir hedeftir. Eşzamanlı çoğaltma ile her yazmanın en az iki düğümde onaylanmasını sağlayabilirsin; bu, kaybı tek bir işlem seviyesine indirir. Bedeli ise her yazmanın ağ gecikmesi kadar yavaşlaması ve mimarinin belirgin biçimde karmaşıklaşmasıdır. Çoğu sistem için birkaç dakikalık RPO hem yeterli hem de çok daha ekonomiktir.

Günlük yedek almak yeterli mi#

Bu tamamen RPO hedefine bağlıdır. Günlük yedek, 24 saate kadar veri kaybını kabul ettiğin anlamına gelir. İçeriği nadiren değişen bir tanıtım sitesi için sorun değildir. Ancak her gün sipariş alan bir e-ticaret sitesinde bu, bir günlük tüm siparişlerin kaybı demektir ve neredeyse hiçbir işletme bunu bilerek kabul etmez. Veri sürekli değişiyorsa günlük yedeğin üstüne işlem kaydı arşivlemesi eklemelisin.

RTO'mu nasıl kısaltırım#

Önce nerede zaman kaybettiğini ölç. Çoğu ekipte en büyük pay geri yüklemede değil, arızayı fark etme ve teşhis aşamalarındadır; otomatik izleme ve net bir nöbet düzeni bu süreyi ucuza kısaltır. Teknik tarafta ise sıralama şudur: yedeği daha yakın tutmak, kurulumu otomatikleştirmek, soğuk yedek sunucu bulundurmak ve en sonunda otomatik devretme kurmak. Her adım maliyeti artırır, bu yüzden hedefe ulaşan en ucuz adımda durmak doğrudur.

RTO ve RPO hedeflerini kim belirler#

Karar iş tarafına aittir, teknik ekip ise seçeneklerin maliyetini ortaya koyar. Teknik ekibin tek başına belirlediği hedefler ya gereksiz pahalı ya da iş riskini karşılamayacak kadar gevşek olur. Doğru yöntem, kesintinin saatlik maliyetini hesaplayıp farklı hedeflerin altyapı maliyetiyle yan yana koymak ve kararı birlikte vermektir.

Yüksek erişilebilirlik RPO sorununu çözer mi#

Hayır, ikisi farklı problemleri çözer. Yüksek erişilebilirlik RTO'yu kısaltır: bir bileşen çöktüğünde hizmet yedek üzerinden hızlıca devam eder. Ama çoğaltma anlık bir ayna olduğu için mantıksal hatalara karşı koruma sağlamaz — yanlışlıkla silinen bir tablo saniyeler içinde tüm düğümlere yayılır. RPO'yu koruyan şey zaman içinde geriye gidebilmendir; bunu yalnızca sürüm tutan yedekler sağlar. Sağlam bir plan ikisini birlikte içerir.

Kapanış#

RTO ve RPO, felaket kurtarma planını duygudan çıkarıp mühendisliğe çeviren iki sayıdır. Aklında kalması gereken dört şey var: hedefleri iş etkisiyle belirle, her sisteme aynı hedefi uygulama, RTO'yu yalnızca geri yükleme süresi sanma ve en önemlisi — hedefini ölç, tahmin etme. Yılda birkaç kez yapılan gerçekçi bir tatbikat, kağıt üzerindeki plan ile gerçek arasındaki farkı görmenin tek yoludur.

Belirlediğin hedeflere uygun bir altyapı kurmak için esnek kaynaklara ihtiyacın var. Sürüm tutan ve uzakta saklanan kopyalar için yedekleme hizmetimize, hazır bekleyen bir yedek ortam için bulut sunucu ve VDS paketlerimize göz atabilirsin. Yedekleme takvimini, geri yükleme tatbikatlarını ve izlemeyi bize bırakmak istersen sunucu yönetimi hizmetimiz bu işi üstlenir.