Yedeğiniz Var mı, Geri Yükleyebiliyor musunuz? Restore Testi Rehberi
Sophos’un 2026 tarihli State of Ransomware raporuna 2.158 BT ve güvenlik yöneticisi katıldı, ortak deneyimleri çarpıcı: fidye yazılımı saldırısına uğrayan kurumların yüzde 96’sında saldırgan önce yedeklere yöneliyor, yüzde 76’sında da bu girişim başarılı oluyor. Yani “yedeğimiz var” cümlesi artık güvence değil. Asıl soru şu: kriz anında o yedeği gerçekten geri yükleyebiliyor musunuz?
Biz müşteri ortamlarında hâlâ aynı sahneyi görüyoruz: yedekleme yazılımı yeşil ışık yakıyor, raporlar “başarılı” diyor, ama kimse son altı ayda tam bir restore denemesi yapmamış. İlk gerçek test, sunucu çöktüğü gün oluyor. O zaman da genelde çok geç kalınıyor.
Rakamlar Ne Anlatıyor?
Sophos’un raporundaki tablo, yedeğin varlığıyla işe yaraması arasındaki farkı net gösteriyor:
| Gösterge | Değer |
|---|---|
| Backup’ların hedef alındığı saldırı oranı | %96 |
| Saldırganın backup’ı ele geçirmeyi başarma oranı | %76 |
| Şifrelenmiş veride çalışan yedekle kurtarma oranı | %66 |
| Backup’ı ele geçirilen kurumda kurtarma maliyeti | 8 kat daha yüksek |
| Ortalama toplam olay maliyeti | 1,7 milyon dolar |
Dikkat çeken kısım şu: yedeği sağlam kalan kurumlar bile her zaman sorunsuz kurtarılamıyor; şifrelenmiş veride başarı oranı yüzde 66’da kalıyor. Geri kalan yüzde 34’te yedek var ama restore bir yerde tıkanıyor.
Yedek Neden Geri Yüklenmiyor?
Sahada üç neden tekrar ediyor.
Bozuk yedek zinciri. Saldırgan sisteme aylarca önce sızmış olabilir; o süre boyunca alınan artımlı (incremental) yedekler zaten bozulmuş içerik taşır. Kurtarma anında fark edersiniz, önceden değil.
Silinen anlık görüntüler. Yedekleme konsoluna üretim ortamıyla aynı yönetici kimlik bilgileriyle erişiliyorsa, saldırgan önce oraya girip eski kopyaları siliyor. Ayrı yönetici hesabı ve ayrı ağ segmenti olmayan yedekleme altyapısı, kendi başına bir risktir.
Kabul edilemeyen kurtarma süresi. Yedek teknik olarak sorunsuz geri yüklenebilir ama 40 saat sürer. İşletme üç saatte ayağa kalkması gerektiğini düşünürken, gerçek rakam masaya yatırılmamıştır.
Değişmez (immutable) depolama bu üçünün yalnızca bir kısmını çözer: veriyi silinmeye ve değiştirilmeye karşı korur. Ama restore’un tamamlanacağını, uygulamanın ayağa kalkacağını ya da geri gelen verinin içinde uykuda bir zararlı kalmadığını garanti etmez. Immutable yedek, test edilmemiş yedekten daha güvenlidir — test edilmiş yedeğin yerini tutmaz.
Restore Testi Nasıl Kurulur?
Test programını karmaşıklaştırmaya gerek yok, düzenli ve ölçülebilir olması yeterli.
- İzole bir test ortamında (üretim ağından ayrı) çeyrekte bir tam restore denemesi yapın.
- Kritik sistemleri örnekleyin: e-posta sunucusu, ERP veritabanı, dosya sunucusu — hepsini değil, en can alıcı üçünü.
- Gerçek kurtarma süresini ölçün ve vaat edilen RTO ile karşılaştırın. Fark varsa, önce beklentiyi düzeltin.
- En az bir denemede eski (30+ gün önceki) bir yedeği geri yükleyin; sadece dünkü yedeği test etmek gizli bozulmayı yakalamaz.
- Sonucu yazılı kaydedin, bir sorumlu atayın. Test yapılmayan restore planı, plan değil niyettir.
20 kişilik bir imalat firmasında geçen yıl tam olarak bunu yaşadık: yıllık restore testinde ERP veritabanının üç aylık bir yedeği bozuk çıktı, sorun kaynağı bulundu ve düzeltildi. Test yapılmasaydı, gerçek bir olayda o veritabanı geri gelmeyecekti.
Hangi Sistem Önce Test Edilmeli?
Her sistemi aynı sıklıkta test etmek gereksiz zaman kaybı, hiçbirini test etmemek ise doğrudan risk. Aradaki dengeyi kurmanın en pratik yolu, sistemleri “durursa kaç saatte fark edilir” sorusuna göre sıralamak:
| Öncelik | Sistem tipi | Test sıklığı |
|---|---|---|
| Yüksek | ERP/muhasebe veritabanı, e-posta sunucusu | Üç ayda bir, tam restore |
| Orta | Dosya sunucusu, CRM, üretim uygulamaları | Altı ayda bir |
| Düşük | Arşiv, log, eski proje verisi | Yılda bir, örnekleme |
Küçük bir işletmede bu tabloyu Excel’de tutmak bile yeterli; önemli olan takvimin var olması ve birinin ona bakmasıdır. Biz müşteri ortamlarında bu takvimi bakım anlaşmasının bir parçası olarak izliyoruz, çünkü unutulan test, hiç yapılmamış test ile aynı sonucu verir.
Sık Sorulan Sorular
Restore testi ne sıklıkla yapılmalı? Kritik sistemler için üç ayda bir tam test, diğer sistemler için yılda bir kez asgari düzey. Yedekleme yazılımı veya altyapı değiştiğinde ek bir test şart.
Immutable yedek yeterli mi, ayrıca test gerekir mi? Immutable depolama silinme ve şifrelenme riskini azaltır ama restore’un çalışacağını göstermez. İkisi birbirinin yerine geçmez, birlikte kullanılır.
Testi kendi ekibimiz mi yapmalı, dış sağlayıcı mı? İç ekip günlük operasyonu bilir, dış sağlayıcı bağımsız gözle bakar ve genelde daha fazla senaryo görmüştür. İkisinin birlikte çalıştığı model en sağlıklısı.
Yedekleme stratejinizi gözden geçirmek ve bir restore testi takvimi kurmak isterseniz iletişime geçebilirsiniz.
İlgili Yazılar
Çalışanın Bilgisayarında Yönetici Yetkisi Olmalı mı? Yetkiyi Kaldırma Planı
Kullanıcıların kendi bilgisayarında yerel yönetici olması fidye yazılımının işini kolaylaştırır. Kimin neye ihtiyacı var, geçiş kaç haftada biter?
Devamını Oku: Çalışanın Bilgisayarında Yönetici Yetkisi Olmalı mı? Yetkiyi Kaldırma Planı
Şirket Laptopu Çalınırsa BitLocker Açık mıydı? Nasıl Kontrol Edilir?
Çalınan bir laptopun asıl maliyeti cihaz değil içindeki veri. Diskin şifreli olup olmadığını ve kurtarma anahtarının yerini nasıl kontrol edersiniz?
Devamını Oku: Şirket Laptopu Çalınırsa BitLocker Açık mıydı? Nasıl Kontrol Edilir?
İşten Ayrılan Çalışanın Hesapları ve Erişimleri Nasıl Kapatılır?
Çalışan çıktı ama e-posta, VPN, bulut paneli ve ortak parolalar hâlâ açık mı? Hangi hesap hangi sırayla kapatılır, veri kaybetmeden nasıl devredilir?
Devamını Oku: İşten Ayrılan Çalışanın Hesapları ve Erişimleri Nasıl Kapatılır?