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

Kurumsal sunucu yedekleme, yalnız gece otomatik yedek alan bir yazılım kurmaktan ibaret değildir. Bir veritabanı hatası, elektrik kesintisi, fidye yazılımı olayı veya yanlışlıkla silinen veri sonrasında en fazla ne kadar veri kaybedilebileceği ve işin ne kadar süre durabileceği tanımlanmalıdır. Bu soruların teknik karşılığı RPO ve RTO hedefleridir.

Kısa cevap: RPO (Recovery Point Objective) zaman cinsinden kabul edilebilir veri kaybını, RTO (Recovery Time Objective) ise iş sürecinin yeniden çalışır duruma gelmesi için hedeflenen en uzun kesintiyi gösterir. Önce iş biriminin kayıp ve kesinti toleransını ölçün; sonra yedekleme, replikasyon, sunucu kapasitesi ve kurtarma testleriyle hedefleri doğrulayın. Yedekleme ve felaket kurtarma hizmeti için teklif alırken her iş yükünün RPO ve RTO değerini ayrı isteyin.

Bu rehber; Logo, Mikro ve SAP gibi ERP uygulamaları, SQL Server, Active Directory, dosya sunucuları ve e-ticaret sistemleri kullanan Türkiye'deki BT ekipleri için hazırlanmıştır. Verilen tüm sayısal süreler örnek planlama hedefleridir, hiçbir sağlayıcının otomatik garanti veya ölçülmüş performans iddiası değildir.

1. RPO ile RTO arasındaki fark nedir?

RPO / Kurtarma Noktası Hedefi, veri kaybını zamanla ifade eder. Bir ERP veritabanında RPO bir saat olarak seçildiyse, olay anında mümkünse en fazla bir saat önceki tutarlı veriye dönmek hedeflenir. Yedek işinin saatlik planlanması bu hedefi kanıtlamaz; yedeğin tamamlanmış, sağlam ve okunabilir olması gerekir.

RTO / Kurtarma Süresi Hedefi, kesintiden sonra iş hizmetinin yeniden erişilebilir olması için belirlenen hedeftir. Sunucunun açılması ile çalışanların muhasebe programında işlemlere devam etmesi aynı şey değildir. RTO kapsamına uygulama, veri, kimlik doğrulama, ağ ve test adımlarından hangilerinin girdiği net yazılmalıdır.

Kavramların dayanağı olarak NIST RPO tanımı, NIST RTO tanımı ve Microsoft felaket kurtarma rehberi kullanılabilir. Hedefler teknik kapasite kadar işletmenin gerçekten tolere edebileceği etkiye dayanmalıdır.

2. RPO ve RTO belirlemek için iş etki analizi nasıl yapılır?

İlk adım iş etki analizidir (BIA). Muhasebe, satış, üretim, insan kaynakları ve operasyon sorumlularına kritik uygulamalar durduğunda hangi işlemlerin aksadığı sorulur. Bir saatlik kesinti ile bir günlük kesintinin müşteri, gelir, üretim ve mevzuat açısından etkisi aynı değildir. Sonradan elle girilebilecek veri miktarı da iş birimi tarafından değerlendirilmelidir.

Her sistem için verinin sahibi, uygulama sorumlusu, kabul edilebilir veri kaybı, kabul edilebilir hizmet kesintisi ve bağımlı uygulamalar listelenir. Örneğin depo stok kayıtları ile sipariş işlemleri birbirine bağlıysa farklı kurtarma noktaları kullanmak kayıt tutarsızlığına neden olabilir. Böyle durumlarda tek tek sistemlerden önce iş akışının bütünlüğü incelenmelidir.

BT ekibi hedefleri teknik tasarıma dönüştürür ve sağlayıcıyla gerçekçi seçenekleri görüşür. Nihai hedefi yalnız sunucu yöneticisinin belirlemesi doğru değildir: veri kaybının işletmeye etkisini en iyi ilgili iş birimi bilir. Çok kısa hedeflerin ilave kaynak, replikasyon, ayrı lokasyon ve yönetim maliyetleri oluşturacağı açıkça paylaşılmalıdır.

3. Örnek RPO ve RTO tablosu nasıl oluşturulur?

Aşağıdaki tablo gerçek müşteri performansı veya hazır bir Netsun paketi değildir. Değerler, ihtiyaç keşfinde kullanılabilecek tamamen temsili hedeflerdir ve şirketinizin iş etki analiziyle yeniden belirlenmelidir.

Birinci satırdaki hedef veri kaybını azaltmayı önceliklendirirken, dördüncü satırda daha ekonomik bir saklama ve kurtarma yaklaşımı uygulanabilir. Bu sadece düşünme biçimini göstermek içindir. Gerçek tasarımda farklı sistemlerdeki işlemlerin birbirleriyle tutarlı kalması, tek bir rakamdan daha önemli olabilir.

ERP ve muhasebe uygulamaları için sunucu çözümlerinde SQL veritabanı, uygulama servisi, lisans bileşeni, uzak erişim ve raporlama bağımlılıklarını birlikte değerlendirin. Bunlardan biri çalışmıyorsa sunucu açılmış olsa bile ekip işine dönmemiş olabilir.

4. RPO hedefi yedekleme sıklığına nasıl dönüştürülür?

“RPO bir saat, öyleyse her saat bir yedek almak yeterli” düşüncesi eksiktir. Zamanlanmış işin gerçekten başarılı bitmesi, son kurtarma noktasının uygulama açısından tutarlı olması ve hedef depoya ulaştığının doğrulanması gerekir. Başarısız iki yedek işi, kağıt üzerindeki planla fiilî kayıp sınırı arasında büyük fark oluşturabilir.

SQL Server gibi işlem odaklı veritabanlarında uygun recovery modeline, log yedekleme zincirine ve uygulamanın tutarlılık gereksinimlerine bağlı olarak daha sık kurtarma noktaları tasarlanabilir. Ancak her veritabanı için aynı mekanizmanın uygun olduğu varsayılmamalıdır. Üreticinin desteklediği uygulama uyumlu yedekleme yöntemleri kontrol edilmelidir.

Geri yükleme için yalnız son dosyanın bulunması değil, tam yedek, artımlı yedek ve gerekiyorsa log zincirinin eksiksiz olması önemlidir. Alarm veren izleme sistemi; başarısız işleri, gecikmiş kopyaları, depo doluluğunu ve doğrulanamayan noktaları gösterebilmelidir. RPO ölçümü günün sonunda gerçek kurtarılabilir noktadan yapılır.

Sürekli replikasyon daha düşük veri kaybı hedeflerine yardımcı olabilir fakat bozulma, yanlışlıkla silme ve saldırganın şifrelediği veriler de ikinci sisteme aktarılabilir. Replikasyon, geriye dönük ve uygun şekilde korunan bağımsız yedeklerin yerini tek başına almaz.

5. RTO neden yalnız dosyaları geri yükleme süresi değildir?

RTO'nun pratik başlangıcı olayın tanımlanmasıyla ilgilidir; kurumun kabul ettiği ölçüm başlangıcı ve hizmetin geri döndüğü an açıkça kararlaştırılmalıdır. Toplam sürenin içinde tespit, bilgilendirme, karar, temiz altyapı hazırlığı, veri geri yükleme, servis açılışı ve kullanıcı kabul testi bulunabilir.

Bir kurtarma planını şu zincire ayırın: olayın tespiti → güvenli müdahale kararı → alternatif kaynağın hazırlanması → sağlam verinin yüklenmesi → ağ ve kimlik bağlantılarının çalışması → uygulama testi → iş biriminin onayı. Her adım için sorumlu kişi ve ölçülen süre kaydedilmelidir.

Birden fazla terabayt veriyi sınırlı internet bağlantısından geri taşımak gerekiyorsa güçlü CPU ve RAM tek başına hızlı toparlanma sağlamaz. Önceden hazırlanmış kapasite, yeterli okuma hızı, ağ bağlantısı ve lisans erişimi gerekir. Felaket anında kullanılacak lokasyonun ve operasyon ekibinin hazır olup olmadığı da sonucu etkiler.

Yönetilen sunucu hizmeti alınırken destek kapsamı, mesai dışı müdahale, kurtarmayı başlatma yetkisi ve test onayı sözleşmede ayrı ayrı belirtilmelidir. “Sunucu çalışıyor” ile “müşteri sipariş verebiliyor” farklı hizmet durumlarıdır.

6. Snapshot, yedekleme ve replikasyon birbirinin yerine geçer mi?

Hayır. Snapshot, belirli bir andaki sistem durumunu yakalamaya yarar. Aynı depolama sisteminde tutulan snapshot, tüm depolamanın kaybı karşısında bağımsız yedek sayılmamalıdır. Uygulama tutarlılığı da kullanılan teknolojinin özelliklerine ve kurulumuna göre değişebilir.

Yedekleme, tanımlanan saklama süresi boyunca birden fazla kurtarma noktası tutmayı amaçlar. Üretimden farklı güvenlik ve depolama sınırında saklanan kopyalar birçok riski azaltabilir. Replikasyon ise bir sistemin verisini başka bir ortama aktararak hizmetin oradan sürdürülmesini kolaylaştırabilir.

Bu ayrım VPS ve bulut sunucu ile dedicated sunucu kiralama tekliflerinde özellikle önemlidir. Bir sanal makine paketinde snapshot bulunması, test edilmiş felaket kurtarma veya ayrı lokasyonda saklanan yedek vaat edildiği anlamına gelmez. Hangi özelliklerin fiyata dahil olduğu ayrı yazılmalıdır.

Önerilen yaklaşım, risklere göre birden fazla kopya, farklı saklama ortamı, gerekli durumlarda bağımsız veya çevrimdışı kopya ve düzenli kurtarma testlerini birlikte değerlendirmektir. “Üç kopya var” demek tek başına kurtarılabilirlik sonucu değildir.

7. SQL Server, Active Directory ve File Server kurtarması nasıl farklılaşır?

SQL Server için son tutarlı işlem noktasına dönmek, uygulama bağlantılarını doğrulamak ve veritabanı kimlikleri ile izinleri kontrol etmek gerekir. Muhasebe veya ERP yazılımının satıcı tarafından desteklenen kurtarma yöntemi önemlidir. Veritabanı servisinin başlaması iş akışının eksiksiz ayağa kalktığı anlamına gelmez.

Active Directory için DNS, replikasyon, etki alanı denetleyicilerinin sistem durumu ve yetkili geri yükleme senaryoları özel dikkat ister. Denetleyicinin sanal makine snapshot'unu rastgele geri döndürmek, üreticinin desteklediği etki alanı kurtarma süreciyle eşdeğer değildir. Kimlik sistemi çalışmadığında başka sunucular açık olsa bile kullanıcıların giriş yapması mümkün olmayabilir.

File Server tarafında NTFS erişim izinleri, SMB paylaşım ayarları, grup üyelikleri ve dosyaların sürüm geçmişi birlikte doğrulanmalıdır. Sadece klasörleri kopyalamak beklenen yetkilendirmeyi geri getirmeyebilir. Şube bağlantıları veya kullanıcıların VPN üzerinden erişimi de RTO hesaplamasına girebilir.

İş yüklerini tek plana toplarken bağımlılık sırasını belirtin. Önce kimlik ve temel ağ servisleri, sonra veritabanı ve uygulama katmanı, en sonunda kullanıcı kabulü gibi bir sıralama başlangıç olabilir; kesin sıralama her kurumun gerçek mimarisiyle belirlenmelidir.

8. Fidye yazılımı karşısında yedekler nasıl güvenli kalır?

Saldırgan üretim yönetici hesabına erişirse aynı kimlikle erişilen yedek deposunu da silebilir veya bozabilir. Bu nedenle yedek yönetici hesaplarını ayırmak, MFA kullanmak, en az yetki vermek ve ağ erişimini sınırlamak önemlidir. Ayrı bir saklama lokasyonu veya bağımsız yönetim alanı, tüm kopyaların aynı olaydan etkilenme ihtimalini azaltabilir.

Değiştirilemez (immutable) veya çevrimdışı kopyalar bazı tehditlere karşı ek savunma sağlar. Yine de retention süresi, anahtar güvenliği, yanlış yapılandırma ve temiz veri noktasının bulunması ayrıca planlanmalıdır. Bağımsız yedek deposu bile test edilmemişse beklendiği gibi kurtarmaya hizmet etmeyebilir.

Ağ ve güvenlik çözümlerini yedekleme mimarisiyle birlikte değerlendirin. Firewall, ayrılmış yönetim ağı, erişim kayıtları ve olay müdahale prosedürü belirleyin. Uygulanacak KVKK ve diğer yükümlülükler için hukuki ve kurumsal değerlendirmeyi ayrıca yaptırın; teknik önlemler otomatik uyumluluk garantisi değildir.

9. RPO ve RTO'nun gerçekleştiği nasıl test edilir?

Yedekleme yazılımının “başarılı” uyarısı, geri yüklemenin başarılı olacağına tek başına kanıt değildir. Tatbikattan önce izole test ortamı, test edilecek veri, senaryo, sorumlu kişiler ve başarı ölçütleri belirlenmelidir. Üretim iş yüküne veya gerçek müşteri verisine gereksiz risk yaratmayan bir test yöntemi seçilmelidir.

Testte son sağlam kurtarma noktası bulunur; gerektiğinde sanal makine, veritabanı, dosyalar ve uygulama bağımlılıkları geri getirilir. Ardından DNS ve kimlik servisleri, uygulama erişimi, raporlar, yetkiler ve kritik kullanıcı işlemleri denenir. Son onayı yalnız altyapı ekibi değil, iş birimi vermelidir.

Rapor iki ölçüm içermelidir: olaya göre geri alınabilen veri noktasının yaşı ve işlevsel sistemin tekrar kullanıma açılma süresi. Bunları hedeflerle yan yana koyun. Başarısız testler gizlenmemeli; eksik bağımlılık, darboğaz, gecikmiş yedek veya hatalı prosedür için iyileştirme işi açılmalıdır.

Sistem taşındığında, veri miktarı büyüdüğünde, yedekleme çözümü değiştiğinde veya ciddi güvenlik olayı yaşandığında yeniden test gerekebilir. Periyodik tatbikat, RPO/RTO hedeflerinin kağıtta kalan sayılar olmasını önlemeye yardımcı olur.

10. Kurumsal yedekleme teklifinde hangi sorular sorulmalı?

İyi bir sözleşme “günlük yedek dahildir” cümlesinden daha fazlasını açıklamalıdır. Farklı sağlayıcılara aynı iş yükü ve iş sürekliliği ihtiyaçlarını vererek karşılaştırılabilir kapsam istemek gerekir.

1. Her uygulamanın RPO ve RTO hedefi nedir; ölçümün başlangıç ve bitişi nasıl tanımlanır?
2. Tam, artımlı veya log yedekleme sıklığı, uygulama tutarlılığı ve saklama süresi nedir?
3. Yedekler hangi ayrı sistemde, hangi lokasyonda, hangi güvenlik sınırında tutulur?
4. Alternatif çalışma ortamı, disk, ağ, IP ve gerekli lisanslar kurtarma anında hazır mıdır?
5. Hatalı yedeklerin alarmları, destek ve olay müdahale sorumluları kimlerdir?
6. Geri yükleme tatbikatı nasıl yapılır, kim onaylar ve hangi kanıt paylaşılır?
7. Sözleşme bitiminde veri teslimi, silme, veri çıkışı ve ek operasyon bedelleri nelerdir?

Toplam maliyette yalnız depolanan terabaytı değil; okuma performansını, ayrı lokasyonu, ağ trafiğini, yönetimi, destek saatlerini ve tatbikat maliyetlerini de düşünün. Daha düşük RPO ve RTO, daha hazır bir kurtarma mimarisi gerektirebilir. Farklı fiyatları ancak kapsamdaki farklılıkları yazılı görerek kıyaslayın.

Sunucu sayınızı, kritik veri türlerinizi, son yedek raporunuzu ve kabul edilebilir veri kaybı ile kesinti sürelerinizi paylaşarak kurumsal yedekleme ve kurtarma teklifi alın. Böylece teklif, yalnız CPU ve disk kapasitesine değil gerçekten ihtiyaç duyulan kurtarma seviyesine dayanır.

Sık sorulan sorular

1. RPO sıfır dakika olabilir mi?

Bazı mimariler çok düşük veya sıfıra yakın veri kaybı hedefleyebilir; fakat bu, veri yazma, replikasyon, tutarlılık ve hata türlerine bağlıdır. Sıfır RPO ifadesi kapsam, istisnalar ve test kanıtı olmadan garanti sayılmamalıdır.

2. RTO bir saat seçilirse her koşulda bir saatte açılır mı?

Hayır. RTO hedefi ve sözleşmede taahhüt edilen kapsam ayrı kavramlardır. Başlangıç anı, olay türleri, uygulama bağımlılıkları, destek koşulları ve test senaryoları yazılı belirlenmelidir.

3. Her gece alınan yedek otomatik olarak 24 saat RPO sağlar mı?

Her zaman değil. İşin tamamlanması, verinin tutarlı olması ve gerektiğinde kurtarılabilmesi gerekir. Gecikmiş veya başarısız yedekler fiilî veri kaybını artırabilir.

4. Replikasyon kullanıyorsak ayrıca yedek tutmalı mıyız?

Genellikle farklı tarihli ve bağımsız kurtarma noktaları da gereklidir. Yanlışlıkla silinen veya bozulan veri replikayla yayılabilir. Risk analizine göre korumalı yedek ve gerekirse çevrimdışı kopya planlanmalıdır.

5. SQL Server için gerçek RPO nasıl ölçülür?

Olay zamanı ile geri getirilen veritabanında kullanılabilen son tutarlı işlem noktası arasındaki fark hesaplanır. Kullanılan recovery model, log zinciri ve uygulama doğrulaması sonucu etkiler.

6. Sunucu açıldıysa RTO hedefi karşılanmış mıdır?

İşletmenin hedefi kullanıcıların ERP veya dosyalara erişmesi ise yalnız VM'nin açılması yeterli değildir. Ağ, kimlik doğrulama, veritabanı, lisans ve kullanıcı kabul testi de kapsama girebilir.

7. RPO ve RTO ne zaman yeniden değerlendirilir?

İş süreçleri, veri hacmi, uygulama mimarisi veya riskler değiştiğinde ve kurtarma tatbikatlarından sonra tekrar değerlendirilmelidir. Uzun süre değişmeyen hedefler bile düzenli testlerle doğrulanmalıdır.

Teknik kaynaklar ve karar özeti

RPO için NIST, RTO için NIST ve Microsoft'un iş sürekliliği rehberi temel kavramların doğrulanabileceği teknik kaynaklardır. Uygulama seçimi yapılırken ilgili üretici ve sözleşme belgeleri de ayrıca incelenmelidir.

Sonuç: Önce kabul edilebilir veri kaybını ve kesintiyi iş birimiyle belirleyin; sonra yedekleme yöntemini, kaynak kapasitesini ve kurtarma prosedürünü seçin. RPO ile RTO'yu gerçek geri yükleme testinde ayrı ayrı ölçmeden garanti varsaymayın. Bu ihtiyaç listesini teklif formuna eklemek, daha şeffaf ve uygulanabilir bir kurumsal sunucu yedekleme planına ulaşmayı kolaylaştırır.