Yedekten Geri Dönüş Testi Nasıl Yapılır? RPO ve RTO Hedeflerini Ölçme Rehberi

Yedek geri yükleme testi, yedekleme sistemleri tarafından oluşturulan veri kopyalarının izole bir test ortamına aktarılarak dosya bütünlüğünün, uygulama tutarlılığının ve belirlenen kurtarma hedeflerinin (RPO ve RTO) fiilen doğrulandığı planlı teknik denetim sürecidir. Kurumsal bilişim altyapılarında yedekleme görevlerinin arayüzde "başarılı" görünmesi, olası bir sistem arızası veya siber saldırı anında verilerin eksiksiz ve zamanında kurtarılabileceğini tek başına kanıtlamaz. Gerçek veri güvenliği, yalnızca düzenli yedek almakla değil, bu yedeklerden belirlenen süre içinde çalışır bir sisteme dönülebildiğinin ölçülmesiyle sağlanır.

Yedek Geri Yükleme Testi Nedir ve Neden Önemlidir?

Yedek geri yükleme testi (backup restore testi), saklanan yedekleme imajlarının, veritabanlarının veya dosyaların üretim ortamını etkilemeyecek yalıtılmış bir altyapıda açılarak hem teknik olarak bozulmadığının hem de iş süreçlerini sürdürebilecek düzeyde çalışır durumda olduğunun kanıtlanması işlemidir.

Kurumsal bilgi teknolojileri (BT) yönetiminde en sık karşılaşılan yanılgı, yedekleme yazılımının ürettiği "Success" (Başarılı) bildirimlerini mutlak veri güvenliği olarak kabul etmektir. Oysa yedekleme işlemi yalnızca verinin kaynak diskten okunup hedef depolama alanına yazıldığını gösterir. Bu sürecin sonunda ortaya çıkan yedek dosyasının okunabilirliği, şifreleme anahtarlarının erişilebilirliği, veritabanı işlem günlüklerinin (transaction log) tutarlılığı ve işletim sisteminin önyükleme (boot) yeteneği ancak fiili bir geri yükleme denemesiyle anlaşılabilir.

NIST (National Institute of Standards and Technology) tarafından yayınlanan SP 800-34 (Contingency Planning Guide for Federal Information Systems) standardı, kurtarma planlarının ve yedekleme medyasının düzenli olarak test edilmemesini, felaket anındaki başarısızlıkların temel nedenlerinden biri olarak tanımlar. Yedek geri yükleme testinin kurumsal açıdan kritik önemi şu dört temel noktada toplanır:

• Gizli Veri Bozulmalarını (Silent Data Corruption) Tespit Etme: Depolama birimlerinde zamanla oluşabilen bit düzeyindeki bozulmalar (bit rot) veya ağ aktarımı sırasındaki paket kayıpları, yedekleme anında hata üretmeyebilir; ancak geri yükleme sırasında arşivin açılmasını tamamen engelleyebilir.
• Kurtarma Süresini Gerçekçi Ölçme: Kağıt üzerinde 2 saat olarak hedeflenen bir sistem kurtarma süreci, disk okuma/yazma (IOPS) darboğazları veya karmaşık bağımlılıklar nedeniyle gerçekte 14 saat sürebilir. Testler bu farkı kriz anından önce ortaya çıkarır.
• Personel ve Prosedür Hazırlığı: Gerçek bir kesinti anında stres altında yapılacak işlemlerin adım adım dokümante edilmesi ve operasyon ekibinin bu adımlara aşina olması insan kaynaklı hataları azaltır.
• Yasal Uyumluluk ve Denetim Gereklilikleri: KVKK, ISO 27001, BDDK veya sektör spesifik bilgi güvenliği denetimlerinde, yalnızca yedekleme politikasının varlığı değil, bu yedeklerin test edildiğine dair imzalı kayıtlar talep edilir.

Yedekleme Yapmak Verileri Korumak için Yeterli midir?

Hayır, yalnızca yedekleme yapmak verileri korumak ve iş sürekliliğini sağlamak için yeterli değildir. Backup (yedekleme) verinin kopyalanması işlemiyken, Restore (geri yükleme) bu kopyanın işler bir sisteme dönüştürülmesi sürecidir; yedekleme görevinin tamamlanması, geri yüklemenin başarılı olacağını garanti etmez.

Bir yedekleme görevi (backup job) izleme ekranında yeşil onay işaretiyle tamamlanmış görünse bile, gerçek bir kurtarma senaryosunda sistemin ayağa kalkmasını engelleyen pek çok teknik arıza meydana gelebilir. Kurumsal altyapılarda sahada en sık karşılaşılan başarısızlık nedenleri şunlardır:

1. Uygulama Tutarsızlığı (Application Inconsistency): Veritabanı veya kurumsal kaynak planlama (ERP) gibi sürekli yazma işlemi yapan uygulamalarda, bellek (RAM) üzerindeki henüz diske yazılmamış işlemler dondurulmadan (VSS – Volume Shadow Copy Service kullanılmadan) alınan yedekler, geri yüklendiğinde "bozuk veritabanı" (corrupt database) hatası verir.
2. Kırık Artımlı (Incremental) Yedek Zinciri: Artımlı yedekleme yönteminde her yedek dosyası bir öncekine bağımlıdır. Zincirin ortasındaki tek bir artımlı yedek dosyasının zarar görmesi veya silinmesi, o noktadan sonraki tüm yedeklerin kurtarılamaz hale gelmesine yol açar.
3. Kayıp Şifreleme Anahtarları ve Parolalar: Güvenlik amacıyla şifrelenen yedek dosyaları, yedekleme sunucusunun kendisi kaybedildiğinde veya şifreleme anahtarı (encryption key) ayrı bir kasada saklanmadığında hiçbir şekilde açılamaz.
4. Kimlik ve Erişim Yetkisi (ACL/NTFS) Uyumsuzlukları: Dosya sunucusu yedekleri geri yüklendiğinde, Active Directory güvenlik tanımlayıcıları (SID) veya klasör erişim izinleri doğru taşınmazsa kullanıcılar dosyalara erişemez ya da yetkisiz erişimler oluşur.
5. Eksik Altyapı Bağımlılıkları: Bir web uygulaması veya ERP sunucusu eksiksiz geri yüklense dahi, bağlı olduğu DNS kayıtları, SSL sertifikaları, lisans sunucusu (dongle/lisans servisi) veya ara katman (middleware) servisleri kurtarılmadığında hizmet kullanılamaz durumda kalır.

RPO ve RTO Nedir? Aralarındaki Farklar Nelerdir?

RPO (Recovery Point Objective – Kurtarma Noktası Hedefi), bir kesinti veya felaket durumunda işletmenin tolere edebileceği maksimum veri kaybı süresini; RTO (Recovery Time Objective – Kurtarma Zamanı Hedefi) ise kesinti anından itibaren sistemlerin yeniden çalışır hale gelmesi için belirlenen maksimum süreyi ifade eder.

Bu iki metrik birbirinin alternatifi değil, birbirini tamamlayan iki temel iş sürekliliği göstergesidir. Birlikte ele alındıklarında kurumun hem veri kaybı riskini hem de operasyonel duruş maliyetini tanımlarlar.

RPO (Recovery Point Objective) Nedir?

RPO, kesinti meydana geldiği andan geriye doğru gidildiğinde, en son alınan geçerli yedekleme noktasına kadar geçen kabul edilebilir zaman aralığıdır. RPO tamamen veri odaklıdır ve doğrudan yedekleme sıklığını belirler.

Örneğin; kritik bir veritabanı için RPO hedefi 1 saat olarak belirlenmişse, sistemin en az saatte bir yedeklenmesi veya işlem günlüğü (transaction log) kopyalaması yapması gerekir. Saat 14:30'da meydana gelen bir donanım arızasında saat 14:00 yedeğine dönüldüğünde veri kaybı 30 dakikadır ve 1 saatlik RPO hedefi karşılanmış olur.

RTO (Recovery Time Objective) Nedir?

RTO, bir sistemin veya iş sürecinin devre dışı kalmasından itibaren, tekrar son kullanıcıların hizmetine sunulmasına kadar geçebilecek kabul edilebilir maksimum kesinti süresidir. RTO tamamen zaman ve erişilebilirlik odaklıdır ve doğrudan kurtarma teknolojisinin hızını belirler.

RTO hesaplanırken yalnızca yedek dosyasının disk üzerine kopyalanma süresi dikkate alınmaz. Olayın fark edilmesi, kurtarma kararının alınması, donanım veya sanal makinenin hazırlanması, verinin geri yüklenmesi, servislerin başlatılması ve iş biriminin sistemi doğrulaması geçen toplam sürenin birer parçasıdır.

RPO ve RTO Arasındaki Farklar

Karşılaştırma Kriteri	RPO (Kurtarma Noktası Hedefi)	RTO (Kurtarma Zamanı Hedefi)
Temel Odak Noktası	Veri kaybı miktarı (zaman cinsinden)	Sistem kesinti süresi (hizmete dönüş hızı)
Zaman Yönü	Olay anından geriye doğru ölçülür	Olay anından ileriye doğru ölçülür
Yanıtladığı Temel Soru	"En fazla ne kadarlık veriyi kaybetmeyi göze alabiliriz?"	"Sistemin kapalı kalmasına en fazla ne kadar dayanabiliriz?"
Belirlediği Teknik Mimari	Yedekleme sıklığı, replikasyon aralığı, log yedekleme	Depolama IOPS hızı, ağ bant genişliği, sıcak/soğuk yedek sistemler
Hedef Aşılırsa Ne Olur?	İşlem kaybı, manuel veri girişi maliyeti, yasal ihlal	Gelir kaybı, üretim duruşu, SLA cezaları, itibar kaybı

RPO ve RTO Nasıl Hesaplanır?

RPO ve RTO değerleri teknik ekiplerin tek başına belirleyeceği sayılar değil; İş Etki Analizi (BIA – Business Impact Analysis) sonucunda süreç sahipleri ve üst yönetimle birlikte belirlenen iş kararlarıdır.

• RPO Hesaplama Mantığı: İlgili sistemdeki veri üretim hızı ve kaybolan verinin yeniden oluşturulma maliyeti analiz edilir. Dakikada yüzlerce sipariş alan bir e-ticaret veritabanında 4 saatlik veri kaybı telafi edilemezken, günde birkaç kez güncellenen bir kurumsal doküman arşivinde 24 saatlik RPO kabul edilebilir olabilir.
• RTO Hesaplama Mantığı: Kurumun MTPD (Maximum Tolerable Period of Disruption – Azami Tolere Edilebilir Kesinti Süresi) değeri bulunur. MTPD, bir sistem kapalı kaldığında işletmenin finansal veya yasal olarak geri dönülmez zarar gördüğü eşiktir. RTO her zaman MTPD değerinden daha düşük belirlenmelidir (RTO küçüktür MTPD). Örneğin, üretim hattını durduran bir ERP sistemi için MTPD 6 saat ise, güvenli bir operasyon payı bırakılarak RTO hedefi 4 saat olarak tanımlanır.

Farklı Sistemler İçin Örnek RPO ve RTO Hedefleri

Aşağıdaki değerler sektörel bir zorunluluk veya evrensel standart değildir; kurumsal planlamada referans alınabilecek örnek katmanlandırma modelleridir.

Sistem Kategorisi	Örnek İş Yükleri	Örnek RPO Hedefi	Örnek RTO Hedefi	Önerilen Mimari Yaklaşım
Kritik (Tier-1)	Çekirdek Bankacılık, E-Ticaret DB, Üretim ERP	0 – 15 Dakika	15 Dakika – 2 Saat	Senkron/Asenkron Replikasyon, Sıcak Yedek (Warm/Hot Standby)
Önemli (Tier-2)	Kurumsal E-Posta, CRM, İç Uygulama Sunucuları	1 – 4 Saat	2 – 8 Saat	Sık Artımlı Yedekleme, Anlık VM Kurtarma (Instant VM Recovery)
Standart (Tier-3)	Ortak Dosya Sunucuları, Departman Paylaşımları	12 – 24 Saat	8 – 24 Saat	Günlük Artımlı / Haftalık Tam Yedekleme
Düşük Öncelik (Tier-4)	Test/Geliştirme Ortamları, Uzun Süreli Arşivler	24 – 72 Saat	24 – 72 Saat	Standart Yedekleme ve Bulut/Teyp Arşivleme

Yedek Geri Yükleme Testi Nasıl Yapılır?

Yedek geri yükleme testi, üretim sistemlerini riske atmadan yalıtılmış bir ağda hazırlık, bütünlük doğrulaması, geri yükleme, fonksiyonel kontrol ve metrik ölçümü adımlarının sırayla uygulanmasıyla gerçekleştirilir.

Sağlıklı ve denetlenebilir bir geri yükleme testi yürütmek için aşağıdaki 8 aşamalı teknik prosedür uygulanmalıdır:

1. Kritik Sistemleri ve Verileri Belirleyin

Tüm altyapıyı aynı anda test etmeye çalışmak operasyonel karmaşaya yol açar. Öncelikle İş Etki Analizi (BIA) doğrultusunda en kritik sistemlerden (örneğin ERP veritabanı, Active Directory, dosya sunucusu veya finans uygulamaları) başlanmalıdır. Her sistemin sahibi (süreç sorumlusu) ve teknik sorumlusu test planına dahil edilmelidir.

2. RPO ve RTO Hedeflerini Tanımlayın

Test başlamadan önce başarı kriterleri netleştirilmelidir. Hangi tarih ve saatteki yedek noktasına dönüleceği (RPO doğrulaması) ve testin başlatılmasından uygulamanın çalışır hale gelmesine kadar geçen toplam sürenin (RTO doğrulaması) hangi eşik değerin altında kalması gerektiği yazılı olarak kayıt altına alınmalıdır.

3. Güvenli Test Ortamını Hazırlayın

Geri yükleme testi kesinlikle aktif çalışan üretim (production) ortamının üzerine yazma şeklinde yapılmamalıdır. Test için üretim ağından VLAN, güvenlik duvarı (firewall) kuralları veya ayrı bir sanal anahtar (isolated vSwitch) ile tamamen izole edilmiş bir Sandbox (kum havuzu) ortamı oluşturulmalıdır. İzolasyon sağlanmazsa, geri yüklenen sanal makineler üretim ortamındaki sunucularla IP adresi, makine adı (SID) veya Active Directory replikasyonu çakışmasına girerek canlı sistemleri kesintiye uğratabilir.

4. Yedek Dosyalarının Bütünlüğünü Kontrol Edin

Geri yükleme işlemine geçmeden önce kaynak yedek dosyalarının fiziksel ve mantıksal bütünlüğü doğrulanmalıdır. Yedekleme yazılımının sağladığı checksum (SHA-256 / MD5 hash) doğrulama araçları çalıştırılmalı, yedek zincirindeki (full + incremental/differential) tüm dosyaların eksiksiz olduğu ve depolama alanında okuma hatası bulunmadığı teyit edilmelidir.

5. Yedekleri Test Ortamına Geri Yükleyin

Kronometre başlatılarak yedekleme yazılımı üzerinden izole test ortamına geri yükleme (restore) işlemi başlatılır. Bu aşamada tam sistem kurtarma (Bare Metal / Full VM Restore), veritabanı geri yükleme veya dosya düzeyi kurtarma (File-Level Restore) senaryolarından hangisi planlandıysa o prosedür işletilir. Şifreleme parolalarının girilmesi ve hedef depolama alanına veri yazım hızı adım adım gözlemlenir.

6. Verilerin ve Uygulamaların Çalışmasını Doğrulayın

Sanal makinenin açılması veya dosyaların klasörde görünmesi testin başarılı olduğu anlamına gelmez. Sistem yöneticisi ve ilgili iş birimi uzmanı şu kontrolleri gerçekleştirmelidir:

• İşletim sistemi olay günlüklerinde (Event Viewer / Syslog) kritik hata olup olmadığı kontrol edilir.
• Veritabanı servislerinin (örneğin MSSQLSERVER) sorunsuz başladığı ve tutarlılık testlerinden geçtiği doğrulanır.
• Uygulama arayüzüne giriş yapılarak son yedekleme tarihine ait gerçek iş kayıtlarının (faturalar, stok hareketleri, dokümanlar) okunabildiği ve yeni kayıt eklenebildiği test edilir.

7. Gerçekleşen RPO ve RTO Değerlerini Ölçün

Test tamamlandığında başlangıçtan uygulama onayına kadar geçen toplam süre hesaplanarak hedeflenen RTO ile karşılaştırılır. Aynı şekilde geri yüklenen sistemdeki en güncel verinin zaman damgası incelenerek hedeflenen RPO değerinin tutturulup tutturulmadığı kayıt altına alınır.

8. Test Sonuçlarını Raporlayın

Elde edilen bulgular, karşılaşılan darboğazlar, eksik dokümantasyonlar ve iyileştirme aksiyonları standart bir test raporuna dönüştürülür. Raporda tespit edilen aksaklıklar için sorumlu kişiler ve tamamlama tarihleri belirlenerek bir sonraki test döngüsüne kadar giderilmesi sağlanır.

Yedek Geri Yükleme Testinin Aşamaları Özeti

Aşama	Yapılacak Temel İşlem	Sorumlu Rol	Çıktı / Doğrulama Kanıtı
1. Kapsam Belirleme	Kritik sistemlerin ve bağımlılıkların seçimi	BT Yöneticisi & Süreç Sahibi	Test Kapsam Dokümanı
2. Hedef Tanımlama	Sistem bazlı RPO ve RTO eşiklerinin netleştirilmesi	İş Sürekliliği / BT Ekibi	Hedef Metrik Tablosu
3. Ortam İzolasyonu	Üretim ağından yalıtılmış Sandbox VLAN kurulumu	Ağ ve Sistem Mühendisi	İzole Ağ Topolojisi
4. Bütünlük Kontrolü	Checksum, hash ve yedek zinciri doğrulaması	Yedekleme Uzmanı	Bütünlük Doğrulama Logu
5. Geri Yükleme	Verinin veya sanal makinenin test ortamına aktarımı	Yedekleme Uzmanı	Zaman Damgalı Restore Kaydı
6. Fonksiyonel Test	Servis, veritabanı ve uygulama işlevlerinin kontrolü	Uygulama Uzmanı & Son Kullanıcı	Kullanıcı Kabul Onayı (UAT)
7. Metrik Ölçümü	Gerçekleşen RPO ve RTO sapmalarının analizi	BT Yöneticisi	Performans Karşılaştırma Tablosu
8. Raporlama	Bulguların dokümantasyonu ve aksiyon planı	Tüm Test Ekibi	İmzalı Test Sonuç Raporu

Hangi Yedekleme Türlerinde Geri Yükleme Testi Yapılmalıdır?

Kurumsal bir BT altyapısında tek tip veri bulunmadığı için geri yükleme testleri yalnızca dosya kopyalama düzeyinde bırakılmamalı; dosya sistemleri, ilişkisel veritabanları, fiziksel sunucular, sanallaştırma platformları, ağ depolama üniteleri (NAS/RAID) ve bulut hizmetleri ayrı ayrı test edilmelidir.

Dosya ve Klasör Yedekleme Testi

Ortak ağ paylaşımlarında (File Server) tutulan ofis belgeleri, PDF arşivleri ve departman klasörleri için yapılır. Bu testte yalnızca dosyanın geri gelmesi değil; Türkçe karakter kodlamalarının bozulmadığı, uzun dosya yolu (260 karakter sınırı) hatalarının yaşanmadığı ve NTFS erişim izinlerinin (ACL) korunduğu doğrulanmalıdır.

SQL Server Veritabanı Geri Yükleme Testi

Kurumsal veritabanları dinamik yapıları nedeniyle en hassas kurtarma bileşenleridir. Microsoft SQL Server resmi dokümantasyonunda belirtildiği üzere, bir yedek dosyasının (.bak veya .trn) başlık ve sayfa bütünlüğünü kontrol etmek için öncelikle RESTORE VERIFYONLY komutu kullanılabilir; ancak bu komut veritabanının iç mantıksal tutarlılığını tam olarak garanti etmez.

Gerçek bir SQL Server geri yükleme testinde yedek dosyası izole bir SQL örneğine (instance) WITH NORECOVERY ve ardından işlem günlükleri uygulanarak WITH RECOVERY seçenekleriyle açılmalı; sonrasında veritabanı içindeki indeks ve sayfa bozulmalarını denetlemek için mutlaka **DBCC CHECKDB** komutu çalıştırılmalıdır. Veritabanı yedekleme mimarinizi güçlendirmek için SQL Server yedekleme stratejileri  rehberimizdeki tam, fark ve işlem günlüğü yedekleme modellerini inceleyebilirsiniz.

Fiziksel Sunucu Geri Yükleme Testi

Sanallaştırılmamış fiziksel sunucularda (Bare Metal) işletim sistemi, sürücüler ve uygulamalar donanıma bağımlıdır. Fiziksel sunucu geri yükleme testinde BMR (Bare Metal Recovery) medyası kullanılarak sunucunun farklı bir donanım profiline veya sanal bir makineye (P2V – Physical to Virtual) dönüştürülerek önyükleme yapıp yapmadığı test edilmelidir. Farklı donanım bileşenlerinde depolama denetleyicisi (RAID/HBA) sürücülerinin enjekte edilebilmesi kritik öneme sahiptir.

VMware ve Hyper-V Sanal Makine Kurtarma Testi

VMware vSphere ve Microsoft Hyper-V ortamlarında alınan imaj tabanlı (image-level) yedekler iki farklı yöntemle test edilebilir:

1. Anlık Kurtarma (Instant VM Recovery): Yedek dosyasının doğrudan yedekleme depolama alanı üzerinden NFS veya vPower benzeri bir katmanla sanal makine olarak çalıştırılmasıdır. RTO süresini dakikalara indirir ancak depolama IOPS performansı mutlaka ölçülmelidir.
2. Tam Geri Yükleme (Full VM Restore): Sanal makine disklerinin (.vmdk veya .vhdx) üretim depolama alanına tamamen kopyalanarak çalıştırılmasıdır. Bu testte sanal ağ adaptörlerinin izole port gruplarına bağlandığı, VMware Tools / Hyper-V Integration Services bileşenlerinin çalıştığı ve sanal makinenin mavi ekran (BSOD) vermeden açıldığı doğrulanır.

RAID ve NAS Sistemlerinde Yedek Kurtarma Testi

Birçok işletmede RAID yapılandırması (RAID 1, RAID 5, RAID 6, RAID 10) yanlışlıkla bir yedekleme yöntemi olarak değerlendirilir. RAID bir yedekleme değildir; yalnızca disk arızalarına karşı donanımsal erişilebilirlik (high availability) sağlar. Yanlışlıkla silinen bir dosyayı veya fidye yazılımının şifrelediği veriyi RAID kurtaramaz. NAS (Network Attached Storage) cihazları üzerindeki anlık görüntülerin (snapshot) ve harici yedeklerin geri yükleme testi yapılırken, NAS işletim sistemi çöktüğünde dahi yedek disklerinin başka bir sistem üzerinden okunabilir (taşınabilir dosya sistemi formatı) olup olmadığı kontrol edilmelidir.

Bulut ve Microsoft 365 Yedekleme Testi

Microsoft 365 (Exchange Online, SharePoint, OneDrive, Teams) ve bulut tabanlı SaaS platformları Paylaşılan Sorumluluk Modeli (Shared Responsibility Model) ile çalışır. Microsoft altyapı sürekliliğini sağlarken, verinin kullanıcı hatası veya kötü niyetli yazılımlarla silinmesine karşı korunması kurumun sorumluluğundadır. Bulut yedekleme testlerinde; silinen bir kullanıcının posta kutusunun (mailbox), SharePoint belge kitaplığının veya Teams kanal yazışmalarının meta verileri ve sürüm geçmişleriyle birlikte geri döndürülebildiği test edilmelidir.

Yedekleme Türlerine Göre Geri Yükleme Testi Matrisi

Yedekleme Türü	Kullanılan Test Yöntemi	Kritik Doğrulama Noktası	Olası Teknik Risk
Dosya / Klasör	Seçili dizinlerin izole alana aktarımı	NTFS/ACL izinleri, dosya bütünlüğü	Uzun yol hataları, yetki kaybı
SQL Server / DB	İzole Instance'a Restore + DBCC CHECKDB	İşlem günlüğü zinciri, sayfa tutarlılığı	Kırık log zinciri, eksik TDE sertifikası
Fiziksel Sunucu	Bare Metal Recovery (BMR) / P2V	Donanım sürücü uyumu, önyükleme	Depolama denetleyicisi sürücü eksikliği
VMware / Hyper-V	Sandbox VLAN'da Instant / Full VM Restore	Ağ izolasyonu, servislerin otomatik açılışı	IP/SID çakışması, yavaş depolama IOPS'u
NAS / RAID	Harici/Alternatif ortamda veri okuma	Snapshot ve harici kopya erişilebilirliği	Tescilli dosya sistemi bağımlılığı
Microsoft 365 / Bulut	Bulut-bulut veya yerel PST/veri kurtarma	E-posta, SharePoint ve OneDrive hiyerarşisi	API hız sınırları (throttling) nedeniyle yavaşlık

RPO ve RTO Hedefleri Nasıl Ölçülür?

RPO ve RTO hedeflerinin ölçümü, yalnızca veri aktarım hızının hesaplanmasıyla değil; olayın fark edilmesinden son kullanıcının sistemi onaylamasına kadar geçen tüm operasyonel adımların zaman damgalarıyla kayıt altına alınmasıyla gerçekleştirilir.

Gerçek bir kesinti veya tatbikat senaryosunda toplam kurtarma süresi (Gerçekleşen RTO) şu beş alt bileşenin toplamından oluşur:

Gerçekleşen RTO = Tespit Süresi + Hazırlık Süresi + Aktarım Süresi + Doğrulama Süresi + Onay Süresi

• Tespit Süresi (T_tespit): Arızanın izleme sistemleri tarafından fark edilmesi, kök nedenin anlaşılması ve geri yükleme kararının onaylanması için geçen süredir.
• Hazırlık Süresi (T_hazırlık): Hedef sunucunun, depolama alanının ve ağ bağlantılarının kurtarma işlemine hazır hale getirilmesi süresidir.
• Aktarım Süresi (T_aktarım): Yedek verisinin depolama biriminden hedef sisteme kopyalanması ve sanal makine/veritabanı açılış süresidir.
• Doğrulama Süresi (T_doğrulama): BT ekibinin servisleri, veritabanı tutarlılığını ve ağ erişimini kontrol ettiği süredir.
• Onay Süresi (T_onay): İlgili departman kullanıcısının uygulamaya girerek verilerin doğruluğunu onayladığı süredir.

Benzer şekilde Gerçekleşen RPO, sistemin durduğu an ile kurtarılan en son geçerli yedek noktasının oluşturulduğu an arasındaki farktır:

Gerçekleşen RPO = Olay Zamanı - Son Başarılı Yedek Zamanı

RPO ve RTO Hesaplama Senaryoları (Uygulamalı Örnekler)

Aşağıdaki üç senaryo, kurumsal ortamlarda RPO ve RTO hesaplama metodolojisini göstermek amacıyla kurgulanmış teknik örneklerdir.

1: Kurumsal Dosya Sunucusu (File Server)

• İşletme Bağlamı ve Tolerans: 250 çalışanlı bir mühendislik firmasının ortak proje ve teknik çizimlerinin tutulduğu 4 TB kapasiteli Windows File Server sunucusu. Günlük veri değişim hızı yaklaşık 60 GB'tır. İşletme en fazla 1 iş günü (24 saat) veri kaybını ve en fazla 4 saatlik kesintiyi tolere edebilmektedir.
• Tanımlanan Hedefler: RPO Hedefi = 24 Saat | RTO Hedefi = 4 Saat (240 Dakika)
• Zaman Çizelgesi:
  • Son Başarılı Yedekleme Zamanı: Pazartesi 23:00 (Artımlı yedek)
  • Olay Zamanı: Salı 14:30 (Depolama denetleyicisi arızası)
  • Geri Yüklenen Verinin Zaman Noktası: Pazartesi 23:00
• RPO Hesaplaması: Salı 14:30 ile Pazartesi 23:00 arasındaki fark 15 saat 30 dakikadır. Belirlenen RPO hedefi 24 saat olduğu için (15.5 saat küçüktür 24 saat), RPO hedefi karşılanmıştır. (Salı sabahı oluşturulan dosyalar kaybedilmiştir ancak belirlenen iş toleransı içindedir.)
• RTO Hesaplaması:
  • Olay tespiti ve donanım arızası doğrulaması: 25 dakika
  • Yedek sunucu üzerinde yeni sanal makine tahsisi: 20 dakika
  • 4 TB verinin 10 Gbps yerel ağ üzerinden geri yüklenmesi: 145 dakika
  • NTFS izinleri ve paylaşım kontrolleri: 20 dakika
  • Proje ekibinin dosya erişim onayı: 15 dakika
  • Toplam Gerçekleşen RTO: 25 + 20 + 145 + 20 + 15 = 225 Dakika (3 Saat 45 Dakika)
• Değerlendirme: 225 dakikalık kurtarma süresi, 240 dakikalık RTO hedefinin altında kaldığı için RTO hedefi başarıyla karşılanmıştır. Ancak 15 dakikalık dar bir güvenlik payı kaldığı için ağ veya depolama performansının izlenmesi önerilir.

2: SQL Server Veritabanı (E-Ticaret Sipariş Sistemi)

• İşletme Bağlamı ve Tolerans: Aktif sipariş ve ödeme kayıtlarının işlendiği 850 GB büyüklüğündeki SQL Server üretim veritabanı. İşletme en fazla 15 dakikalık sipariş kaybını ve en fazla 1 saatlik (60 dakika) hizmet kesintisini kabul etmektedir.
• Tanımlanan Hedefler: RPO Hedefi = 15 Dakika | RTO Hedefi = 60 Dakika
• Zaman Çizelgesi:
  • Son Başarılı Yedekleme Zamanı: Çarşamba 11:00 (Transaction Log yedeği; her 15 dakikada bir alınmaktadır)
  • Olay Zamanı: Çarşamba 11:12 (Hatalı bir güncelleme betiği nedeniyle tabloların bozulması)
  • Geri Yüklenen Verinin Zaman Noktası: Çarşamba 11:00 (11:15 log yedeği henüz alınmadığı için 11:00 noktasına dönülmüştür)
• RPO Hesaplaması: Çarşamba 11:12 ile 11:00 arasındaki fark 12 dakikadır. Hedeflenen RPO 15 dakika olduğu için (12 dk küçüktür 15 dk), RPO hedefi karşılanmıştır.
• RTO Hesaplaması:
  • Veri bozulmasının fark edilmesi ve geri dönüş kararı: 18 dakika
  • Mevcut veritabanının çevrimdışı alınması ve geri yükleme hazırlığı: 7 dakika
  • Son tam yedek + fark yedeği + işlem günlüklerinin uygulanması: 38 dakika
  • DBCC CHECKDB ve uygulama bağlantı kontrolleri: 12 dakika
  • E-ticaret operasyon ekibinin sipariş testi: 10 dakika
  • Toplam Gerçekleşen RTO: 18 + 7 + 38 + 12 + 10 = 85 Dakika (1 Saat 25 Dakika)
• Değerlendirme: RPO hedefi tutturulmuş olmasına rağmen, gerçekleşen RTO (85 dakika), hedeflenen 60 dakikalık sınırı 25 dakika aşmıştır. Sorunun temel kaynağı tam + fark + log zincirinin tek tek uygulanması ve olay tespitinin 18 dakika sürmesidir. Çözüm için fark yedekleme sıklığı artırılmalı ve hızlı geri dönüş için veritabanı anlık görüntüsü (database snapshot) veya replikasyon mimarisine geçilmelidir.

3: Kurumsal ERP ve Üretim Takip Uygulaması

• İşletme Bağlamı ve Tolerans: Fabrika üretim bandı, depo sevkiyatı ve muhasebe modüllerini yöneten çok katmanlı ERP sistemi (Uygulama Sunucusu + Veritabanı Sunucusu). Üretimin durmaması için RPO hedefi 1 saat, RTO hedefi 2 saat (120 dakika) olarak belirlenmiştir.
• Tanımlanan Hedefler: RPO Hedefi = 1 Saat (60 Dakika) | RTO Hedefi = 2 Saat (120 Dakika)
• Zaman Çizelgesi:
  • Son Başarılı Yedekleme Zamanı: Perşembe 08:00 (Saatlik artımlı imaj yedeği)
  • Olay Zamanı: Perşembe 09:40 (09:00 yedekleme görevi kaynak sunucudaki disk kuyruğu yoğunluğu nedeniyle zaman aşımına uğrayıp başarısız olmuştur; sistem 09:40'ta tamamen çökmüştür)
  • Geri Yüklenen Verinin Zaman Noktası: Perşembe 08:00
• RPO Hesaplaması: Olay saati 09:40 ile kurtarılabilen son sağlam yedek olan 08:00 arasında 1 saat 40 dakika (100 dakika) fark vardır. Hedeflenen RPO 60 dakika olduğu için RPO hedefi 40 dakika aşılmıştır.
• RTO Hesaplaması:
  • Olay tespiti ve eskalasyon: 15 dakika
  • Instant VM Recovery ile veritabanı ve uygulama sunucularının başlatılması: 22 dakika
  • Servis bağımlılıklarının (lisans servisi, barkod terminali API'leri) ayağa kaldırılması: 35 dakika
  • Depo ve üretim hattı kullanıcı onayı: 15 dakika
  • Toplam Gerçekleşen RTO: 15 + 22 + 35 + 15 = 87 Dakika (1 Saat 27 Dakika)
• Değerlendirme: Instant VM Recovery teknolojisi sayesinde RTO hedefi (120 dakika) kolaylıkla karşılanmış (87 dakika); ancak 09:00 yedekleme görevinin başarısız olmasına anında müdahale edilmediği için RPO hedefi başarısız olmuştur.

RPO ve RTO Hedeflerine Ulaşılamazsa Ne Yapılmalıdır?

Geri yükleme testi sonucunda gerçekleşen RPO veya RTO değerleri belirlenen hedefleri aşıyorsa, ya teknik altyapı kapasitesi artırılmalı ya da iş birimiyle mutabık kalınarak hedefler ve bütçe yeniden dengelenmelidir.

Testlerde hedef sapması görüldüğünde uygulanabilecek teknik ve yönetsel iyileştirme adımları şunlardır:

1. RPO Hedefi Aşılıyorsa Yapılacaklar:
   • Yedekleme Sıklığını Artırın: Günlük yedekleme yerine saatlik artımlı yedeklemeye veya veritabanları için 5-15 dakikalık işlem günlüğü (transaction log) yedeklemesine geçin.
   • CDP (Continuous Data Protection – Sürekli Veri Koruma) Kullanın: Çok düşük RPO (saniyeler düzeyinde) gereken kritik sistemlerde blok düzeyinde sürekli replikasyon teknolojilerini devreye alın.
   • Yedekleme Penceresi Darboğazlarını Giderin: Yedekleme görevlerinin zaman aşımına uğramasını önlemek için kaynak sunucudaki anlık görüntü (snapshot) yükünü azaltın ve yedekleme trafiğini ayrı bir depolama ağına (SAN / Dedicated Backup VLAN) taşıyın.
2. RTO Hedefi Aşılıyorsa Yapılacaklar:
   • Anlık Kurtarma (Instant Recovery) Teknolojilerini Kullanın: Terabaytlarca veriyi ağ üzerinden kopyalamayı beklemek yerine, sanal makineleri doğrudan yedekleme depolama birimi üzerinden çalıştıran mimarilere geçin.
   • Sıcak Yedek (Warm/Hot Standby) veya Replikasyon Kurun: İkinci bir veri merkezinde veya bulutta hazır bekleyen replika sanal makineler kullanarak kurtarma süresini dakikalar seviyesine indirin.
   • Kurtarma Otomasyonu (Orchestration) Oluşturun: Sunucuların açılış sırasını (örneğin önce Active Directory ve DNS, ardından veritabanı, en son uygulama sunucusu) manuel müdahale gerektirmeden yürüten otomatik kurtarma planları (runbook) hazırlayın.
3. İş Hedeflerini ve Bütçeyi Yeniden Değerlendirin:
   • Sıfıra yakın RPO ve RTO hedefleri yüksek altyapı ve lisans maliyeti gerektirir. Eğer teknik iyileştirme maliyeti, sistemin kesinti anında kuruma vereceği finansal zarardan yüksek çıkıyorsa, süreç sahipleriyle görüşülerek ilgili sistemin RPO/RTO hedefleri gerçekçi bir seviyeye revize edilmelidir.

Fidye Yazılımı Saldırılarında Yedek Geri Yükleme Testi Neden Önemlidir?

Fidye yazılımı (ransomware) saldırılarında saldırganların birincil hedeflerinden biri üretim sunucularıyla birlikte kurumsal yedekleme altyapısını da şifrelemek veya silmektir. Bu nedenle yedeklerin saldırıdan etkilenmediğinin ve geri yüklenecek yedek noktasında uyuyan zararlı yazılım (dwell time) bulunmadığının test edilmesi hayati önem taşır.

Modern fidye yazılımı grupları, bir kurumun ağına sızdıktan sonra hemen şifreleme başlatmaz; haftalar hatta aylar boyunca sistemde gizlenerek (dwell time) yönetici yetkilerini ele geçirir, Active Directory yapısını inceler ve yedekleme sunucularına ulaşarak yedek arşivlerini bozar veya siler. CISA (Cybersecurity and Infrastructure Security Agency) fidye yazılımı müdahale rehberleri, saldırı sonrası kurtarma sürecinde şu kritik adımların uygulanmasını vurgular:

• Temiz Geri Yükleme Noktasının (Clean Recovery Point) Tespiti: En son alınan yedek, büyük olasılıkla saldırganın sistemde aktif olduğu ve arka kapı (backdoor) bıraktığı döneme aittir. Geri yükleme testi sırasında farklı tarihlerdeki yedek kopyaları izole bir sandbox ortamında açılarak güncel uç nokta koruma (EDR/AV) ve adli bilişim (forensic) araçlarıyla taranmalı, zararlı yazılımın sisteme ilk girdiği tarihten önceki temiz yedek noktası belirlenmelidir.
• Kimlik İzolasyonu ve Parola Sıfırlama: Yedekler geri yüklendiğinde eski yönetici parolaları ve Active Directory biletleri (Kerberos TGT) hala geçerli olacağından, sistem üretim ağına alınmadan önce izole ortamda tüm ayrıcalıklı hesapların parolaları sıfırlanmalı ve güvenlik yamaları uygulanmalıdır.
• Yedeklerin Kendi Sağlamlığının Kanıtlanması: Saldırı anında yedeklerin gerçekten değiştirilemez (immutable) veya çevrimdışı (air-gapped) kaldığının periyodik testlerle doğrulanmış olması, fidye ödeme baskısına karşı kurumun elindeki tek teknik güvencedir.

3-2-1 Yedekleme Kuralı ve Immutable Backup Nedir?

3-2-1 yedekleme kuralı, verilerin en az 3 kopyasının oluşturulmasını, bu kopyaların 2 farklı depolama ortamında saklanmasını ve 1 kopyanın fiziksel olarak farklı bir lokasyonda (off-site) tutulmasını öngören temel veri koruma mimarisidir. Immutable Backup (Değiştirilemez Yedekleme) ise yedek verilerinin belirlenen saklama süresi boyunca sistem yöneticileri dahil hiç kimse tarafından silinemeyecek, değiştirilemeyecek veya şifrelenemeyecek şekilde (WORM – Write Once, Read Many) kilitlenmesidir.

Günümüzün gelişmiş siber tehdit ortamında klasik 3-2-1 kuralı, endüstride yaygın olarak kullanılan 3-2-1-1-0 kuralına evrilmiştir:

• 3 Kopya: Birincil üretim verisi ve en az iki yedek kopyası.
• 2 Farklı Medya/Ortam: Örneğin yerel disk tabanlı yedekleme sunucusu ve bulut nesne depolama (Object Storage) veya teyp ünitesi.
• 1 Farklı Lokasyon (Off-Site): Yangın, sel, deprem veya bölgesel elektrik kesintilerine karşı verinin ana veri merkezinden uzakta bir lokasyonda tutulması.
• 1 Değiştirilemez (Immutable) veya Çevrimdışı (Air-Gapped) Kopya: Fidye yazılımı saldırganları alan adı yöneticisi (Domain Admin) yetkisini ele geçirse dahi bu kopyayı silemez veya üzerine yazamaz. Linux tabanlı güçlendirilmiş depolar (Hardened Repository) veya S3 Object Lock mekanizmaları bu korumayı sağlar.
• 0 Doğrulama Hatası: Alınan tüm yedeklerin düzenli olarak geri yükleme testlerinden geçirilerek sıfır hatayla doğrulanması.

Yedek Geri Yükleme Testi Ne Sıklıkla Yapılmalıdır?

Yedek geri yükleme testleri, sistemlerin kritikliğine bağlı olarak katmanlı bir takvimle yürütülmelidir: otomatik bütünlük kontrolleri günlük/haftalık, kritik sistemlerin sanal makine ve veritabanı geri yükleme testleri 3 ayda bir (çeyreklik), kapsamlı felaket kurtarma tatbikatları ise yılda en az bir veya iki kez yapılmalıdır.

Sabit bir takvime ek olarak, aşağıdaki olay tabanlı durumlarda planlı tarih beklenmeden mutlaka ek bir geri yükleme testi gerçekleştirilmelidir:

• Sunucu işletim sistemi veya veritabanı motorunda büyük sürüm yükseltmeleri (major upgrade) yapıldığında,
• Yedekleme yazılımı veya depolama altyapısı (SAN/NAS/Bulut) değiştirildiğinde,
• Ağ topolojisinde, güvenlik duvarı kurallarında veya Active Directory yapısında köklü değişiklikler uygulandığında,
• Kuruma yeni bir kritik iş uygulaması (ERP, CRM vb.) dahil edildiğinde.

Felaket Kurtarma ve İş Sürekliliği Planlaması

İş Sürekliliği Planlaması (BCP – Business Continuity Planning), bir kriz veya felaket sırasında kurumun temel iş fonksiyonlarını kesintisiz veya kabul edilebilir düzeyde sürdürmesini sağlayan bütünsel yönetim stratejisidir; Felaket Kurtarma Planı (DRP – Disaster Recovery Plan) ise bu stratejinin bilişim altyapısını, sunucularını ve verilerini yeniden çalışır hale getirmeye odaklanan teknik alt bileşenidir.

Başka bir ifadeyle; İş Sürekliliği Planı "kriz anında çalışanlar nereden çalışacak, müşterilere nasıl hizmet verilecek ve tedarik zinciri nasıl yönetilecek?" sorularını yanıtlarken, Felaket Kurtarma Planı "veri merkezi devre dışı kaldığında sunucular, veritabanları ve ağ bağlantıları hangi sırayla ve hangi RPO/RTO hedefleriyle ayağa kaldırılacak?" sorusuna odaklanır.

Yedek geri yükleme testleri, Felaket Kurtarma Planı'nın kağıt üzerinde kalmasını önleyen en somut doğrulama mekanizmasıdır. Yedekleri geri yüklenemeyen veya kurtarma süresi iş birimlerinin beklentisini karşılamayan bir altyapıda, hiçbir iş sürekliliği planı başarıya ulaşamaz. Kurumsal altyapınızın kesinti toleransını analiz etmek ve RPO/RTO hedeflerinize uygun mimariyi kurgulamak için felaket kurtarma ve yedekleme planlaması çözümlerimizi inceleyebilirsiniz.

Uygulama Kontrol Listeleri ve Raporlama Şablonları

Teknik ekiplerin geri yükleme testlerini standartlaştırması ve yönetim kurullarına veya denetçilere sunulabilir kanıtlar üretmesi için aşağıdaki üç referans tablo operasyonel rehber olarak kullanılabilir.

Başarılı ve Başarısız Test Kriterleri Tablosu

Değerlendirme Alanı	Başarılı Test Kriteri (Pass)	Başarısız Test Kriteri (Fail)
Dosya & İmaj Bütünlüğü	Checksum/hash doğrulaması hatasız tamamlandı, tüm zincir okunabilir.	Yedek arşivi bozuk, artımlı zincir kırık veya okuma hatası (CRC) var.
Sistem Açılışı (Boot)	Sunucu/VM mavi ekran veya çekirdek hatası vermeden açıldı.	Önyükleme başarısız, eksik sürücü veya bozuk sistem diski hatası.
Veritabanı Tutarlılığı	DBCC CHECKDB (veya eşdeğeri) sıfır hata ile tamamlandı.	Sayfa/indeks bozulması, eksik işlem günlüğü veya tutarsız veri.
Uygulama Fonksiyonu	İş birimi kullanıcısı giriş yaptı, verileri okudu ve test kaydı oluşturdu.	Uygulama servisi başlamadı, lisans/API hatası verdi veya veriler eksik.
RPO Uyumluluğu	Gerçekleşen RPO ≤ Hedeflenen RPO	Gerçekleşen RPO > Hedeflenen RPO
RTO Uyumluluğu	Gerçekleşen RTO ≤ Hedeflenen RTO	Gerçekleşen RTO > Hedeflenen RTO

Geri Yükleme Testi Uygulama Kontrol Listesi (Checklist)

• Test edilecek sistemlerin iş kritikliği ve bağımlılık haritası (DNS, AD, DB, Lisans) çıkarıldı.
• İlgili sistem için hedeflenen RPO ve RTO değerleri yazılı olarak onaylandı.
• Test ortamının üretim ağından tamamen izole edildiği (VLAN / Firewall / vSwitch) doğrulandı.
• Şifrelenmiş yedeklerin kurtarma anahtarlarının ve parolalarının erişilebilir olduğu kontrol edildi.
• Yedek dosyalarının bütünlük (hash/checksum) kontrolü tamamlandı.
• Geri yükleme işlemi başlatılırken kronometre / zaman damgası kaydı tutuldu.
• Geri yüklenen sunucu veya veritabanı üzerinde servis ve bütünlük testleri çalıştırıldı.
• Süreç sahibi veya son kullanıcı tarafından fonksiyonel doğrulama (UAT) yapıldı.
• Gerçekleşen RPO ve RTO süreleri hesaplanarak hedeflerle karşılaştırıldı.
• Tespit edilen aksaklıklar ve iyileştirme aksiyonları test raporuna işlendi.

Test Sonuçlarının Raporlanmasında Kullanılacak Ölçüm Alanları

Rapor Alanı	Açıklama ve İçerik Detayı	Örnek Kayıt Formatı
Test Kimliği ve Tarihi	Testin benzersiz takip numarası ve uygulama tarihi	DR-TEST-2026-Q4-01 / 12.11.2026
Test Edilen Sistem & Yedek Noktası	Sunucu adı, IP/VLAN bilgisi ve seçilen yedek zaman damgası	ERP-DB-01 / 11.11.2026 23:00 (Incremental)
Hedef vs. Gerçekleşen RPO	Tanımlanan veri kaybı hedefi ile testte ulaşılan değer	Hedef: 60 dk - Gerçekleşen: 45 dk (Uygun)
Hedef vs. Gerçekleşen RTO	Tanımlanan kesinti süresi hedefi ile toplam kurtarma süresi	Hedef: 120 dk - Gerçekleşen: 138 dk (18 dk Sapma)
Aşama Bazlı Süre Dağılımı	Tespit, hazırlık, aktarım, doğrulama ve onay süreleri	Tespit: 15dk, Aktarım: 95dk, Doğrulama: 28dk
Karşılaşılan Engeller & Kök Neden	Test sırasında yaşanan teknik gecikmeler veya hatalar	Yedekleme depolama IOPS darboğazı nedeniyle aktarım uzadı.
Düzeltici Aksiyon Planı	Sorunu giderecek teknik adım, sorumlu ve termin tarihi	SSD önbellek katmanı eklenecek – Sorumlu: Sistem Ekibi
Onay İmzaları	Testi yürüten BT uzmanı ve doğrulayan süreç sahibi	BT Sistem Yöneticisi & Finans Süreç Sorumlusu

Kurumsal Veri Güvenliği ve Kurtarma Süreçlerinizde Profesyonel Yaklaşım

Yedekleme altyapınızın yalnızca kağıt üzerinde değil, gerçek kriz senaryolarında da belirlenen RPO ve RTO hedeflerini karşıladığından emin olmak iş sürekliliğinin temel şartıdır. DrDiskLab olarak kurumsal yedekleme mimarilerinin analizi, veri bütünlüğü doğrulaması, fidye yazılımına dayanıklı kurtarma planlaması ve veri kurtarma süreçlerinde teknik uzmanlığımızla kurumların yanında yer alıyoruz. Mevcut yedekleme altyapınızın kurtarma kapasitesini değerlendirmek ve kurumunuza özel doğrulama prosedürleri oluşturmak için teknik ekibimizle iletişime geçebilirsiniz.

Yedek Geri Yükleme Testi Hakkında Sık Sorulan Sorular

1. Yedek geri yükleme testi nedir?

Yedek geri yükleme testi, yedekleme yazılımları tarafından alınan veri kopyalarının üretim ortamından izole edilmiş bir test altyapısına geri yüklenerek hem dosya bütünlüğünün hem de uygulamaların çalışır durumda olduğunun fiilen doğrulanması sürecidir. Bu test, yedeklerin kriz anında gerçekten kurtarılabilir olduğunu kanıtlar.

2. Yedekleme testi neden yapılmalıdır?

Yedekleme testi, yedekleme yazılımının arayüzünde "başarılı" görünen görevlerin arka planda bozuk dosya, kırık yedek zinciri veya eksik uygulama bağımlılıkları nedeniyle geri yüklenememe riskini ortadan kaldırmak için yapılmalıdır. Ayrıca belirlenen RPO ve RTO hedeflerinin gerçek hayatta karşılanıp karşılanmadığını ölçmenin tek güvenilir yoludur.

3. Yedeklerin sağlam olduğu nasıl anlaşılır?

Yedeklerin sağlam olduğu, yalnızca yedekleme loglarındaki başarı bildirimlerine bakılarak değil; yedek dosyalarının hash/checksum bütünlük kontrollerinden geçirilmesi, izole bir ortamda geri yüklenmesi ve veritabanı tutarlılık komutları (DBCC CHECKDB gibi) ile uygulama açılış testlerinin hatasız tamamlanmasıyla anlaşılır.

4. RPO ve RTO arasındaki fark nedir?

RPO (Kurtarma Noktası Hedefi) bir kesinti anında işletmenin katlanabileceği maksimum veri kaybı süresini (yedekleme sıklığını) ifade ederken; RTO (Kurtarma Zamanı Hedefi) kesinti sonrasında sistemlerin yeniden çalışır hale gelmesi için belirlenen maksimum kurtarma süresini ifade eder. RPO geriye dönük veri kaybını, RTO ileriye dönük kesinti süresini ölçer.

5. RPO ve RTO nasıl hesaplanır?

RPO, kesinti anı ile kurtarılabilen en son geçerli yedekleme zamanı arasındaki fark hesaplanarak ölçülür. RTO ise olayın tespit edilmesi, test/kurtarma ortamının hazırlanması, verilerin aktarılması, servislerin doğrulanması ve iş biriminin sistemi onaylaması için geçen toplam sürenin toplanmasıyla hesaplanır.

6. Yedek geri yükleme testi ne sıklıkla yapılmalıdır?

Yedek geri yükleme testi, otomatik dosya/imaj bütünlük doğrulamaları için haftalık veya aylık periyotlarla; kritik veritabanları ve sanal sunucular için 3 ayda bir (çeyreklik); kapsamlı felaket kurtarma tatbikatları için ise yılda en az bir kez yapılmalıdır. Altyapı veya sürüm değişikliklerinden sonra ayrıca test tekrarlanmalıdır.

7. SQL Server yedeği nasıl test edilir?

SQL Server yedeği, üretim sunucusunu etkilemeyecek izole bir SQL Server örneğine tam, fark ve işlem günlüğü yedeklerinin sırayla geri yüklenmesi ve ardından veritabanı sayfalarının mantıksal ve fiziksel bütünlüğünü denetleyen DBCC CHECKDB komutunun çalıştırılmasıyla test edilir.

8. Backup restore testi ne kadar sürer?

Backup restore testinin süresi, yedeklenen verinin boyutuna, depolama biriminin okuma/yazma (IOPS) hızına, ağ bant genişliğine ve kullanılan kurtarma yöntemine (Instant VM Recovery veya tam kopyalama) bağlı olarak birkaç dakikadan birkaç saate kadar değişebilir. Testin temel amaçlarından biri de bu süreyi net olarak ölçmektir.

9. Fidye yazılımı saldırısından sonra yedekler nasıl geri yüklenir?

Fidye yazılımı saldırısından sonra yedekler, doğrudan canlı ortama değil önce tamamen izole bir sandbox ortamına geri yüklenir; zararlı yazılımın sisteme sızdığı tarihten önceki temiz geri yükleme noktası bulunur, antivirüs/EDR taramaları yapılır, tüm yönetici parolaları sıfırlanır ve güvenlik açıkları kapatıldıktan sonra temiz üretim altyapısına aktarılır.

10. Immutable Backup nedir?

Immutable Backup (Değiştirilemez Yedekleme), yedek dosyalarının belirlenen saklama süresi dolana kadar sistem yöneticileri, kök kullanıcılar veya fidye yazılımları tarafından silinmesini, değiştirilmesini ve şifrelenmesini engelleyen (WORM – Write Once, Read Many) güvenlik teknolojisidir.

11. 3-2-1 yedekleme kuralı nedir?

3-2-1 yedekleme kuralı, kurumsal verilerin en az 3 kopyasının oluşturulmasını, bu kopyaların 2 farklı depolama ortamında tutulmasını ve en az 1 kopyanın fiziksel olarak farklı bir lokasyonda saklanmasını öngören temel yedekleme stratejisidir. Modern yaklaşımda buna 1 değiştirilemez/çevrimdışı kopya ve 0 doğrulama hatası (3-2-1-1-0) eklenir.

12. Yedekleme ve felaket kurtarma arasındaki fark nedir?

Yedekleme (Backup) verilerin belirli zaman noktalarındaki kopyalarını saklama işlemidir; Felaket Kurtarma (Disaster Recovery) ise doğal afet, donanım çökmesi veya siber saldırı gibi büyük kesintilerde tüm BT altyapısını, sunucuları, ağ bağlantılarını ve iş uygulamalarını belirlenen RPO ve RTO hedefleri doğrultusunda yeniden ayağa kaldırma sürecidir.