Bizi Takip Edin :
Veri Güvenliği

Yedeğiniz Var mı, Geri Yükleyebiliyor musunuz? Restore Testi Rehberi

Sunucu odasında yedekleme kaydını kontrol eden BT uzmanı - Xen Bilişim Veri Güvenliği

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östergeDeğ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 maliyeti8 kat daha yüksek
Ortalama toplam olay maliyeti1,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:

ÖncelikSistem tipiTest sıklığı
YüksekERP/muhasebe veritabanı, e-posta sunucusuÜç ayda bir, tam restore
OrtaDosya sunucusu, CRM, üretim uygulamalarıAltı ayda bir
DüşükArşiv, log, eski proje verisiYı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.

Bu yazıyı paylaşın
Read in English

İlgili Yazılar