RPO/RTO Hedefine Göre Teknoloji Seçimi: Yedek, Replika ve Cluster

Yönetim “ERP için RPO 15 dakika, RTO 4 saat” diye imzayı atar; altyapıda ise hâlâ gece 23:00’te çalışan tek bir yedek işi vardır. Kâğıttaki hedefle sunucu odasındaki gerçek arasındaki bu açık, ilk ciddi arızada ortaya çıkar. Aşağıda onaylı hedeflerden yola çıkıp sistemleri kademelere ayırıyor, her kademeye uygun teknolojiyi (günlük yedek, sık snapshot, replikasyon, cluster, sürekli veri koruma) seçiyor ve gerçek geri dönüş süresini ölçüp hedefle karşılaştırıyoruz.

RPO ve RTO’nun teknik anlamı

RPO (Recovery Point Objective), bir kesinti sonrasında kabul edilebilecek en fazla veri kaybını zaman cinsinden ifade eder. Teknik karşılığı, en son geçerli kurtarma noktası ile olay anı arasındaki boşluktur. Günde bir kez gece 23:00’te alınan yedek, ertesi gün 22:59’da yaşanan bir arızada yaklaşık 24 saatlik veri kaybı demektir. Günlük yedeğin gerçek RPO’su bu yüzden “1 gün” değildir; en kötü durumda yedek aralığı artı yedeğin tamamlanma süresidir. Hesabı buna göre yapın.

RTO (Recovery Time Objective), hizmetin yeniden kullanılabilir hale gelmesi için kabul edilen en uzun süredir. Sahada en sık gördüğümüz yanılgı, RTO’yu yedek yazılımının gösterdiği aktarım süresiyle eşitlemektir. Oysa RTO şu bileşenlerin toplamıdır:

• Tespit ve karar süresi: arızanın fark edilmesi, kurtarma kararının verilmesi.
• Altyapı hazırlığı: hedef host, depolama, ağ ve kimlik hizmetlerinin ayağa kalkması.
• Veri aktarımı veya devreye alma: geri yükleme, replika failover’ı ya da cluster rol geçişi.
• Uygulama doğrulaması: servislerin başlaması, veritabanı tutarlılığı, kullanıcı erişim testi.

Hedef belirleme sürecinin kendisi (iş etki analizi, MTPD ve onay) bir yönetim konusudur ve MTPD, RTO ve RPO hedeflerinin belirlenmesi ve onaylanması yazısında anlatılıyor. Burada hedefler elinizde, onaylı ve yazılı kabul ediliyor.

Sistemleri kademelere ayırma

Sunucu ve sistem altyapısındaki her sunucuya ayrı hedef yazarsanız elinizde kimsenin güncellemediği yüz satırlık bir tablo kalır. Sistemleri aynı teknolojiyle korunabilecek kademelere (tier) gruplayın. Orta ölçekli bir ortam için örnek yapı:

Değerler kurumunuzun onaylı hedeflerinden gelmeli; tablo yalnızca yapıyı gösteriyor. Kademe 0’ı ayrı tutmamızın nedeni basit: geri kalan her şey ona bağlıdır. Domain controller ve DNS ayakta değilse ERP veritabanı açılsa bile kullanıcı oturum açamaz, servis hesapları kimlik doğrulayamaz. DNS yoksa hiçbir şey yok.

Bağımlılık sırası ve geri dönüş zinciri

Bir uygulamanın RTO’su, bağımlı olduğu en yavaş bileşenden kısa olamaz. ERP uygulama sunucusu 30 dakikada ayağa kalksa bile veritabanı 3 saatte geri yükleniyorsa uygulamanın gerçek RTO’su en az 3 saattir. Her Kademe 1 sistemi için bağımlılık zincirini yazıya dökün:

1. Altyapı: hipervizör kümesi, paylaşımlı depolama, çekirdek ağ ve güvenlik duvarı kuralları.
2. Kimlik ve isim çözümleme: en az bir domain controller, DNS, gerekirse sertifika hizmetleri.
3. Veri katmanı: veritabanı sunucuları, dosya paylaşımları.
4. Uygulama katmanı: uygulama sunucuları, lisans sunucuları, entegrasyon servisleri.
5. Erişim katmanı: yük dengeleyici, ters proxy, VPN, uzak masaüstü ağ geçidi.

Zinciri çıkardığınızda neredeyse her ortamda iki sorun çıkar. Birincisi, Kademe 2 diye etiketlenmiş ama Kademe 1 uygulamasının çalışması için şart olan bir sistemdir; tipik örnek, kimsenin hatırlamadığı lisans sunucusudur. İkincisi, paralel geri yükleneceği varsayılan ama aynı depolamayı veya aynı proxy’yi paylaştığı için fiilen sıraya giren sistemlerdir. Kâğıtta paralel, sahada seri. Bu sıranın adım adım nasıl dokümante edileceği felaket kurtarma runbook’u hazırlama yazısının konusudur.

Hedef–teknoloji eşleme tablosu

Her teknoloji belirli bir RPO/RTO bandını makul maliyetle karşılar. Tablo karar için başlangıç noktasıdır; gerçek değerler ürüne, yapılandırmaya ve bant genişliğine göre değişir.

Tablonun asıl dersi şu: yüksek erişilebilirlik teknolojileri yedeğin yerini tutmaz. Cluster, AG ve senkron replikasyon, yanlışlıkla çalıştırılan bir DELETE komutunu ya da fidye yazılımının şifrelediği blokları da milisaniyeler içinde karşı tarafa taşır. Replika sadık bir kopyadır. Hatayı da kopyalar. Mantıksal hatalara karşı RPO ancak geçmişe dönük kurtarma noktaları tutan yedek ve log yedekleriyle sağlanır. Kademe 0 ve 1 sistemlerinde bu yüzden iki katmanı birlikte kurarız: altyapı arızası için replika veya cluster, mantıksal hata için sık yedek. Replikasyon seçeneklerinin uygulama ayrıntıları Hyper-V Replica, Veeam ve depolama replikasyonu yazısında; cluster tasarımı Hyper-V failover cluster planlama yazısında anlatılıyor.

Maliyet ve karmaşıklık dengesi

RPO’yu saatlerden dakikalara indirmek çoğunlukla ikinci bir site veya bulut hedefi, ek lisans ve sürekli bant genişliği ister. RTO’yu saatlerden dakikalara indirmek ise boşta bekleyen hesaplama kapasitesi demektir. Her kademe için şunu sorun: hedefi bir alt teknolojiyle, örneğin replikasyon yerine sık yedek ve anında başlatma ile karşılayabilir miyiz? Cevap evetse karmaşıklığı artırmayın. Her ek katman, gece 03:00’te arıza ayıklanacak bir bileşen daha demektir.

Geri yükleme süresini ölçme

RTO’nun karşılandığını söylemenin tek yolu ölçmektir. Ürün belgelerindeki aktarım hızları veya yedek işinin süresi geri yükleme süresini göstermez. Geri yükleme yolu (depodan okuma, ağ, hedef depolamaya yazma) yedekleme yolundan farklı darboğazlara takılır; deduplikasyonlu bir depo yazarken hızlıdır, rastgele okurken çoğu zaman değildir. Tahmin değil, kronometre. Ölçüm için:

• Her kademeden temsili bir sistemi izole bir ağda tam olarak geri yükleyin ve başlangıç–bitiş zamanını kaydedin.
• Süreyi bileşenlere ayırın: depodan veri aktarımı, VM kaydı ve açılışı, servislerin başlaması, uygulama doğrulaması.
• Eşzamanlılığı test edin: tek VM’nin 40 dakikada döndüğü bir ortamda on VM aynı anda geri yüklendiğinde süre doğrusal artmayabilir ama mutlaka uzar.
• Veeam SureBackup veya benzeri otomatik doğrulama özellikleri, VM’nin açılıp temel servislerinin yanıt verdiğini düzenli olarak kanıtlamak için kullanılabilir.

Hyper-V ortamında tam geri yükleme sonrası VM’nin ne kadar sürede yanıt verdiğini PowerShell ile basitçe ölçebilirsiniz:

$basla = Get-Date
Start-VM -Name "ERP-DB01"
do { Start-Sleep -Seconds 5 }
until (Test-NetConnection -ComputerName "erp-db01" -Port 1433 -InformationLevel Quiet -WarningAction SilentlyContinue)
"SQL portu yanıt verdi: {0:N1} dakika" -f ((Get-Date) - $basla).TotalMinutes

Bu ölçüm yalnızca açılış ve servis başlatma süresini verir. Port açıldı diye uygulama çalışıyor sayılmaz; toplam RTO’ya veri aktarım süresini ve anahtar kullanıcının gerçek bir işlem yapıp yapamadığını da ekleyin. Geri yükleme testini düzenli alışkanlığa çevirmenin yolu 3-2-1-1-0 kuralı ve geri yükleme testi yazısında ayrıntılı olarak ele alınıyor.

Örnek hesap

Kademe 1’deki bir ERP veritabanı sunucusu için hedefin mevcut altyapıyla karşılanıp karşılanmadığına bakalım. Değerler varsayımdır; kendi test geri yüklemenizden gelen sayıları koyun.

Kâğıt üzerinde RTO karşılanıyor. Pay ise 25 dakika. Aynı anda iki Kademe 1 sistemi daha geri yüklenecekse 250 MB/s paylaşılır ve hedef aşılır. RPO tarafında 15 dakikalık log yedeği aralığı hedefi karşılıyor gibi görünür; ama log yedekleri yalnızca aynı sunucunun yerel diskinde duruyorsa sunucuyla birlikte onlar da gider ve gerçek RPO son kopyalamanın zamanına geriler. Bu hatayı denetimlerde sık görüyoruz.

Hedef ile gerçek arasındaki açığı kapatma

Ölçüm sonuçlarını hedefin yanına koyduğunuzda açık genellikle şu kalıplardan birine uyar:

• Aktarım darboğazı: Depo yavaş diskler üzerinde veya 1 GbE ağ arkasında. Çözüm: geri yükleme yolunu hızlandırmak (daha hızlı depo katmanı, 10/25 GbE, yerel kopya) ya da anında başlatma ile hizmeti önce açıp veriyi arka planda taşımak.
• Sıralama darboğazı: Kademe 0 sistemleri geç dönüyor. Çözüm: ikinci sitede sürekli çalışan bir domain controller, kimlik hizmetlerini geri yükleme yerine replikasyonla korumak.
• Eşzamanlılık darboğazı: Tek proxy veya tek depo ağ bağlantısı tüm geri yüklemeleri sıraya sokuyor. Çözüm: proxy ve depo kapasitesini felaket senaryosuna göre boyutlandırmak.
• RPO boşluğu: Yedek aralığı uygun ama kopyalar aynı yerde. Çözüm: log ve artımlı yedeklerin kısa aralıkla ikinci konuma kopyalanması.
• Hedefin kendisi gerçekçi değil: Teknik olarak karşılamanın maliyeti kabul edilmiyorsa, ölçüm sonuçlarıyla hedefin yeniden onaya sunulması gerekir. Hedefi sessizce “yaklaşık karşılanıyor” saymak, sürprizi felaket gününe ertelemektir.

Hedeflerin teknik karşılığını ölçüp açıkları altyapı tasarımına yansıtırken birlikte çalışmak isterseniz yedekleme ve felaket kurtarma ile altyapı danışmanlığı sayfalarımızda yaklaşımımızı bulabilirsiniz. Kavramsal çerçeve için NIST’in SP 800-34 Rev. 1 bilgi sistemleri olağanüstü durum planlama rehberi iyi bir birincil kaynaktır.

Sık sorulan sorular

RPO ve RTO arasındaki fark nedir?

RPO, kabul edilebilir en fazla veri kaybıdır ve kurtarma noktalarının sıklığına bağlıdır. RTO, hizmetin yeniden kullanılabilir olması için kabul edilen en uzun süredir; geri yükleme, failover ve doğrulama hızına bağlıdır.

Replikasyon varsa ayrıca yedek almak gerekir mi?

Evet. Replikasyon ve cluster donanım veya site kaybında hızlı dönüş sağlar, ama silme, bozulma ve şifrelemeyi de karşı tarafa taşır. Geçmişe dönük kurtarma noktası yalnızca yedekte vardır.

RTO nasıl ölçülür?

Her kademeden temsili bir sistemi izole bir ortamda gerçekten geri yükleyin; tespit, altyapı hazırlığı, veri aktarımı ve uygulama doğrulaması sürelerini ayrı ayrı kaydedin. Birden fazla sistemin aynı anda geri yüklendiği senaryoyu da test edin.

Günlük yedeğin gerçek RPO’su neden 24 saatten uzun olabilir?

Olay bir sonraki yedekten hemen önce yaşanırsa kayıp, yedek aralığı kadardır; buna yedeğin tamamlanma süresi ve kopyanın ikinci konuma ulaşma süresi eklenir. Yedek, arızadan etkilenen aynı yerde duruyorsa RPO daha da geriye gider.