- 01Backup job başarılı olması geri dönüşün çalıştığını kanıtlamaz; gerçek restore testi veri, uygulama ve dependency zincirini ayrı ortamda doğrulamalıdır.
- 02RTO, restore işlemi bitene kadar değil uygulamanın işlevsel doğrulamayı geçtiği ana kadar ölçülmelidir; RPO ise gerçek geri yüklenen veri zaman noktasından hesaplanmalıdır.
- 03Aylık restore testi NIST veya CISA'nın tüm kuruluşlar için koyduğu bir zorunluluk değildir; kritik sistemler için kullanılabilecek risk bazlı operasyon başlangıç modelidir.
- 04NIST SP 1339 tekrarlanan restore testlerinin non-production ortamında yapılmasını ve sonuçların belgelenmesini önerir.
- 05Aylık küçük testleri çeyreklik geniş kapsamlı senaryolarla tamamlamak backup zincirindeki kimlik, DNS, secret, uygulama ve failback sorunlarını daha erken ortaya çıkarır.
Kısaca
Yedeğinizin olması, geri dönebileceğiniz anlamına gelmez. Aylık geri yükleme testi; yedeğin ayrı bir ortamda açılabildiğini, uygulamanın çalıştığını ve ölçülen RPO/RTO hedeflerinin karşılandığını doğrular. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak restore testini backup job durumundan ayrı bir operasyon kontrolü olarak ele alır. Aylık plan burada zorunluluk değil, kritik sistemler için uygulanabilir bir başlangıç takvimidir.
Aylık test planının amacı
Bu planın amacı her ay tüm felaket senaryosunu baştan sona canlandırmak değildir. Amaç, yedek zincirinin gerçekten kullanılabilir olduğunu sürekli kanıtlamaktır.
Aylık testte en az şu dört soruya cevap verin:
- Doğru recovery point seçilebiliyor mu?
- Veri ayrı bir test ortamına geri yüklenebiliyor mu?
- Uygulama ve bağımlılıkları çalışıyor mu?
- Ölçülen RPO ve RTO hedefi karşılanıyor mu?
CISA düzenli backup testlerini, NIST ise tekrarlanan restore testlerini ve kurtarma tatbikatlarını veri koruma programının parçası olarak ele alır. Ancak tüm kuruluşlar için tek bir aylık test zorunluluğu yoktur. Bu nedenle aşağıdaki takvim Dynamis'in örnek operasyon modelidir.
Ayın başında test kapsamını seçin
Her ay aynı sistemi test etmek yerine kritik sistemleri döngüye alın.
Örnek rotasyon:
| Ay | Test edilecek sistem | Test tipi |
|---|---|---|
| Ocak | SQL veritabanı | Point-in-time restore |
| Şubat | Dosya sunucusu | Dosya + izin geri yükleme |
| Mart | Kritik uygulama | Tam VM / image restore |
| Nisan | Kimlik sistemi | Sistem state / directory restore |
| Mayıs | Object storage | Silinmiş obje geri yükleme |
| Haziran | Uygulama + DB | Uçtan uca restore |
Sonraki aylarda döngüyü tekrarlayın veya yeni sistemleri ekleyin.
Kritik sistemler daha sık test edilebilir. Düşük etkili sistemlerde daha seyrek takvim kullanılabilir. Test sıklığını RPO/RTO, değişiklik hızı ve iş etkisine göre belirleyin.
Test öncesi kontrol listesi
Geri yükleme testinden önce aşağıdakileri doğrulayın:
- Yedek job son başarılı zamanını
- Seçilecek recovery point'i
- Yedek bütünlük kontrolünü
- Şifreleme anahtarına erişimi
- Restore için yeterli test kapasitesini
- Uygulama dependency listesini
- DNS, IP ve sertifika gereksinimlerini
- Test ortamının üretimden izole olduğunu
- Başarı kriterlerini
- Test sorumlusunu
NIST SP 1339, tekrarlanan restore testlerinin non-production sistemlerde yapılmasını önerir. Bu yaklaşım üretim riskini azaltır ve gerçek geri dönüş prosedürünü güvenle denemenizi sağlar.
Adım 1: Recovery point'i kaydedin
Test başlangıcında seçtiğiniz yedek noktasını belgeleyin.
Kayıt örneği:
- Sistem: ERP-DB-01
- Backup zamanı: 19 Eylül 2026 02:00
- Test başlangıcı: 19 Eylül 2026 10:00
- Hedef RPO: 4 saat
- Hedef RTO: 2 saat
Bu örnekte seçilen recovery point test anından 8 saat gerideyse RPO hedefi daha test başlamadan karşılanmıyor olabilir.
RPO yalnızca "yedek her dört saatte bir çalışıyor" demek değildir. Geri yüklenen verinin gerçekten hangi zaman noktasını temsil ettiğini ölçün.
Adım 2: Ayrı ortama geri yükleyin
Restore'u varsayılan olarak üretim dışı ve izole bir ortama yapın.
Test ortamı:
- Üretim network'üne gereksiz erişim vermemeli
- Aynı hostname veya IP ile çakışmamalı
- E-posta, ödeme veya entegrasyon gibi dış aksiyonları tetiklememeli
- Gerekirse dummy DNS ve credentials kullanmalı
- Test bitiminde temizlenebilmeli
Amaç yalnızca dosyaları görmek değil, gerçek kurtarma zincirini test etmektir.
Adım 3: Uygulama doğrulamasını yapın
Restore tamamlandığında test bitmiş sayılmaz.
Doğrulama seviyeleri:
Seviye 1: Veri okunabiliyor mu?
- Dosyalar açılıyor mu?
- Database mount oluyor mu?
- Backup bozuk mu?
- Şifreleme anahtarı çalışıyor mu?
Seviye 2: Uygulama açılıyor mu?
- Service başlıyor mu?
- Database bağlantısı kuruluyor mu?
- Kullanıcı login olabiliyor mu?
- Gerekli sertifikalar ve secret'lar mevcut mu?
Seviye 3: İş akışı çalışıyor mu?
- Örnek sipariş görüntüleniyor mu?
- Dosya yükleme/okuma çalışıyor mu?
- Kritik API endpoint cevap veriyor mu?
- Batch job veya queue tüketimi doğru mu?
Gerçek restore testi en az bir işlevsel doğrulama içermelidir.
Adım 4: RTO'yu ölçün
RTO ölçümünü restore butonuna basıldığı anda değil, kurtarma işlemi başlatıldığı anda başlatın.
Ölçülebilir başlangıç:
T0 = restore talebinin onaylandığı zaman
Ölçülebilir bitiş:
T1 = uygulamanın başarı kriterlerini geçtiği zaman
Formül:
Ölçülen RTO = T1 - T0
Örnek:
- T0: 10:05
- Restore tamamlandı: 10:42
- Database doğrulandı: 10:51
- Uygulama smoke test geçti: 11:07
Ölçülen RTO:
62 dakika
Hedef RTO 60 dakikaysa test teknik olarak başarısızdır; restore job bitmiş olsa bile iş hedefi karşılanmamıştır.
Adım 5: RPO'yu ölçün
RPO için geri dönen verinin en son geçerli zamanını bulun.
Örnek:
- Test başlangıcı: 10:00
- Geri yüklenen son transaction: 08:30
- Ölçülen veri kaybı penceresi: 1 saat 30 dakika
Hedef RPO 2 saat ise hedef karşılanmıştır.
Database point-in-time recovery kullanılıyorsa son uygulanabilen log/WAL noktası; dosya sisteminde ise son backup/snapshot zamanı kullanılabilir.
Adım 6: Backup job ile restore sonucunu karşılaştırın
En değerli bulgulardan biri şudur:
Backup job successful ama Restore test failed
Bu durum şu nedenlerle oluşabilir:
- Eksik encryption key
- Yanlış IAM/ACL
- Bozuk incremental chain
- Uygulama-consistent olmayan snapshot
- Eksik database log
- Eski secret
- DNS bağımlılığı
- Sertifika süresi
- Uygulama ve database versiyon uyuşmazlığı
Bu nedenle backup başarısını restore başarısıyla ayrı metrik olarak takip edin.
Test sonucu için dört seviye kullanın
Basit bir sonuç modeli kullanabilirsiniz:
| Sonuç | Tanım | Aksiyon |
|---|---|---|
| Geçti | RPO/RTO ve fonksiyon testleri başarılı | Kayıt kapatılır |
| Koşullu geçti | Restore başarılı ancak hedeflerden biri sınırda | İyileştirme açılır |
| Başarısız | Restore veya işlevsel test başarısız | Öncelikli aksiyon |
| Test edilemedi | Ortam, erişim veya süreç engeli | Operasyon açığı olarak kaydedilir |
"Test edilemedi" sonucu başarı değildir. Özellikle şifreleme anahtarı veya test kapasitesi eksikliği gerçek felakette de aynı engeli oluşturabilir.
Aylık test raporunda ne tutulmalı
Her test için şu alanları saklayın:
- Sistem adı
- Test tarihi
- Test sorumlusu
- Backup kaynağı
- Recovery point
- Hedef RPO
- Ölçülen RPO
- Hedef RTO
- Ölçülen RTO
- Restore ortamı
- Uygulama doğrulama sonucu
- Hata ve bulgular
- Aksiyon sahibi
- Hedef kapatma tarihi
Bu kayıtlar yalnızca denetim için değil, trend görmek için değerlidir.
Örneğin üç ay boyunca RTO 45, 58 ve 76 dakika olduysa backup hala başarılı olabilir fakat kurtarma performansı kötüleşiyor demektir.
Üç ayda bir kapsamı genişletin
Aylık restore testi küçük ve tekrarlanabilir olmalıdır. Her üç ayda bir daha geniş senaryo deneyebilirsiniz.
Örnek çeyreklik test:
- Uygulama sunucusu restore
- Database restore
- DNS değişikliği
- Secret kontrolü
- Monitoring yeniden bağlama
- Kullanıcı smoke test
- Failback prosedürü
Bu test aylık kontrol ile tam felaket tatbikatı arasındaki boşluğu kapatır.
Yıllık tam tatbikat zorunluluk değil, risk kararıdır
Birçok kuruluş yıllık geniş kapsamlı disaster recovery exercise uygular; ancak bunu tüm şirketler için evrensel NIST/CISA zorunluluğu gibi yazmak doğru değildir.
Tam tatbikat sıklığı:
- Sistem kritikliği
- Regülasyon
- Büyük mimari değişiklikler
- İş etkisi
- Daha önceki test sonuçları
üzerinden belirlenmelidir.
Önemli olan planın gerçekçi aralıklarla çalıştırılması ve bulguların kapatılmasıdır.
Immutable veya offline yedeği ayrıca test edin
CISA, kritik backup'ların offline veya immutable olarak korunmasını önerir.
Ancak immutable olması restore edilebilir olduğu anlamına gelmez.
Test sırasında şunları doğrulayın:
- Doğru retention içindeki yedeğe erişilebiliyor mu?
- Restore rolü immutable objeyi okuyabiliyor mu?
- Encryption key erişilebilir mi?
- Başka hesap/bölge restore prosedürü çalışıyor mu?
- Recovery sırasında üretim admin hesabına ihtiyaç var mı?
En kritik yedek zinciri, en zor erişilen zincir olmamalıdır.
KVKK kapsamındaki test verisini kontrol edin
Restore testi kişisel veriyi production dışı ortama kopyalayabilir.
Bu nedenle:
- Test ortamına kim erişiyor?
- Veri ne kadar süre tutuluyor?
- Test bittiğinde nasıl siliniyor?
- Yurt dışındaki test ortamına veri aktarılıyor mu?
- Maskeleme mümkün mü?
sorularını önceden cevaplayın.
Kişisel veri içeren restore testleri için KVKK uyumlu bulut altyapısı rehberindeki erişim, saklama ve aktarım kontrollerini uygulayın.
RPO/RTO hedefini test sonucu üzerinden güncelleyin
Bazı hedefler kağıt üzerinde gerçekçi görünür ama ilk restore testinde karşılanmaz.
Örnek:
- Hedef RTO: 30 dakika
- 4 TB database restore süresi: 95 dakika
Burada iki seçenek vardır:
- Mimariyi değiştirin
- İş birimiyle RTO hedefini yeniden değerlendirin
Testin amacı yalnızca geçmek değil, gerçek kapasiteyi öğrenmektir.
Dynamis'te aylık restore operasyonu
Dynamis'in kurumsal altyapı hizmetinde yedekleme işini restore doğrulamasından ayrı takip ederiz.
Operasyon modeli şu bileşenlerden oluşabilir:
- Backup job takibi
- Aylık veya risk bazlı restore testi
- RPO/RTO ölçümü
- Restore evidence kaydı
- Çeyreklik geniş kapsamlı test
- Runbook güncellemesi
- Aksiyon takibi
- Felaket kurtarma tatbikatı planlaması
Temel 3-2-1 ve felaket kurtarma mimarisi için 3-2-1 yedekleme kuralı rehberini kullanın.
Sık yapılan hatalar
Backup job başarılı olduğu için restore testini atlamak: Backup yazılmış olabilir ama uygulama geri dönemeyebilir.
Testi yalnızca dosya açma olarak görmek: İşlevsel uygulama doğrulaması yapılmalıdır.
RTO'yu yalnız restore süresi olarak ölçmek: Uygulama kullanılır hale gelene kadar süre devam eder.
RPO'yu backup schedule ile eşitlemek: Gerçek recovery point doğrulanmalıdır.
Her ay aynı düşük riskli sistemi test etmek: Kritik sistemleri rotasyona alın.
Test verisini silmeyi unutmak: Özellikle kişisel veri içeren test ortamları süre sonunda temizlenmelidir.
Başarısız testi belgeleyip aksiyon açmamak: Restore testi ancak bulgular kapatıldığında operasyonel değer üretir.
Sırada ne var
- Bulut yedekleme fiyatları: maliyet nasıl hesaplanır?: düzenli geri dönüş testinin depolama, geçici kaynak ve operasyon maliyetine etkisini görün.
- Disaster Recovery nedir? Şirketler için felaket kurtarma planı: restore testlerini daha geniş recovery strategy, iş sürekliliği ve failover planına bağlayın.
- 3-2-1 yedekleme kuralı: backup mimarisini ve RPO/RTO temellerini kurun.
- KVKK uyumlu yedekleme: saklama süresi ve imha: restore edilen eski yedeklerde daha önce silinmiş kişisel verinin yeniden imha sürecini planlayın.
- KVKK uyumlu bulut altyapısı: restore test ortamındaki kişisel veri kontrollerini planlayın.
- Bulut sunucu mu, yönetilen altyapı mı?: backup ve restore sahipliğinin yalnız cloud sunucu satın almakla otomatik çözülmediğini değerlendirin.
- Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: restore operasyonunun kimde kalacağını belirleyin.
- Kurumsal altyapı hizmeti: backup, restore testi ve felaket kurtarma operasyonunu birlikte yönetin.
Kaynaklar
Kaynaklar
- 1.CISA #StopRansomware GuideCybersecurity and Infrastructure Security Agency · 2026-09-19
- 2.NIST SP 1339 OT Backup Quick Start GuideNational Institute of Standards and Technology · 2026-09-19
- 3.NIST SP 800-34 Rev. 1 Contingency Planning GuideNational Institute of Standards and Technology · 2026-09-19
- 4.Recovery Point ObjectiveNIST CSRC · 2026-09-19
- 5.Recovery Time ObjectiveNIST CSRC · 2026-09-19
Sık sorulan sorular
Yedek geri yükleme testi neyi doğrular?
Geri yükleme testi yalnızca yedek dosyasının okunabildiğini değil, verinin ayrı bir ortamda geri döndürülebildiğini, uygulamanın açıldığını, bağımlılıkların çalıştığını ve ölçülen RPO/RTO hedeflerinin karşılanıp karşılanmadığını doğrular.
Aylık geri yükleme testi zorunlu mu?
Hayır. NIST ve CISA düzenli veya tekrarlanan geri yükleme testlerini önerir ancak tüm kuruluşlar için aylık tek bir zorunlu sıklık belirlemez. Aylık plan, kritik sistemlerde kullanılabilecek operasyonel bir başlangıç noktasıdır; gerçek sıklık risk ve RPO/RTO hedeflerine göre belirlenmelidir.
Restore testinde RPO ve RTO nasıl ölçülür?
RPO için geri yüklenen verinin son geçerli zaman noktasını olay veya test başlangıcıyla karşılaştırın. RTO için geri yükleme talebinin başladığı andan uygulamanın işlevsel doğrulamayı geçtiği ana kadar geçen süreyi ölçün.
Backup job başarılıysa restore testi yine gerekir mi?
Evet. Başarılı backup job, verinin yazıldığını gösterir; uygulamanın geri dönebildiğini garanti etmez. Şifreleme anahtarı, izin, bozuk dosya, eksik dependency veya uygulama tutarlılığı sorunları ancak gerçek geri yükleme testinde ortaya çıkabilir.
Geri yükleme testi üretimde mi yapılmalı?
Varsayılan olarak ayrı ve izole bir non-production kurtarma ortamı daha güvenlidir. NIST SP 1339 da tekrarlanan restore testlerinin non-production sistemlerde yapılmasını önerir. Üretimde yapılan kontrollü tatbikatlar ayrıca planlanabilir.