RTO ile RPO arasındaki fark
RTO (recovery time objective, kurtarma süresi hedefi), bir sistemin, iş üzerinde kabul edilemez bir etki doğmadan ne kadar süre kapalı kalabileceğidir. RPO (recovery point objective, kurtarma noktası hedefi) ise restore edilen verinin ne kadar eski olabileceği, yani ne kadar veri kaybını göze alabileceğinizdir. RTO kesintiden ileriye, RPO geriye doğru ölçülür. İkisini de iş etki analizine göre belirleyin; RTO'yu recovery süresini ölçerek, RPO'yu restore edilen verinin yaşını kontrol ederek doğrulayın.
RTO nedir?
RTO, bir sistemin arızadan sonra kapalı kalabileceği hedef süredir. Bu süre aşılırsa diğer sistemler ve sistemin desteklediği iş süreci kabul edilemez biçimde etkilenir, sürecin maksimum tolere edilebilir kesinti süresi (MTD) de tehlikeye girer. İş etki analiziyle belirlenir, gerçek bir restore'un süresi ölçülerek doğrulanır.
RPO nedir?
RPO, bir kesintiden sonra verinin restore edilebilmesi gereken zaman noktasıdır; yani ne kadar eski veriye dönmeyi kabul ettiğinizi belirler. 4 saatlik RPO, son dört saatteki değişiklikleri kaybetmeyi kabul etmek demektir; backup ya da replication tasarımı en kötü durumu bu sınırın içinde tutmalıdır.
| RTO | RPO | |
|---|---|---|
| Cevapladığı soru | Sistem ne kadar süre kapalı kalabilir? | Ne kadar veri kaybedebiliriz? |
| Ölçüm yönü | Kesintiden ileriye | Kesintiden geriye |
| MTD'nin parçası mı (NIST) | Evet | Hayır, ama kaybolan veriyi yeniden işlemek MTD bütçesinden süre kullanır |
| Neye göre belirlenir | İş etki analizi, sürecin MTD'si içinde | İş etki analizi, sürecin veri kaybı toleransı |
| Veeam v13'te neye bağlı | Restore yöntemi: full restore, Instant Recovery, replica failover | Job aralığı artı en uzun session, kopyalama gecikmesi, CDP RPO'su |
| Gerçekleşen değer nasıl ölçülür | RTA: süresi ölçülen bir restore, her aşama dahil | RPA: arıza anında kullanılabilir en yeni restore point'in yaşı (en kötü durum: aralık artı en uzun session) |
Birincil kaynaklar tam olarak ne diyor
Sık atıf yapılan tanımların bir kısmı NIST'in federal süreklilik planlama rehberi SP 800-34 Rev. 1'den gelir (Mayıs 2010; CSRC'nin nihai olarak listelediği sürüm Kasım 2010 güncellemelerini içeriyor). Bölüm 3.2.1 üç kesinti terimini tanımlar:
| Terim | NIST SP 800-34 Rev. 1 ifadesi |
|---|---|
| Maximum Tolerable Downtime (MTD) | "the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption and includes all impact considerations" |
| Recovery Time Objective (RTO) | "the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD" |
| Recovery Point Objective (RPO) | "the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage" |
NIST sözlüğündeki RTO, RPO ve MTD maddeleri aynı yayının ek sözlüğünden gelir ve ifadeleri farklıdır: örneğin RPO maddesi, Bölüm 3.2.1'deki "can be recovered" yerine "must be recovered" ifadesini kullanır.
Bu tanımların uygulamada üç sonucu var:
- MTD iş sürecine, RTO sisteme aittir. Bir süreci destekleyen her sistem için, o sürecin MTD'si içinde ayrı bir RTO belirlenir. Bir dipnot, SP 800-34'ün ilk baskısında tek bir terim (Maximum Allowable Outage) kullanıldığını, MTD ile RTO'nun ise "to further delineate business process and information system downtime" amacıyla getirildiğini söyler.
- RPO, MTD'nin dışında kalır; NIST bunu açıkça yazar: "Unlike RTO, RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process."
- Kaybolan veriyi yeniden işlemek de zaman alır. NIST, kesintinin bir süreci yarıda kestiği durumu örnek verir: "because it takes time to reprocess the data, that additional processing time must be added to the RTO to stay within the time limit established by the MTD." Yani gevşek bir RPO, kesinti bütçesinden pay alır.
Work Recovery Time (WRT), Recovery Time Actual (RTA) ve Recovery Point Actual (RPA) sahada kullanılan terimlerdir; hiçbiri SP 800-34'te geçmiyor. Aşağıda ölçülen değerler için RTA ve RPA diyoruz, çünkü yazının geri kalanında "hedef" ile "gerçekleşen"i ayrı tutuyoruz.
Hedefleri araçtan değil, iş etki analizinden çıkarın
SP 800-34, RTO'yu backup ürününün yapabildiğinden değil, iş sürekliliği planının temeli olan iş etki analizinden (BIA) türetir. Rehberin BIA sürecini gösteren şekli (Şekil 3-2, "Notional Times" notuyla) fatura sürecine 72 saatlik MTD, uygulama sunucusuna 36 saatlik RTO veriyor; MTD'si 36 saat olan bütçe sürecinin veritabanı sunucusuna ise 12 saatlik RTO veriyor. Ek B'deki örnek BIA ise tedarikçi faturası ödeme süreci için MTD 72 saat, RTO 48 saat, RPO 12 saat (son backup) öngörüyor. NIST'e göre RTO normalde MTD'den kısa olmalı ki, örneğin verinin yeniden işlenmesi gerektiğinde MTD aşılmasın. NIST bu süreyi RTO'ya katar; sahada ise ayrı tutulur ve work recovery time (WRT) diye anılır. Yaygın kural, MTD'nin en az RTO ile WRT'nin toplamı kadar olmasıdır. Aynı aşamayı iki kez saymamak için RTO'nuzun neleri kapsadığını açıkça yazın.
Aynı bölüm, hedeflerin neden yalnızca en kısaya indirilmek yerine iş birimiyle birlikte belirlenmesi gerektiğini de açıklar: "the shorter the RTO, the more expensive the recovery solutions cost to implement."
Veeam'in Data Trust and Resilience Report 2026 çalışmasında (900'den fazla kıdemli BT, güvenlik ve risk yöneticisi) katılımcıların %90'ı siber olay sonrası RTO hedeflerini karşılayabileceğinden emin olduğunu söylüyor; buna karşın yalnızca %69'u RTO'larının iş sürekliliği hedefleriyle tam uyumlu olduğunu belirtiyor ("yet only 69% say RTOs are fully aligned with business continuity goals"). BIA'ya bağlanmamış bir RTO kâğıt üzerinde tutturulup iş sürecinin ihtiyacını yine de karşılamayabilir.
Kesinti ve veri kaybının maliyetini tahmin etmek için ransomware ve downtime maliyeti hesaplayıcımız RTO ve RPO'yu ayrı girdi olarak alıyor.
BDDK bankalardan ne istiyor
Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik (Resmî Gazete 15/3/2020, 31069) RTO ve RPO kavramlarını kendi diliyle yazıyor. Madde 28(3): "iş etki analizi çerçevesinde her bir BS servisi için kabul edilebilir kesinti süreleri ile kabul edilebilir veri kayıpları belirlenir". Madde 28(6) ise banka düzeyinde bir sınır koyuyor: "Birincil sistemlerin tamamen devre dışı kaldığı felaket senaryolarında dahi bankanın en geç yirmi dört saat içerisinde faaliyetlerini yeniden sürdürebiliyor olması esastır." Aynı fıkra yılda en az bir kez gerçek bir felaket senaryosuna dayanan ve ikincil merkezden çalışmayı deneyen test istiyor. Yani bir bankada her BS servisinin kabul edilebilir kesinti ve veri kaybı sınırları, 28(3) uyarınca BIA'ya göre belirlenir. 24 saat ise birincil sistemlerin tamamen devre dışı kaldığı senaryoda bankanın faaliyetlerini yeniden sürdürebilmesi için belirtilen süredir. Madde 28(9) uyarınca banka, ikincil merkez kapsamına aldığı ve almadığı BS servislerinin listesini ayrıca belgelendirir. Madde 28, 1/1/2021'den beri yürürlükte.
Ulaşılabilir RTO nasıl hesaplanır: örnek hesap
RTA, arızadan servisin kullanılabilir hâle gelmesine kadar geçen toplam süredir; veri kopyalama bunun yalnızca bir bölümüdür. Buradaki bütün sayılar örnek amaçlı; kendi ölçümlerinizle değiştirin.
Senaryo. Veritabanı, uygulama ve dosya sunucusu VM'lerinden oluşan, toplam 50 TiB'lık bir ERP servisi yerel repository'den full restore ediliyor. İş birimiyle 8 saatlik RTO üzerinde anlaşılmış.
1. adım: veri aktarım süresi. Restore yolunun 10 Gbps'lik bir bağlantının %70'ini sürekli kullanabildiğini varsayalım. Hesap, replication window ve bandwidth hesaplayıcımızla aynı modeli kullanıyor: bağlantı hızı ondalık tabanda (bit), veri ikili tabanda (TiB).
- Efektif throughput: 10.000.000.000 bit/s ÷ 8 × 0,70 = 875.000.000 byte/s (875 MB/s)
- Veri: 50 × 2^40 = 54.975.581.388.800 byte
- Aktarım: 54.975.581.388.800 ÷ 875.000.000 = 62.829,2 s = 1.047,2 dakika (yaklaşık 17,45 saat)
2. adım: bütçenin geri kalanı.
| Aşama | Örnek süre (dakika) |
|---|---|
| Tespit ve alarm | 15 |
| Restore kararı, restore point seçimi | 30 |
| Veri aktarımı (1. adım) | 1.047,2 |
| Uygulamanın ayağa kalkması ve doğrulama | 60 |
| Cutover (DNS, connection string'ler, kullanıcı duyurusu) | 15 |
| Tahmini recovery süresi | 1.167,2 (19 sa 27,2 dk) |
15 + 30 + 1.047,2 + 60 + 15 = 1.167,2 dakika. Tasarım 8 saatlik RTO'yu 11 sa 27,2 dk farkla kaçırıyor; anlaşılan sürenin 2,4 katı gerekiyor. Veri kopyalama toplamın yaklaşık %90'ı (1.047,2 ÷ 1.167,2 = %89,7). Bu yüzden ekibin daha hızlı çalışması açığı kapatmaz: tespit, karar, doğrulama ve cutover sıfıra inse bile yalnızca kopyalama 17,45 saat sürer. Sonucu ancak farklı bir recovery mekanizması ya da taşınacak verinin azalması değiştirir.
3. adım: mekanizmayı değiştirin. Veeam Backup & Replication 13'teki Instant Recovery ile VM'ler doğrudan sıkıştırılmış ve deduplication uygulanmış backup dosyalarından çalışır; Veeam'e göre workload'lar dakikalar içinde geri döner ("are recovered in a matter of minutes"). Testinizde boot 10 dakika sürüyorsa bütçe 15 + 30 + 10 + 60 + 15 = 130 dakikaya (2 sa 10 dk) iner ve 8 saatlik RTO'nun rahatça içinde kalır. Production storage'a taşınana kadar bu VM'ler sınırlı I/O performansıyla çalışan geçici VM'lerdir ("temporary spares", "limited I/O performance"). Storage vMotion bu taşımayı kesintisiz ("without any downtime") yapabilir, ama iki koşulla: VM değişiklikleri başka bir datastore'a yönlendirilmeden vPower NFS datastore'da tutulmalı ve VMware lisansınız Storage vMotion'ı kapsamalı. Aksi hâlde VM'ler Quick Migration ile taşınır. 130 dakikayı RTA olarak ancak uygulama bu geçici VM'ler üzerinde gerekli performansı sağlıyorsa sayın.
- adımla ilgili bir uyarı: hesaplayıcı bir bağlantı üzerindeki aktarım süresini hesaplar, oysa gerçek restore süresi repository okuma hızı, proxy kapasitesi ve hedefin yazma hızıyla da sınırlıdır. Çıkan sayıyı alt sınır kabul edin ve ortamınızı temsil eden bir VM'in gerçek restore'unu kronometreyle ölçün.
Örnek, servisin bütün VM'lerini tek bir paralel kopya gibi ele alıyor. Gerçek bir ERP recovery'si çoğu zaman sırayla ilerler: önce kimlik altyapısı ve DNS, sonra veritabanı, sonra uygulama. Site kaybından ya da bir ransomware saldırısından sonra Veeam sunucusunun kendisini de önce yeniden kurmanız gerekebilir. Bütün tier-1 sistemler aynı anda, ortak repository, proxy ve bağlantılar üzerinden restore ediliyorsa toplam tier-1 veri boyutunu paylaşılan yolun efektif throughput'una bölün. RTO sayacının arıza anında mı yoksa felaket ilan edildiğinde mi başlayacağını önceden kararlaştırın. Tespit ve karar süreleri yalnızca ilk durumda sayılır; MTD'yi ise her iki durumda da arızadan itibaren geçen toplam kesintiyle karşılaştırın. Item-level restore, tek VM, bütün bir site ve ransomware sonrası recovery için ayrı RTO'lar belirleyin.
Ulaşılabilir RPO nasıl hesaplanır
RPA, job'ın çalışma aralığı değildir. Restore point, job'ın snapshot aldığı andaki durumu yakalar ama ancak o session tamamlanınca kullanılabilir. Dolayısıyla periyodik bir job'da veri kaybı için güvenli üst sınır, job aralığı ile en uzun session süresinin toplamıdır; tipik session süresi kullanılmaz, çünkü periyodik bir full ya da yeniden denenen bir session daha uzun sürer. Bu hesap, hiçbir çalışmanın gecikmediğini ya da atlanmadığını ve her çalışmanın kullanılabilir bir restore point ürettiğini varsayar.
Örnek hesap (varsayımsal girdilerle). Bir backup job'ı 4 saatte bir çalışıyor ve 40 dakika sürüyor. Veeam aralıkları 00:00'dan saymaya başlar; session'lar 00:00, 04:00, 08:00'de başlar. 04:00 restore point'i 04:40'ta, 08:00 restore point'i 08:40'ta kullanılabilir olur. 08:39'da arıza olursa kullanılabilir en yeni restore point 04:00'da alınandır: 4 sa 39 dk veri kaybı. En kötü durum 240 + 40 = 280 dakika, hedef ise 4 saatlik RPO. ERP veritabanında transaction log backup da açıksa (v13'te SQL Server için varsayılan 15 dakikada bir), image-level backup ile son kullanılabilir log backup arasındaki log zinciri kesintisizse recovery point tamamlanan son log backup kadar yeni olabilir; log replay de recovery süresine eklenir.
- Aralığı 3 saate çekin: 180 + 40 = 220 dakika (3 sa 40 dk). Her session başarılı olduğu sürece RPO artık 20 dakika payla tutuyor.
- Task'ı yeniden denemeler dahil başarısız olan bir VM, bir aralık daha kaybeder. Veeam başarısız bir job'ı varsayılan olarak aynı session içinde 3 kez yeniden dener ve yalnızca başarısız VM'leri yeniden işler; diğerlerinin yeni restore point'leri korunur. VM'in 03:00 task'ı yeniden denemeleriyle birlikte başarısız olur, 06:00 session'ı başarılı olursa en kötü durum 2 × 180 + 40 = 400 dakikaya (6 sa 40 dk) çıkar, yani 220'nin 1,8 katı. Başarılı olan yeniden denemeler de session'ı uzatır; hesapta en uzun session süresinin kullanılmasının nedeni bu. Yani ulaşılabilir RPO, zamanlama kadar başarısız task'ları yakalamanıza da bağlı.
- Site kaybında RPA kopyadan ölçülür: birincil repository site ile birlikte giderse esas alınan, off-site kullanılabilir en yeni restore point'tir. Immediate modda bir backup copy job'ı restore point'leri kaynak repository'de belirir belirmez kopyalar ("as soon as they appear in a source backup repository"). Her 3 saatlik çalışma 40 GiB'lık bir incremental (sıkıştırma sonrası, yani kopyanın taşıdığı veri) üretiyor ve bu veri 500 Mbps'lik bir WAN'dan %80 verimle gidiyorsa: 500.000.000 ÷ 8 × 0,80 = 50.000.000 byte/s; 40 × 2^30 = 42.949.672.960 byte; 42.949.672.960 ÷ 50.000.000 = 859 s, yani 14,3 dakika. Off-site en kötü durum: 180 + 40 + 14,3 = 234,3 dakika (3 sa 54,3 dk). Kâğıt üzerinde RPO 5,7 dakika farkla tutuyor, ama bu gerçek bir pay sayılmaz. Tasarımda daha fazla pay bırakın: daha uzun bir session ya da backup copy session'ındaki ek süre hedefi bozar, üstelik immediate modda Veeam başarısız bir kopyayı 3 kez yeniden dener, yeni restore point yoksa 1 saat arayla.
- Aynı olay için RTO'ya da bakın. 50 TiB'ın tamamı off-site kopyadan dönmek için aynı 500 Mbps'lik bağlantıdan geçmek zorundaysa yalnızca aktarım 54.975.581.388.800 ÷ 50.000.000 = 1.099.511,6 s, yani yaklaşık 305,4 saat (12,7 gün) sürer; hedef ise 8 saatlik RTO. Bağlantıdan sıkıştırılmış backup verisi geçiyorsa gerçekten gönderilen byte miktarıyla hesaplayın. Site kaybının kendi RTA'sı olmalı ve genellikle yalnızca bir kopya değil, kopyanın yanında işlem gücü gerekir (bir replica ya da DR sitesinde host'larıyla birlikte bir repository).
CDP'de ayarlanan RPO'yu çalışma aralığıyla değil, replication gecikmesi ve kullanılabilir en yeni restore point'in yaşıyla karşılaştırın. v13'teki CDP policy wizard'ına göre en düşük RPO 2 saniye, önerilen en az 15 saniye, üst sınır 60 dakika. Aynı sayfada RPO reporting seçeneği var: yeni restore point'ler belirlenen RPO içinde hedefe aktarılmazsa uyarı ya da hata üretir.
Veeam v13 mekanizmalarının RPO ve RTO karşılığı
| Mekanizma (v13) | RPO'yu ne belirler | RTO'yu ne belirler |
|---|---|---|
| Backup job | Çalışma aralığı artı job süresi; backup window taşan job'ı sonlandırabilir | Full restore süresi ya da Instant Recovery boot'u; geçici VM production yükünü taşıyamıyorsa ayrıca migration |
| Backup copy job | Kaynak restore point'in yaşı artı kopyalama süresi; periodic mod ayrıca zamanlamayı bekler ve log backup'larını kopyalamaz; immediate mod ise onları yalnızca ayar açıksa kopyalar | Kopyanın bulunduğu yerden, çoğu zaman WAN üzerinden restore |
| Application log backup (SQL Server transaction log'ları) | Log backup aralığı (varsayılan 15, en fazla 480 dakika), backup'ın tamamlanma gecikmesi ve kesintisiz log zinciri | Image-level restore artı seçilen restore point'e kadar log replay |
| Replication (snapshot tabanlı) | Veeam replication'ı saatler düzeyinde RPO gereken VM'ler için öneriyor ("RPO of hours") | Replica'lar başlatılmaya hazır bekler ("ready-to-start state"); failover planları boot sırasını ve bekleme aralıklarını belirler |
| vSphere için CDP ve Universal CDP | 2 saniye ile 60 dakika arasında ayarlanan RPO; short-term restore point'ler crash-consistent | Başlatılmaya hazır replica'ya failover |
| SureBackup | Yok | Full recoverability testing modunda restore point'in izole virtual lab'de boot edildiğini kontrol eder ve etkin heartbeat, ping ve uygulama testlerinden hangilerinin gerçekten çalışıp geçtiğini raporlar ("backup verification and content scan only" modu hiçbir şeyi boot etmez) |
Aşağıdaki tablo, ekiplerin bunları nasıl birleştirebileceğine dair bir örnektir; standart değildir:
| Örnek tier | RPO | RTO | Tipik v13 tasarımı |
|---|---|---|---|
| 0 | Saniyeler | Dakikalar; ancak failover ve doğrulama otomatikse ya da önceden onaylıysa | CDP ve failover planı |
| 1 | 1 ila 4 saat | 1 saatin altı, ancak tespit, karar ve doğrulama otomatikse ya da önceden onaylıysa | Snapshot replication ya da sık backup artı Instant Recovery |
| 2 | Yaklaşık bir gün artı job süresi | 4 ila 24 saat | Günlük backup, off-site backup copy, full restore |
| 3 | 24 saat ve üzeri | Günler | Object storage'a günlük ya da haftalık backup |
Her satırı yukarıdaki en kötü durum kurallarıyla sınayın: bu kurallara göre günlük bir job 24 saatlik RPO'yu tutturamaz; 2. adımdaki 15/30/60/15 dakikalık aşama bütçesine 10 dakikalık Instant Recovery boot'u eklenince toplam yine 130 dakikayı bulur.
SureBackup sık sık RTO testi sanılıyor, oysa VM'leri izole bir lab'de doğrudan backup dosyasından ve aynı anda yalnızca sınırlı sayıda ("Process simultaneously up to … machines") başlatıyor; Application initialization timeout varsayılan olarak 120 saniye. Bu, gerçekten çalıştırılan testler kapsamında restore point'in kullanılabildiğini gösterir; tam bir production restore'unun ne kadar süreceğini göstermez. Restore tatbikatlarını ayrıca kronometreyle yapın. Veeam'in bu iş için kendi araçları da var: Veeam Recovery Orchestrator her recovery plan için hedef RTO ve RPO tanımlar, gerçekleşen değerleri readiness check, execution ve test raporlarına yazar. Veeam ONE ise hazır alarmlarıyla tanımlı RPO içinde backup'ı alınmayan VMware VM'lerini ve kopyalanmayan backup'ları işaretler (VM alarmı varsayılan olarak 24 saattir; RPO'nuza göre daraltın).
Ransomware, kâğıt üzerindeki RTO ve RPO'yu neden bozar
Yukarıdaki her şey, hangi restore point'in temiz olduğunu bildiğinizi ve backup sunucusu, kimlik altyapısı ve hypervisor'ın ayakta kaldığını varsayıyor. Ransomware bu varsayımlardan birini ya da ikisini birden geçersiz kılabilir.
RPA artık son temiz restore point'in ne kadar eski olduğuyla belirlenir. Saldırganlar şifrelemeden önce içeride olabilir: Mandiant'ın M-Trends 2026 raporu, tüm saldırı türlerinde küresel medyan dwell time'ı 14 gün olarak veriyor (önceki yıl 11) ve artışı büyük olasılıkla saldırganların savunmaları atlatmada ustalaşmasına bağlıyor. Siber casusluk ve Kuzey Koreli BT çalışanı vakalarında medyan 122 gün. Rakam ransomware'e özgü değil; onu restore için kaç gün geriye gideceğinizin ölçüsü olarak değil, bir uyarı olarak okuyun. Veeam'in Scan Backup özelliği, saldırı tarihi bilinmediğinde son temiz restore point'i bulmak için var ("find the last clean restore point if the date of the malware attack is unknown"); Secure Restore ise restore point'leri production'a dönmeden önce malware'e karşı tarar. İkisi de recovery süresine tarama süresi ekler ve taramada tehdit bulunmaması, restore point'in temiz olduğunu kesin olarak göstermez: örneğin Secure Restore, mount edemediği volume'ları taramadan restore eder. Scan Backup'ın koşulları da var: replica'ları değil, backup ve backup copy'leri tarar; SOBR archive tier'daki backup'ları ve storage snapshot'larını taramaz; Cloud Connect repository'deki backup'ları tenant tarayamaz, service provider ise Cloud Connect sunucusundan tarayabilir. File share ve object storage backup'larının ise 13.1 veya sonrasında oluşturulmuş, consistent, şifrelenmemiş ve GFS dışında olması gerekir.
CDP şifrelenmiş yazma işlemlerini de her değişiklik gibi replike eder: policy 15 saniyelik RPO'sunu tutturuyorsa şifrelenmiş bloklar replica'ya saniyeler içinde ulaşır. Kurtarma bu durumda ayarladığınız short-term retention (en fazla 7 gün) içinde ya da long-term restore point'ler arasında temiz bir restore point bulunmasına bağlı. Scan Backup burada işe yaramaz; replica'ları değil, backup'ları tarar. Long-term CDP restore point'leri disk başına 95 ile sınırlı; bu yüzden long-term restore point'lerin 14 günü kapsamasını isterseniz 4 saatte bir restore point (84) sığar, 3 saatte bir (112) sığmaz.
Sistemlerin üzerine yazılmadan önce delillerin de korunması gerekir. CISA'nın #StopRansomware Guide belgesi (Ekim 2023 yayını) ilk üç adımın sırayla uygulanmasını istiyor; 9. adım (ilk müdahale mümkün görünmüyorsa), etkilenen cihazların bir kısmından sistem imajı ve bellek dökümü almak ("take a system image and memory capture of a sample of affected devices"). 16. adım sistemleri önceliğe göre yeniden kurmak. Offline backup'lardan restore ("restore data from offline, encrypted backups") 19. adımda geliyor, üstelik temiz sistemleri yeniden enfekte etmeme uyarısıyla ("not to re-infect clean systems during recovery"). Bunların hiçbiri bir aktarım hızı hesabında görünmez.
Backup'lar da doğrudan saldırıya uğruyor: M-Trends 2026'ya göre ransomware operatörleri backup altyapısını, kimlik servislerini ve sanallaştırma yönetim katmanını hedef aldı; cloud storage'daki backup nesnelerini de aktif olarak sildi. Saldırgan kullanılabilir bütün kopyaları silebiliyorsa RPO karşılanamaz. Immutable bir kopyanın gerekçesi bu; bunu 3-2-1-1-0 kuralı rehberimizde anlatıyoruz. Immutability'nin gerçekten uygulandığını nasıl kontrol edeceğinizi de ayrı bir yazıda ele aldık. Immutability, Backup güvenliği nedir? yazımızdaki sekiz kontrolden biri.
Sophos'un State of Ransomware 2026 raporunda (ransomware saldırısına uğramış kuruluşlardan 2.158 BT ve güvenlik karar vericisi, 17 ülke, anket Ocak-Mart 2026) kuruluşların %16'sı bir günden kısa sürede, %55'i bir hafta içinde, %83'ü bir ay içinde tamamen toparlandı; ortalama süre yine üç hafta. Verisi şifrelenenlerin %66'sı veriyi backup'tan restore etti (taban 1.214). Şifreleme toparlanmayı yavaşlatıyor: 2025 baskısında (toplam 3.400 katılımcı) verisi şifrelenenlerin %9'u bir günde tamamen toparlanırken saldırganların veriyi şifreleyemediği kuruluşlarda bu oran %24. Veeam'in 2026 raporunda da saldırıya uğrayanların yalnızca %28'i etkilenen verinin tamamını geri alabildi; ortalama geri alınan oran %72.
Sophos kuruluşun tamamını, örnek hesap tek bir ERP servisini ölçüyor; sayılar doğrudan karşılaştırılamaz. Ransomware recovery hedeflerini BIA'ya göre belirleyin; gerçekleşen recovery süresini ve veri kaybını tarama, adli inceleme için bekleme, temiz ve izole bir ağ ve yeniden kurulmuş bir kimlik altyapısı içeren testlerde ölçün.
Bu yazı neyi söylemez
- Örnek hesaplar varsayımsal girdilerle yapılmış aritmetik. %70 bağlantı verimi, 40 dakikalık job ve 10 dakikalık Instant Recovery boot'u yalnızca örnek değerler. Bunları farklı veri boyutlarına uyarlamak için kendi restore yolunuzu ölçün.
- Anket rakamları beyana dayalı. Sophos "fully recover" süresini soruyor ve her katılımcı bunu kendi yorumluyor. Veeam'in 2026 raporunun tamamı kayıt formunun arkasında; buradaki rakamlar Veeam'in kendi basın bülteninden. Bülten araştırma firmasını ve anketin tarihlerini vermiyor. Sophos'un backup'tan recovery için verdiği %66'lık rakamda birden fazla cevap seçilebiliyordu; katılımcılar 100 ile 5.000 çalışanlı kuruluşlardan.
- ISO'dan değil NIST'ten alıntı yapıyoruz. NIST metni kamuya açık. ISO 22301 ve terim standardı ISO 22300 yakın terimler kullanır: NIST'in MTD dediğine MTPD (maximum tolerable period of disruption) der. RTO'yu tek bir sistem için değil ürün, hizmet, faaliyet ve bunların arkasındaki kaynaklar için belirler; ayrıca kesinti sırasında kabul edilebilir asgari hizmet düzeyi olan MBCO'yu tanımlar. Bağlantı verdiğimiz terim özeti, ISO 22301'in eski 2012 baskısının ifadesini aktarıyor; 2019 baskısı terimlerini ISO 22300'den alıyor. ISO'nun telifli ifadelerini aktarmadık.
- Model, kendisine ayrılmış altyapıda tek bir paralel kopya olarak restore edilen tek bir servisi esas alır. Bağımlılık, kaynak paylaşımından doğan darboğaz (contention) ya da backup sunucusunun yeniden kurulması yok. Tahmin bu aşamaları içermez; gerçek olay senaryolarınız için uçtan uca recovery süresini ölçün.
- Veeam karşılıkları VMware vSphere için yazıldı. CDP ve Universal CDP yalnızca vSphere'e replike eder; hedefte vSphere olmayan (örneğin tamamen Hyper-V, Proxmox ya da Nutanix üzerinde çalışan) ortamlarda CDP tier'ı yoktur. Agent, cloud-native ve Microsoft 365 recovery süreleri de farklı davranır.
- Site kaybı RTA'sı yalnızca taslak. 305,4 saat yalnızca aktarım süresidir; recovery için DR sitesinde işlem gücü de gerekir; failback'i ayrıca planlayıp ölçün.
- Dwell time, bulaşma süresi değildir. 14 günlük medyan dwell time, son 14 günün backup'larının enfekte olduğu demek değildir. Yalnızca şifreleme tarihinin tek başına temiz restore point'i göstermediğini söyler.
- BDDK notu yalnızca bankalar için. Madde 28 yalnızca bankaları bağlar. Sermaye piyasası kurumları SPK'nın VII-128.10 sayılı tebliğine, diğer finansal kuruluşlar kendi düzenleyicilerinin bilgi sistemleri mevzuatına tabidir. 24 saat şartı bu kuruluşlara kendiliğinden uygulanmaz; hedefleri kendi mevzuatlarına ve BIA sonuçlarına göre belirlenir.
BackupSec bu işe nasıl yaklaşıyor
Ücretsiz replication window ve bandwidth hesaplayıcımız, örnek hesabın 1. adımını kendi veri boyutunuz, bağlantınız ve verim oranınızla çalıştırıyor; seed süresini ve günlük incremental süresini tarayıcınızda gösteriyor.
Bütçenin geri kalanı için ZeroTAM, Veeam mimarisi ve hardening'in yanında RTO ve RPO dahil recovery stratejisi konusunda danışmanlık veriyor. ZeroMON job ve SLA durumunu, Veeam Backup & Replication sunucunuzun build ve patch seviyesini izliyor; başarısız session'ları e-posta ve uygulama içi bildirimle haber veriyor. Yeniden denemelerden sonra da task'ı başarısız olan bir VM, RPA'sına bir aralık daha ekler. ZeroPEN, gerçek backup'ları silmeden ya da veri şifrelemeden, bir saldırganın Veeam'e karşı backup neutralization dahil ne kadar ilerleyebildiğini test ediyor; böylece ransomware RTA'nızın dayandığı backup'ların, test ettiğimiz saldırı yollarından sağ çıkıp çıkmadığını görürsünüz.