Yedekleme testi, alınan yedekten veriyi ya da sistemi gerçekten geri yükleyip eksiksiz, tutarlı ve hedeflenen sürede çalışır hâle geldiğini doğrulama işidir. "Yedek başarılı" bildirimi, yedeğin geri döneceğini kanıtlamaz. Yedekleme testi nasıl yapılır? Dosya, veritabanı ve tüm sunucu düzeyinde, yazılı bir senaryoyla ve düzenli aralıklarla geri yükleme yapılır, sonuç kayda geçirilir.
Yedeğiniz var, peki geri dönebiliyor musunuz?
Çoğu şirkette yedekleme şöyle işler: gece bir görev çalışır, sabah "başarılı" yazan bir e-posta gelir ve kimse o yedeği bir daha açmaz. Sorun, bir gün sunucu çöktüğünde ya da fidye yazılımı dosyaları şifrelediğinde ortaya çıkar. Yedek dosyası açılmaz, veritabanı tutarsız çıkar, şifreleme anahtarı kimsede yoktur ya da geri yükleme saatler yerine günler sürer.
Başarılı yedek ile başarılı geri yükleme arasındaki boşluk, pek çok nedenle oluşur. Yedeklenen klasör listesi yıllar önce yazılmıştır ve yeni uygulama dışarıda kalmıştır. Veritabanı çalışırken dosya düzeyinde kopyalanmıştır ya da yedek yazılımının lisansı artık yoktur. Bunların hiçbiri, yedekten gerçekten geri dönmeyi denemeden görünmez.
Yedekleme stratejisinin temeli olan 3-2-1 kuralını ve fidye yazılımına karşı değiştirilemez kopyayı fidye yazılımından korunma ve 3-2-1 yedekleme yazısında anlattık. Bu yazı, o stratejinin son ve en çok atlanan adımına odaklanıyor: testin kendisine.
Yedek test edilmezse ne olur? Rakamlarla maliyeti
Güven ile gerçek arasındaki fark rakamlarla da görülüyor. Yedekleme yazılımı üreticisi Veeam'in 900'den fazla BT, güvenlik ve risk yöneticisiyle yaptığı Data Trust and Resilience Report 2026 araştırmasına göre:
Ankete katılan kurumların %90'ı bir siber olaydan kurtulabileceğinden emin olduğunu söyledi; ancak fidye yazılımı saldırısına uğrayan katılımcıların yalnızca %28'i etkilenen verilerin tamamını geri alabildi, ortalama kurtarılan veri oranı %72'de kaldı.
Planların test boyutu da zayıf. Veeam'in 1.300 kurumla yaptığı 2025 Ransomware Trends and Proactive Strategies Report araştırmasında ankete katılan kurumların %98'inin fidye yazılımı müdahale planı olduğu, ancak yedek doğrulama ve sıklığını plana yazanların yalnızca %44'te kaldığı görüldü.
Saldırganlar da yedeği bilerek hedefliyor. Güvenlik üreticisi Sophos'un 2.974 BT uzmanıyla yaptığı State of Ransomware 2024 araştırmasına dayanan Sophos: The impact of compromised backups on ransomware outcomes analizine göre, fidye yazılımına uğrayan katılımcı kurumların %94'ü, saldırganların yedeklerini ele geçirmeye çalıştığını söyledi ve bu girişimlerin %57'si başarılı oldu. Yedekleri ele geçirilen kurumların medyan toplam kurtarma maliyeti, yedekleri etkilenmeyenlerin sekiz katıydı. Test, yedeğin yalnızca var olduğunu değil, saldırıdan sağ çıktığını da göstermelidir.
Testten önce hedefi belirleyin: RPO ve RTO
Test, neyi ölçtüğünü bilmiyorsa sonuç üretmez. İki hedefi her kritik sistem için yazın:
- RPO (Recovery Point Objective, kurtarma noktası hedefi): En fazla ne kadarlık veri kaybını kabul edebilirsiniz? Muhasebe için "son 4 saat", dosya sunucusu için "dünkü gün sonu" gibi.
- RTO (Recovery Time Objective, kurtarma süresi hedefi): Sistem en geç ne kadar sürede yeniden çalışmalı? ERP için "aynı iş günü", web sitesi için "birkaç saat" gibi.
Bu iki rakamı iş birimleriyle birlikte belirleyin; BT'nin tek başına seçtiği hedefler genellikle ya pahalı ya da yetersiz çıkar. Test sonucunu bu hedeflerle karşılaştırırsınız: yedek 6 saatlik veri kaybı gösteriyorsa ve RPO 4 saatse, test başarısızdır.
| Test türü | Ne yapılır | Neyi kanıtlar |
|---|---|---|
| Dosya düzeyi geri yükleme | Rastgele seçilen dosya ve klasörler ayrı bir konuma geri yüklenir | Yedeğin okunabildiğini, kapsamın doğru olduğunu |
| Veritabanı / uygulama geri yükleme | ERP, muhasebe ya da CRM veritabanı test sunucusuna açılır, uygulama bağlanır | Verinin tutarlı olduğunu, uygulamanın çalıştığını |
| Tam sistem geri yükleme | Sunucu ya da sanal makine yalıtılmış ortamda sıfırdan ayağa kaldırılır | RTO'nun gerçekçi olduğunu |
| Felaket kurtarma tatbikatı | Birincil sistem yokmuş gibi, iş birimleriyle birlikte senaryo oynanır | İnsanların, parolaların ve prosedürün hazır olduğunu |
Yedekleme testi nasıl yapılır: 8 adım
- Kapsamı çıkarın. Kritik sistemleri listeleyin: dosya sunucusu, ERP ve muhasebe veritabanı, e-posta, web sitesi, üretim tarafında SCADA ve reçete verileri. Her birinin yedeğinin nerede, hangi sıklıkta alındığını yazın.
- RPO ve RTO hedeflerini yazın. Her sistem için iş birimiyle birlikte belirleyin.
- Yalıtılmış bir test ortamı hazırlayın. Geri yükleme canlı sistemin üzerine yapılmaz. Ayrı bir sanal makine, ayrı bir ağ bölümü ya da bulutta geçici bir ortam kullanın.
- Senaryoyu yazın. "Muhasebe veritabanını dünkü yedekten geri yükle, uygulamayı bağla, son beş faturayı kontrol et" gibi; kimin, hangi adımı, hangi araçla yapacağı belli olsun.
- Geri yükleyin ve süreyi ölçün. Kronometre, yedeğe erişim anından sistemin kullanılabilir olduğu ana kadar çalışsın. Parola, şifreleme anahtarı ya da lisans arayarak geçen süre de ölçüme dahildir.
- Sonucu iş gözüyle doğrulayın. Dosya sayısı tutuyor mu, veritabanı açılıyor mu, son kayıtlar yerinde mi? Mümkünse kontrolü sistemi her gün kullanan kişi yapsın.
- Kaydedin. Tarih, sistem, yedek noktası, geçen süre, bulunan sorunlar ve sorumlu. Bu kayıt, hem denetimde hem de gerçek olay anında en değerli belgenizdir.
- Bulguları kapatın ve takvime bağlayın. Her sorunun bir sahibi ve bitiş tarihi olsun; bir sonraki testin tarihini şimdiden belirleyin.
Testlerde en sık çıkan sorunlar
- Kapsam dışında kalmış sistemler: sonradan kurulan bir uygulama, bir çalışanın masaüstünde tutulan kritik Excel dosyaları, bulut hizmetindeki veriler.
- Tutarsız veritabanı yedeği: uygulama çalışırken dosya düzeyinde kopyalanan veritabanları açılmaz ya da eksik açılır.
- Kayıp anahtarlar: yedek şifrelidir ama anahtar, yedeğin kendisiyle aynı sunucudadır ya da işten ayrılan bir çalışanın bilgisayarındadır.
- Gerçekçi olmayan süreler: yedek uzak bir konumdadır ve internet hızıyla geri indirmek günler sürer.
Dosya sunucusundan buluta geçen şirketlerde sık görülen bir yanılgı da eşitleme ile yedeği karıştırmaktır. Bulutta eşitlenen bir klasör, silinen ya da şifrelenen dosyayı da eşitler. Sürüm geçmişi yanlışlıkla üzerine yazmaya karşı işe yarar; bunu dosya sürüm kontrolü yazısında anlattık. Ancak bağımsız, ayrı tutulan bir yedeğin yerini tutmaz.
Hangi test ne sıklıkla yapılmalı?
Sıklık, sistemin kritikliğine ve değişim hızına göre belirlenir. Genel bir başlangıç çerçevesi:
| Test | Önerilen sıklık |
|---|---|
| Yedek görevlerinin başarı/başarısızlık kontrolü | Her gün (otomatik uyarıyla) |
| Rastgele dosya geri yükleme | Ayda bir |
| Kritik veritabanı ve uygulama geri yükleme | Üç ayda bir |
| Tam sistem geri yükleme ve felaket kurtarma tatbikatı | Yılda en az bir kez ve her büyük altyapı değişikliğinden sonra |
Büyük değişiklikler, yani sunucu taşıma, buluta geçiş ya da yeni bir ERP'ye geçiş, takvimden bağımsız olarak ek test gerektirir. Üretim tesislerinde SCADA sunucusu ve PLC programlarının yedeği ayrıca ele alınmalıdır; OT tarafındaki özel riskleri SCADA ve OT güvenliği yazısında topladık.
Düzenli tutulan test kayıtları, ISO 27001 denetiminde yedeklerin gerçekten sınandığını gösteren en somut kanıtlardan biridir.
Yedeklerin kendisi de kişisel veri içerir. Saklama süresi dolan veriler yedeklerde de süresiz kalmamalıdır; bu dengeyi e-posta arşivleme ve KVKK yazısında e-posta örneği üzerinden anlattık. Kişisel veri içeren bir yedeğin yetkisiz kişilerin eline geçmesi de veri ihlali sayılabilir ve KVKK veri ihlali 72 saat yazısında anlattığımız bildirim sürecini başlatabilir; yedeğe erişimin kaybedilmesi de olay kaydına geçirilip bu açıdan değerlendirilmelidir.
Digital Bridge'de bu işi nasıl yapıyoruz?
Yedekleme projesini "yedek alınıyor mu?" sorusuyla değil, "yarın sabah bu sistem çökse kaç saatte ve ne kadar veri kaybıyla döneriz?" sorusuyla başlatıyoruz:
- Keşif ve ihtiyaç analizi. Bulut geçiş ve altyapı danışmanlığı kapsamında kritik sistemlerinizi, mevcut yedek görevlerini ve yedeklerin nerede durduğunu çıkarıyor; RPO ve RTO hedeflerini iş birimlerinizle birlikte yazıyoruz.
- Saldırıya dayanıklılık. Siber güvenlik çalışması kapsamında yedek sistemine erişim yetkilerini, yöneticilerde MFA'yı ve değiştirilemez ya da çevrim dışı kopyayı gözden geçiriyoruz.
- Pilot test. İlk geri yükleme testini en kritik tek sistemle, genellikle ERP ya da muhasebe veritabanıyla, sizin ekibinizle birlikte yapıyor; süreyi ölçüp bulguları raporluyoruz.
- Entegrasyon ve süreklilik. Test senaryolarını, kayıt şablonunu ve takvimi yazılı hâle getiriyor; üretim tarafında SCADA ve HMI sistemlerinin proje ve reçete yedeklerini de plana dahil ediyoruz. Raporlama altyapısı kullanıyorsanız veri ambarı kaynaklarının geri yüklenebilirliğini de test kapsamına alıyoruz.
Kendi ürünümüz Smart360 tarafında SmartFiles, yanlışlıkla silme ve üzerine yazmaya karşı ilk savunma hattını sağlar: aynı adla yüklenen her dosya yeni sürüm olur, önceki sürümler geri yüklenebilir ve çöp kutusundan klasörler de geri gelir. Yine de bu özellikleri, kurumunuzun bağımsız yedekleme ve test planının yerine değil, yanına koymanızı öneririz.
Sonraki adım
Bu ay tek bir test yapın: en kritik sisteminizi seçin, dünkü yedekten yalıtılmış bir ortama geri yükleyin ve kronometreyi tutun. Geçen süre ve bulduğunuz eksikler, yedekleme stratejinizin gerçek durumunu gösterecektir. Testi birlikte planlamak için iletişim sayfamızdan bize ulaşın. Temel güvenlik önlemlerinin tamamı için KOBİ siber güvenlik kontrol listesi ve Siber Güvenlik ve KVKK sayfamıza göz atabilirsiniz.