Felaket kurtarma metrikleri: RTO kurtarma süresi ve RPO veri kaybı hedefleri nasıl belirlenir? Fabrikalarda kesinti maliyeti hesaplama adımları burada.
Hızlı Özet (TL;DR)
Kurumsal iş sürekliliği ve felaket kurtarma (Disaster Recovery - DR) mühendisliğinin iki temel matematiksel direği RTO ve RPO metrikleridir. RTO (Recovery Time Objective - Kurtarma Süresi Hedefi), bir siber saldırı, donanım arızası veya fiziksel felaket sonrasında sistemin çökmesi ile yeniden ayağa kalkıp üretime/operasyona hizmet vermeye başlaması arasında geçebilecek maksimum kabul edilebilir süredir. RPO (Recovery Point Objective - Kurtarma Noktası Hedefi) ise sistem kurtarıldığında geriye dönük olarak en fazla kaç dakikalık veya saatlik verinin kaybolabileceğini (son sağlam yedeğin ne kadar eski olabileceğini) tanımlayan metriktir. RTO ve RPO hedeflerini sıfıra yaklaştırmak altyapı yatırım maliyetini logaritmik olarak artırır; bu nedenle fabrikalarda önce Saatlik Kesinti Maliyeti (Cost of Downtime) hesaplanmalı ve her yazılım/veri katmanı için optimum mühendislik dengesi kurulmalıdır.
RTO ve RPO Kavramlarının Zaman Çizelgesi Üzerindeki Yeri
Bir felaket anını (örneğin saat 14:00’te sunucu odasındaki RAID kartının yanması veya fidye yazılımının sanal makineleri şifrelemesi) zaman ekseninde sıfır noktası (T0) olarak kabul ettiğimizde:
- RPO (Geçmişe Bakar - Veri Kaybı Hacmi): Felaket saat 14:00’te yaşandığında en son sağlam ve değiştirilemez yedeğiniz saat 13:45’te alınmışsa, sistem ayağa kalktığında yalnızca 13:45 ile 14:00 arasındaki 15 dakikalık stok hareketlerini ve irsaliyeleri yeniden girmeniz gerekir. Burada RPO değeriniz 15 dakikadır. Eğer yedeklemeyi sadece gece 23:59’da alıyorsanız, saat 14:00’teki çöküşte sabahtan beri yapılan tüm üretim ve muhasebe kayıtları silinir; RPO değeriniz 14 saattir.
- RTO (Geleceğe Bakar - Kesinti ve Bekleme Süresi): Saat 14:00’te çöken ERP ve barkod sistemini yedek sunucu üzerinde yeniden çalıştırıp operatörlerin el terminallerinden tekrar okutma yapabildiği an saat 14:30 ise, RTO başarımınız 30 dakikadır. Sistem ertesi gün öğlene kadar açılamıyorsa fabrika 22 saat boyunca durmuş veya kağıt-kalemle kör uçuş yapmış demektir.
MTPD (Maksimum Kabul Edilebilir Kesinti Süresi) ve WRT (İş Kurtarma Süresi)
ISO 22301 standartlarında RTO hesaplanırken iki yardımcı parametre daha kullanılır:
- WRT (Work Recovery Time): Sanal makine ve veritabanı teknik olarak ayağa kalktıktan sonra (RTO tamamlandıktan sonra), verilerin tutarlılığının kontrol edilmesi, yarıda kalan iş emirlerinin düzeltilmesi ve kayıp RPO dilimindeki irsaliyelerin sisteme manuel girilmesi için geçen süredir.
- MTPD (Maximum Tolerable Period of Disruption):
RTO + WRT < MTPDolmak zorundadır. Yani teknik kurtarma süresi ile veri doğrulama süresinin toplamı, şirketin telafisi imkânsız ticari veya yasal yıkıma uğrayacağı maksimum kesinti sınırını asla aşmamalıdır.
RTO ve RPO Karşılaştırma Tablosu
İki kritik süreklilik metriği arasındaki operasyonel, mimari ve finansal farklar aşağıda özetlenmiştir:
| Kriter | RTO (Kurtarma Süresi Hedefi) | RPO (Kurtarma Noktası Hedefi) |
|---|---|---|
| Temel Mühendislik Sorusu | “Sistem çöktüğünde ne kadar sürede tekrar çalışır hale gelecek?” | “En fazla kaç dakikalık/saatlik veriyi kaybetmeyi göze alabiliriz?” |
| Zaman Eksenindeki Yönü | Olay anından geleceğe doğru (Sistemin açılış anına kadar) | Olay anından geçmişe doğru (En son sağlam yedeğe kadar) |
| Odak Alanı ve Ölçtüğü Zarar | Operasyonel duruş süresi, üretim bandı beklemesi ve ciro kaybı | Veri kaybı hacmi, yeniden veri giriş işçiliği ve stok/muhasebe farkı |
| Belirleyici Teknoloji Faktörü | Donanım yedekliliği, High Availability (HA) Cluster, NVMe disk hızı ve Anlık VM Kurtarma (Instant Restore) | ZFS Snapshot periyotları, asenkron/senkron replikasyon ve veritabanı işlem kütüğü (Transaction Log) |
| Tipik Sanayi Örneği | “Barkodlu WMS ve ERP sunucusu çökerse en geç 30 dakika içinde devrede olmalı” | “En fazla son 15 dakikalık üretim ve kalite kontrol kaydının tekrar girilmesine tahammülümüz var” |
| Sıfıra Yaklaştırma Maliyeti | Çift sunucu odası, Active-Active veya Active-Passive Failover kümesi | Sürekli Veri Koruma (CDP), çift lokasyonlu senkron depolama kümesi |
Fabrikalarda Saatlik Kesinti Maliyeti (Cost of Downtime) Nasıl Hesaplanır?
Bir yönetim kurulu başkanına veya fabrika sahibine neden 5.000 dolarlık basit bir NAS kutusu yerine kurumsal bir yedekli sanallaştırma ve ZFS depolama mimarisi kurulması gerektiğini anlatmanın en doğru yolu, 1 saatlik plansız duruşun şirkete faturasını matematiksel olarak ortaya koymaktır.
Sanayi tesislerinde saatlik kesinti maliyeti şu mühendislik formülüyle hesaplanır:
Saatlik Kesinti Maliyeti = (Kayıp Ciro / Çalışma Saati)
+ (Mavi ve Beyaz Yaka Atıl İş Gücü Maliyeti)
+ (Hammadde Hurda / Yarı Mamul Bozulma Maliyeti)
+ (Gecikme Cezası + Fazla Mesai Telafi Maliyeti)
Gerçek Bir Fabrika Üzerinden Maliyet Simülasyonu
Yıllık cirosu 240 Milyon TL olan, yılda 300 gün ve günde 2 vardiya (16 saat = yılda 4.800 saat) çalışan, 80 mavi yaka operatör ve 25 beyaz yaka personelin görev yaptığı orta ölçekli bir otomotiv yan sanayi (plastik enjeksiyon ve talaşlı imalat) fabrikasını ele alalım:
- Saatlik Ciro ve Katma Değer Kaybı:
240.000.000 TL / 4.800 Saat = 50.000 TL / Saat. Üretim takip, barkod basımı ve e-İrsaliye sistemi durduğu için sevkiyat rampasından tır çıkamaz, tezgâhlar yeni iş emri alamaz. - Atıl İş Gücü Maliyeti: Sistem çalışmadığı sırada içeride bekleyen 105 personelin işverene saatlik brüt maliyeti ortalama 18.000 TL / Saat düzeyindedir.
- Hurda ve Yeniden Başlatma (Setup) Kaybı: Enjeksiyon makinelerinin veya ısıl işlem fırınlarının plansız durması nedeniyle kovan içinde yanan hammadde ve yeniden rejime girme enerjisi 12.000 TL.
- Telafi Fazla Mesaisi ve Müşteri Ceza Riski: Kaybedilen vardiyayı hafta sonu %100 zamlı fazla mesai ile telafi etmenin ek yükü ve ana sanayi (OEM) hat durdurma cezası riski.
Bu tabloda yalnızca 4 saatlik bir sunucu çöküşünün veya fidye yazılımı duruşunun fabrikaya doğrudan maliyeti 300.000 TL’yi aşmaktadır. Eğer geleneksel yedekten geri dönüş 2 gün (32 çalışma saati) sürerse, oluşan zarar kurumsal bir felaket kurtarma ve yedekli sunucu yatırımının bedelini tek bir olayda katbekat geçmektedir.
Kurumsal Sistemlerde Kritiklik Seviyesi (Tier) Bazlı RTO ve RPO Matrisi
Fabrikadaki her sunucu ve yazılım için aynı RTO/RPO hedefini koymak bütçeyi gereksiz şişirir. Doğru mimaride sistemler kritiklik katmanlarına (Tier) ayrılır:
| Sistem Katmanı | Kapsamdaki Kurumsal Uygulamalar | Hedef RTO (Kurtarma Süresi) | Hedef RPO (Veri Kaybı) | Önerilen Teknik Kurtarma Mimarisi |
|---|---|---|---|---|
| Tier 0: Ağ ve Güvenlik Omurgası | Güvenlik Duvarı (Firewall), Core Switch, DHCP, DNS, Active Directory | < 1 Dakika (Sıfıra Yakın) | 0 Dakika | Donanımsal High Availability (Aktif-Pasif Cluster) ve İkincil Domain Controller |
| Tier 1: Kritik Üretim ve Ticaret | ERP Veritabanı, Üretim Takip Yazılımı (MES), Barkodlu WMS, e-Fatura/e-İrsaliye | 15 – 30 Dakika | 5 – 15 Dakika | NVMe tabanlı Sanallaştırma Kümesi + 15 dakikalık ZFS Snapshot ve Replikasyon |
| Tier 2: Mühendislik ve Ortak Veri | CAD/CAM Teknik Çizim Sunucusu, PDM/PLM, Ortak Dosya Paylaşımları, E-Posta | 1 – 4 Saat | 15 – 60 Dakika | TrueNAS ZFS Kurumsal Depolama + Saatlik Değiştirilemez (Immutable) Snapshot |
| Tier 3: Arşiv ve Destek Sistemleri | Eski Yıl Muhasebe Arşivleri, Kamera Kayıtları (NVR), Eğitim ve İK Portalları | 12 – 24 Saat | 24 Saat | Günlük Sıkıştırılmış Soğuk Yedekleme (Off-Site NAS / Şifreli Bulut / LTO Teyp) |
RPO ve RTO’yu Küçültmenin Mühendislik Yolu: Periyodik ZFS Snapshot ve Instant VM Restore
Geleneksel dosya kopyalama veya gece 23:00’te çalışan klasik yedekleme yazılımlarında iki büyük darboğaz vardır: Birincisi RPO 24 saattir (gün içi veri kaybolur); ikincisi ise 4 Terabaytlık bir dosya sunucusunu harici diskten geri kopyalamak (Restore) 12 ila 18 saat sürer (RTO çok yüksektir).
Maysa Yazılım olarak kurduğumuz TrueNAS ZFS ve Kurumsal Sanallaştırma altyapılarında bu iki sorunu kökünden çözüyoruz:
- 15 Dakikalık RPO (Copy-on-Write ZFS Snapshot): ZFS dosya sistemi, diskteki verinin kopyasını oluştururken veriyi baştan sona kopyalamaz; yalnızca değişen blokların işaretçilerini (Metadata Pointers) dondurur. Bu sayede 10 Terabaytlık bir Ortak Dosya Sunucusu ve Yedekleme havuzunda bile her 15 dakikada bir, sunucuyu hiç yavaşlatmadan (0 saniye gecikmeyle) salt-okunur (Read-Only / Immutable) anlık görüntü alınır. Saat 16:20’de fidye yazılımı bulaşırsa, saat 16:15’teki snapshot’a tek tıkla geri dönülür (Rollback) ve sadece 5 dakikalık veri kaybıyla kriz atlatılır.
- 15 Dakikalık RTO (Anlık Sanal Makine Ayağa Kaldırma): Ana sanallaştırma sunucusu fiziksel olarak yansa bile, ZFS replikasyonu ile ikincil (DR) sunucuya her 15 dakikada bir aktarılan sanal makine imajları doğrudan yedek sunucu üzerinde (veri kopyalamayı beklemeden) başlatılır.
Fabrikanızdaki ERP, Özel İmalat Çözümleri ve teknik çizim arşivlerinizin RTO/RPO hedeflerini dakikalar seviyesine indirmek için Ortak Dosya Sunucusu ve Yedekleme sayfamızı inceleyebilir, kesinti maliyeti analizi için uzmanlarımızdan destek alabilirsiniz.
Sıkça Sorulan Sorular
RPO ve RTO değerlerini tüm sunucularımız için “Sıfır (0 Dakika)” yapabilir miyiz?
Teknik olarak senkron veri replikasyonu ve aktif-aktif sunucu kümeleri (Metro Cluster) ile sıfır RPO ve sıfıra yakın RTO mümkündür. Ancak bu mimari; sunucu, lisans, kurumsal NVMe depolama ve yedekli fiber altyapı maliyetlerini 3 ila 4 katına çıkarır. Bu nedenle finansal optimizasyon gereği yalnızca güvenlik duvarı ve kritik veritabanlarında sıfıra yakın hedefler seçilirken, dosya paylaşımlarında 15 dakikalık ZFS snapshot mimarisi fiyat/performans açısından en akılcı endüstriyel çözümdür.
Bulut yedekleme (Cloud Backup) kullanmak düşük RTO sağlar mı?
Bulut yedekleme, yangın ve deprem gibi fiziksel felaketlere karşı veriyi bina dışında korumak (3-2-1 kuralı) için mükemmeldir ve RPO açısından güvenlidir. Ancak fabrikanızdaki 5 Terabaytlık sanal sunucu imajını internet üzerinden geri indirmek (Download), 100 Mbps’lik bir hatla bile günler sürer. Dolayısıyla düşük RTO (dakikalar içinde ayağa kalkma) için mutlaka fabrika içinde yerel bir hızlı felaket kurtarma sunucusu (Local DR Appliance) bulunmalı, bulut ise ikincil felaket kopyası olarak konumlandırılmalıdır.
Belirlediğimiz RTO süresinin gerçekçi olup olmadığını nasıl anlarız?
Bunu anlamanın tek yolu habersiz ve kronometreli Geri Yükleme Tatbikatı (Restore Drill) yapmaktır. Yedekleme yazılımının “Yedek Başarılı” mesajı vermesi, o yedeğin hedeflenen RTO süresinde çalışacağı anlamına gelmez. En az 3 ayda bir yedeklenen ERP ve dosya sunucusu imajları izole bir test VLAN’ında ayağa kaldırılmalı, veritabanı bütünlüğü kontrol edilmeli ve geçen süre ölçülerek RTO hedefiyle karşılaştırılmalıdır.