Kurumsal Sunucu Yedekleme: RPO ve RTO Nasıl Belirlenir?

Kurumsal sunucu yedekleme, yalnızca dosyaların başka bir diske kopyalanması değildir. ERP, SQL Server, Active Directory ve dosya sunucularının kesinti sonrası hangi tarihteki veriye, ne kadar sürede ve kimin sorumluluğunda döndürüleceği, satın alınan yedekleme hizmetinin gerçek değerini belirler. Bu iki soruya teknik ve ticari yanıt veren ölçüler RPO (Recovery Point Objective) ile RTO (Recovery Time Objective) olarak adlandırılır.

Kısa cevap: RPO, kurtarma sonrası kabul edilebilir veri kaybını zaman cinsinden tanımlar; RTO ise uygulamanın yeniden kullanılabilir hale gelmesi için tolere edilen en uzun kesinti süresidir. RPO'yu yalnız yedek sıklığına, RTO'yu yalnız sanal makinenin açılma hızına eşitlemeyin. Önce iş birimlerinin kayıp ve kesinti toleransını belirleyin; sonra yedekleme ve felaket kurtarma hizmetlerini bu iki hedefi test edebilen mimariler üzerinden karşılaştırın.

NIST'in RPO ve RTO tanımları ile AWS'nin felaket kurtarma hedefleri rehberi aynı kritik ayrımı vurgular: hedefler iş ihtiyacından doğar, kullanılan donanım veya yedekleme yazılımı tarafından kendiliğinden belirlenmez.

1. RPO nedir? Ne kadar verinin kaybı kabul edilebilir?

RPO (kurtarma noktası hedefi), sistemin kesildiği ana göre verinin hangi geçmiş noktaya kadar kurtarılabilmesinin kabul edileceğini söyler. Örneğin RPO 30 dakika olarak belirlenirse, uygun senaryoda en fazla 30 dakikalık işlemin yeniden girilmesini gerektirebilecek kayıp sınırı hedeflenir.

Saat 14.00'te bir muhasebe sunucusu durduğunda, en son kullanılabilir ve tutarlı veri noktası 13.45 ise bu örnekte fiili kurtarma noktası farkı 15 dakikadır. Ancak 13.45'te planlanmış bir görev, görev başarısız olmuşsa gerçek kurtarma noktası sayılmaz. Son başarılı ve geri yüklenebilir kopyanın zamanı esastır.

Yedekleme sıklığının 30 dakika olması, her olayda 30 dakikalık RPO garantisi vermez. İşlem bitiş süresi, kopyanın farklı hedefe aktarılması, log zincirinin bütünlüğü, uygulama tutarlılığı ve bozulma tespit süresi sonucu etkileyebilir.

2. RTO nedir? Sunucunun açılması neden yeterli değil?

RTO (kurtarma süresi hedefi), bir hizmetin kesintiden sonra yeniden kullanılabilir olması için belirlenen azami kabul edilebilir süredir. Kurum, ödeme işlemleri veya depo sevkiyatı gibi kritik bir sürecin dört saatten uzun duramayacağını söylüyorsa RTO için başlangıç noktası bu iş etkisidir.

Buradaki ölçü yalnız Windows veya Linux'un açılış süresi değildir. Sanal makine, veritabanı, DNS, Active Directory, VPN, dosya izinleri, uygulama lisansı ve gerçek kullanıcı işlemi birlikte çalışmalıdır. ERP ekranı açılıyor ama sipariş kaydedilemiyorsa hizmet kurtarılmış sayılmaz.

RTO'ya müdahalenin başlama süresi, uygun kurtarma noktasının seçilmesi, veri aktarımı, sistemlerin ayağa kaldırılması, servis kontrolleri ve iş biriminin kabulü dahildir. Sadece yedek yazılımının raporladığı “restore completed” kaydıyla ölçülen süre işletmenin RTO'sunu kanıtlamaz.

3. RPO ve RTO arasındaki fark: örnek zaman çizelgesi

Bir şirketin sipariş veritabanını ele alalım. Bu bölümdeki rakamlar öğretici örnektir; Netsun Bilişim'e ait müşteri ölçümü veya hizmet garantisi değildir.

Bu örnekte gerçekleşen veri noktası farkı 20 dakika, gerçekleşen kurtarma süresi 90 dakika olur. Bir iş birimi RPO hedefini 15 dakika, RTO hedefini 60 dakika belirlemişse bu test, hedeflerin ikisinin de karşılanmadığını gösterir.

Ayrıca veritabanı 09.40'a dönerken başka bir uygulamanın 09.55 verisiyle açılması tutarsız sipariş kayıtları üretebilir. Birbirine bağımlı sistemlerde tek tek sunucu hedefleri değil, işlemin uçtan uca tutarlı çalışması önemlidir.

4. RPO ve RTO hedeflerini kim belirlemeli?

Hedefleri yalnız sistem yöneticisinin seçmesi doğru değildir. Finans, üretim, satış ve operasyon sorumluları iş kesintisinin etkisini açıklar; BT ekibi ve hizmet sağlayıcı bu toleranslara uygun alternatiflerin teknik ve mali sonuçlarını değerlendirir.

Önce bir iş etki analizi (Business Impact Analysis, BIA) oluşturun. “Bu sistem durunca hangi süreç durur?”, “Bekleyen siparişler yeniden girilebilir mi?”, “Manuel çalışma kaç saat sürdürülebilir?”, “Mevzuat, mutabakat veya hizmet sözleşmesi hangi sınırları getiriyor?” sorularına yanıt aranmalıdır.

NIST'in bilgi sistemleri süreklilik planlaması yaklaşımı, MTD (azami tolere edilebilir kesinti), RTO ve RPO'nun işletmenin etkileriyle ilişkilendirilmesini önerir. Böylece her sunucuya gelişigüzel “15 dakika RPO, bir saat RTO” yazmak yerine gerekçeli hedef belirlenebilir.

5. ERP, SQL, dosya ve Active Directory için örnek öncelik matrisi

Aşağıdaki rakamlar kapasite planlaması görüşmesi başlatan kurgusal değerlerdir; sektör standardı, ürün gereksinimi veya sunulmuş bir SLA değildir.

Bu tablodaki ERP ihtiyacı için yalnız ERP ve muhasebe uygulaması altyapısını büyütmek yeterli değildir; aynı veritabanının hangi işlem noktasına dönebildiği de test edilmelidir. Dosya sunucusunda ise paylaşımların NTFS/SMB izinleri ve ağ bağlantısı, AD tarafında ise etki alanı bütünlüğü dikkate alınır.

Kritik iş yükü sayısı arttıkça ortak altyapı bağımlılıkları ve kurtarma sırası önem kazanır. Bu nedenle bütün sistemlere aynı yedekleme planını uygulamak yerine bir hizmet öncelik listesi çıkarın.

6. Günlük yedek, snapshot ve replikasyon aynı işi mi yapar?

Hayır. Yedekleme, verinin farklı bir kurtarma noktasından geri alınması için kopya üretir. Snapshot, desteklenen platformda belirli bir andaki durumun yakalanmasına yardımcı olabilir; tek başına ayrı lokasyonda bağımsız yedek demek değildir. Replikasyon ise değişiklikleri ikinci ortama taşır; bazı iş yüklerinde daha hızlı kurtarma seçenekleri sağlayabilir.

Replikasyonun bir riski, yanlışlıkla silinen veya şifrelenen verinin ikinci kopyaya da taşınabilmesidir. Snapshot aynı depolama sisteminin arızasına bağımlıysa iki ayrı kurtarma ortamı sağlamaz. Bu yüzden “yüksek erişilebilirlik var, ayrıca yedeğe gerek yok” yaklaşımı uygun değildir.

Gereksinimlere göre VPS ve bulut sunucu ortamında snapshot, uygulama tutarlı yedek ve farklı güvenlik alanındaki ikinci kopya birlikte planlanabilir. Seçeneklerin RPO/RTO'ya katkısı test edilmeden garanti beyanı verilmemelidir.

7. SQL Server'da düşük RPO için log yedekleri ne sağlar?

SQL Server'da veritabanı kurtarma modeli kritik bir etkendir. Full recovery model, doğru kurulduğunda tam ve gerektiğinde diferansiyel yedeklerin ardından uygun işlem günlüğü (transaction log) zincirinin geri yüklenmesine olanak sağlar. Bu sayede desteklenen koşullarda belirli bir zaman noktasına dönüş planlanabilir.

Microsoft'un tam kurtarma modelinde restore rehberi ve işlem günlüğü geri yükleme belgesi zincir sırası ve uyumluluk koşullarını açıklar. Her veritabanı modelinde aynı ayrıntıda zamana dönük kurtarma yapılabileceği düşünülmemelidir.

Örneğin log yedeklerini sıklaştırmak hedef RPO'yu iyileştirebilir; fakat yedeklerin korunması, log zincirinin kopmaması, kaynak disk arızaları ve tam restore süresi ayrıca değerlendirilmelidir. Daha sık log yedeği tek başına kısa RTO anlamına gelmez.

8. Yedekleme altyapısı nasıl farklı arıza alanına ayrılır?

Üretim ile yedeğin aynı yönetici hesabı, aynı kabin veya aynı depolama üzerinde bulunması ortak arıza ve saldırı riskini artırabilir. Ayrı yetki alanı, farklı depolama, uygun coğrafi veya mantıksal izolasyon ve erişim kayıtları değerlendirilmelidir.

3-2-1-1-0 yaklaşımı; birden çok kopyayı, farklı depolama tiplerini, saha dışı kopyayı, değiştirilemez veya çevrimdışı korumayı ve testten geçen kurtarma doğrulamasını bir arada düşünmeye yardımcı olur. Ancak bu kuralı izlemek belirli bir RTO'nun otomatik sağlandığı anlamına gelmez.

Veeam'in yedekleme dayanıklılığı rehberi, kopyaların test edilebilirliğini vurgular. Depolama özelinde teknik seçenekleri anlamak için ayrıca sitemizdeki Veeam immutable yedekleme deposu rehberine bakabilirsiniz.

9. Sunucu kaynakları ve bağlantı hızı RTO'yu nasıl etkiler?

Birden fazla TB verinin farklı lokasyondan geri yüklenmesi, ağ kapasitesine ve hedef diskin yazma performansına bağlı olabilir. Yalnız internet portunun kâğıt üzerinde 1 Gbps görünmesi, verinin bu hızda geri yükleneceği anlamına gelmez; gecikme, dosya sayısı, sıkıştırma, paylaşılan kaynak ve uygulama doğrulaması gerçek süreyi etkiler.

RTO çalışmasında veri boyutu, değişim oranı, depolama IOPS/gecikme profili, hedef sunucuda CPU/RAM, şifre çözme ve bağlantı yolu birlikte ele alınmalıdır. Kritik uygulamanın geri dönüşte çalışacağı platform önceden hazırlanmadıysa yeni sunucu kurma süresi de hedefe eklenir.

Yüksek kaynak ihtiyacı olan dedicated sunucu seçimi bazı senaryolarda performans öngörülebilirliğine yardımcı olabilir. Ancak daha güçlü sunucu, yanlış tasarlanmış geri yükleme zincirini ya da eksik DNS ve uygulama bağımlılıklarını kendiliğinden düzeltmez.

10. Gerçek kurtarma testi nasıl yapılmalı ve raporlanmalı?

Başarılı bir yedekleme işi, başarıyla kurtarılmış bir iş uygulaması demek değildir. Önce üretim verisini açığa çıkarmayan yetkili test ortamı belirleyin; sonra seçilen tarihli kopyadan kurtarmayı gerçek kullanıcı senaryolarıyla sınayın.

Kontrol listesi: yedek nesnesi ve tarihinin seçilmesi, kurtarma başlangıç/bitiş saatlerinin kaydı, veritabanı tutarlılığı, dosya/izin kontrolü, uygulama oturum açma, kritik iş akışı ve iş birimi kabulü. Gerçekleşen veri noktası farkı ile kurtarma süresi hedeflerden ayrı raporlanmalıdır.

Test sonuçlarını tek bir “PASS” ifadesine indirmeyin. Başarısız adımlar, kullanıcı etkisi, kurtarma sırasında gereken manuel işlem, otomasyon boşlukları ve düzeltme sahibi yazılmalıdır. Tekrar test edilmeden kapatılan bir bulgu, hedeflerin sağlandığını göstermez.

11. Yönetilen yedekleme hizmetinde sorumluluk kime ait?

Kurumsal tekliflerde en sık karşılaşılan belirsizlik, yedekleme işinin kimin sorumluluğunda olduğu değil, geri yükleme kararını ve uygulama kabulünü kimin vereceği sorusudur. Hizmet sağlayıcı yedek yazılımını yönetirken uygulama üreticisi SQL tutarlılığından, kurum da kurtarma noktasının iş açısından kabulünden sorumlu olabilir.

Bu ayrımı sözleşmeye yazın: yedek politikası sahibi, izleme ve alarm alıcısı, ilk müdahale kişisi, erişim onaylayan yönetici, SQL veya ERP doğrulayıcısı, olay iletişimi, destek saatleri ve test raporunu imzalayan taraf.

Yönetilen sunucu hizmetleri kapsamında izleme ve bakımın sunulması, felaket kurtarma operasyonunun tüm kalemlerinin otomatik dahil olduğu anlamına gelmez. Ayrı kapsam ve ücret kalemleri açık gösterilmelidir.

12. Fidye yazılımı durumunda RPO ve RTO neden daha zor olabilir?

Sıradan donanım arızasında en son yedekten dönmek çoğu zaman makul bir adım gibi görünür. Fidye yazılımında ise en yeni kopya da etkilenmiş olabilir. Olayın ilk başladığı an, saldırganın yetki elde ettiği tarih ve güvenilir veri noktasının tespiti süreci uzatabilir.

Bu yüzden kurtarma planında erişim izolasyonu, yedek yönetim hesaplarının korunması, çevrimdışı veya uygun immutable kopya, temiz sistem kurulumu ve kötü amaçlı yazılım kontrolü ayrı aşamalar olmalıdır. Sıfır dakika veri kaybı veya kesintisiz geri dönüş iddiası, uygulanabilirliği test edilmeden verilmemelidir.

Firewall ve ağ güvenliği çözümleri erişim yüzeyini azaltmaya yardımcı olabilir; fakat ağ güvenliği, tutarlı yedek ve geri yükleme testinin yerine geçmez.

13. RPO ve RTO hedefleri yedekleme fiyatını nasıl değiştirir?

Daha düşük veri kaybı toleransı genellikle daha sık kurtarma noktası, daha fazla veri akışı ve farklı koruma teknikleri gerektirebilir. Daha kısa RTO ise hazır bekleyen kaynaklar, hızlı depolama, önceden kurulmuş ağ, otomasyon ve daha sık tatbikat ihtiyacı oluşturabilir. Her iki hedefi de en düşük sayıya indirmek, maliyeti ve işletim karmaşıklığını artırabilir.

Teklifi yalnız “kaç TB yedekleme alanı” üzerinden karşılaştırmayın. Saklama süresi, günlük değişim hacmi, ayrı lokasyon, immutable koruma, bağlantı kapasitesi, lisans, test sıklığı, kurtarma operasyonunun kimde olduğu ve veri çıkış koşulları fiyatı etkiler.

Her şirketin hedefi farklıdır; bu makalede fiyat, kesin kurtarma süresi, müşteri SLA'sı veya belirli bir ürün garantisi verilmemiştir. İyi teklif, varsayımları ve hariç tutulan kalemleri görünür kılar.

14. Teklif almadan önce doldurulacak RPO/RTO ihtiyaç listesi

İş birimleriyle kısa bir toplantı yapıp koruma kapsamını yazılı hale getirin: uygulama adı, veri sahibi, kullanıcı/şube sayısı, bağımlı veritabanları, mevcut yedek yöntemi, veri hacmi ve günlük değişim oranı, en son başarılı restore testi, kabul edilebilir veri kaybı ve kesinti süresi.

Ayrıca hangi olay senaryolarının kapsanacağını belirtin: yanlışlıkla silme, sunucu disk arızası, fidye yazılımı, veri merkezi erişim kesintisi ve tam lokasyon kaybı. Aynı hedefin her senaryoda aynı maliyetle sağlanabileceği varsayılmamalıdır.

Netsun Bilişim ile teknik keşif: Mevcut sunucularınız ve iş uygulamalarınız için RPO/RTO tablosu çıkarıp kurtarma mimarisini, yedek kopyalarını, güvenlik sınırlarını ve test sorumluluklarını ayrı kalemlerle planlayabiliriz. Kurumsal sunucu yedekleme ve felaket kurtarma teklifi alın.

Resmî teknik kaynaklar

Tanımlar ve yöntem için NIST RPO, NIST RTO, AWS Disaster Recovery Objectives, Microsoft SQL Server full recovery restore ve Microsoft log backup restore belgelerini inceleyin. Bunlar teknik rehberdir; belirli bir müşteriye sunulan sözleşmesel garanti değildir.

Sık sorulan sorular

1. RPO ile RTO arasındaki fark nedir?

RPO, kurtarma sırasında en fazla ne kadar geçmişe dönülebileceğine ilişkin veri kaybı toleransıdır. RTO, kesintiden sonra hizmetin kullanılabilir duruma gelmesi için kabul edilen süredir.

2. Her saat yedek almak RPO'nun kesin bir saat olduğu anlamına gelir mi?

Hayır. Son başarılı ve uygulama tutarlı kopya, aktarım ve erişilebilirlik dikkate alınır. Yedek görevi başarısızsa fiili veri kaybı hedefi aşabilir.

3. RTO yalnız sunucunun yeniden açıldığı ana kadar mı hesaplanır?

Hayır. Kullanıcının gerçek uygulamada kritik işlemi tamamlayabildiği ana kadar olan müdahale ve doğrulama süresi de dikkate alınmalıdır.

4. ERP veya SQL Server için 15 dakika RPO nasıl değerlendirilir?

Uygun veritabanı kurtarma modeli, log yedekleri veya desteklenen veri koruma yöntemi ile farklı seçenekler incelenir. RPO yalnız görev sıklığıyla değil test edilmiş geri yükleme noktasıyla doğrulanır.

5. Snapshot, immutable yedekleme yerine geçer mi?

Hayır. Snapshot her zaman ayrı arıza alanındaki bağımsız yedek değildir. Immutable kopya da tek başına hızlı RTO garantisi vermez; birlikte değerlendirilmelidir.

6. Replikasyon varsa ayrıca yedek almaya gerek var mı?

Çoğu kurumsal senaryoda ayrıca yedek gerekir. Yanlış veri değişiklikleri veya silinme ikinci ortama da aktarılabilir; geçmişe dönebilmek için bağımsız kurtarma noktaları önemlidir.

7. RPO ve RTO'yu IT mi, yönetim mi belirlemeli?

İş birimleri kayıp ve kesinti toleransını belirler; BT ve sağlayıcı teknik uygulanabilirliği ve maliyeti değerlendirir. Hedefler yetkili iş sahibi tarafından onaylanmalıdır.

8. Sunucu yedekleme teklifi için hangi bilgileri paylaşmalıyım?

İş yükleri, veri hacmi ve değişim oranı, RPO/RTO hedefleri, mevcut yedek ve kurtarma testleri, lokasyon, güvenlik, lisans ve yönetim beklentilerini paylaşın. Teknik yedekleme teklifi isteyin.