Yedekleme Geri Yükleme Testi Nasıl Yapılır? Adım Adım Rehber

Birçok kurumda yedekleme "kuruldu ve çalışıyor" diye düşünülür. Raporda yeşil işaretler görünür, görevler zamanında tamamlanır, kimse alarm almaz. Asıl soru ise ancak bir sunucu bozulduğunda ya da fidye yazılımı dosyaları şifrelediğinde sorulur: Bu yedekten gerçekten geri dönebilir miyiz, ne kadar sürede ve eksiksiz mi? Bu sorunun cevabını olay anında değil, önceden ve düzenli olarak test ederek vermeniz gerekir.

Neden yedek almak tek başına yetmez?

Bir yedekleme görevinin "başarılı" görünmesi, yalnızca verinin bir kopyasının bir yere yazıldığı anlamına gelir. Bu, şu sorulara cevap vermez: dosyalar bozulmadan mı yazıldı, uygulama tutarlı (application-consistent) bir anlık görüntü mü alındı, geri yükleme sırasında lisans/sürücü/ağ ayarları doğru mu geliyor, geri dönüş gerçekten kabul edilebilir bir sürede mi tamamlanıyor? Sorunlar genelde teknik bir "hata" olarak değil, sessizce birikir: eksik izin, dolu disk, güncel olmayan bir ajan, yanlış yapılandırılmış bir politika. Test edilmemiş bir yedek, aslında doğrulanmamış bir varsayımdır.

Geri yükleme testi türleri

Tüm sistemleri her ay uçtan uca test etmek çoğu kurum için pratik değildir. Bunun yerine, kritikliğe göre farklı derinlikte testler uygulanır:

• Dosya düzeyinde geri yükleme testi: Yedekten rastgele seçilen birkaç dosya/klasörün açılıp bütünlüğünün kontrol edilmesi. Hızlı ve sık yapılabilir.
• Tam makine geri yükleme testi (izole ortamda): Bir sunucunun veya iş istasyonunun yedekten üretim dışı, izole bir ortama (sandbox) tam olarak ayağa kaldırılması. Uygulamanın gerçekten açılıp çalıştığının doğrulanmasıdır.
• Anlık kurtarma / sanal makine olarak çalıştırma testi: Acronis gibi çözümlerde yedeğin doğrudan bir sanal makine olarak başlatılıp (instant restore / run as VM) RTO'nun gerçekte ne kadar sürdüğünün ölçülmesi.
• Felaket kurtarma (DR) failover tatbikatı: Birden fazla sistemin birlikte, belirlenmiş bir sırayla, iş sürekliliği senaryosunu simüle edecek şekilde ayağa kaldırılması. Yılda bir veya iki kez, kritik iş uygulamaları için önerilir.

Ne sıklıkla test edilmeli?

Test sıklığı, sistemin kritikliğine ve hedeflenen RTO/RPO değerlerine bağlı olmalıdır. Pratik bir yaklaşım:

• Kritik sistemler (ERP, e-posta, muhasebe, üretim veritabanları): ayda bir dosya/örnek testi, üç ayda bir tam geri yükleme testi.
• Orta öncelikli sistemler: üç ayda bir dosya testi, yılda en az bir tam test.
• Düşük öncelikli/arşiv veriler: yılda bir örnekleme testi yeterli olabilir.

Buradaki belirleyici soru şu olmalı: "Bu sistem şu an çökse, hedeflediğimiz RTO süresinde gerçekten ayağa kalkar mıyız?" Cevap "test etmedik, bilmiyoruz" ise, o sistemin test takvimi gözden geçirilmeli.

Adım adım geri yükleme testi planı

1. Kapsamı belirleyin: Hangi sistem, hangi yedek noktası (tarih/saat) test edilecek, net olarak yazın.
2. İzole bir test ortamı hazırlayın: Geri yükleme asla üretim ağına veya üretim sistemine yazılmamalı; ayrı bir sanal ağ/sandbox kullanın.
3. Geri yüklemeyi başlatın ve süreyi ölçün: Başlangıç ve tamamlanma zamanını kaydedin — bu, gerçek RTO'nuzdur, hedef RTO ile karşılaştırın.
4. Veri bütünlüğünü doğrulayın: Uygulamanın açılıp açılmadığını, kritik dosyaların/tabloların eksiksiz olup olmadığını, son kayıtların tarihini (gerçek RPO) kontrol edin.
5. Erişim ve bağımlılıkları kontrol edin: Kullanıcı girişi, lisans doğrulaması, bağımlı servislerin (veritabanı, API, DNS) doğru çalışıp çalışmadığını test edin.
6. Sonucu kayıt altına alın: Başarılı/başarısız, ölçülen süre, karşılaşılan sorun, düzeltici aksiyon — hepsini yazılı olarak saklayın.
7. Bulguları yedekleme planına yansıtın: Test bir sorun ortaya çıkardıysa (örn. eksik dosya, yetersiz süre), yedekleme politikasını veya altyapıyı güncelleyin ve bir sonraki testte tekrar doğrulayın.

Sık yapılan hatalar

• Testi üretim sistemi üzerinde veya üretim ağına bağlı şekilde yapmak — bu, test amacını riske atar.
• Yalnızca "geri yükleme başladı mı" diye bakıp uygulamanın gerçekten açılıp açılmadığını kontrol etmemek.
• Test sonuçlarını hiçbir yere yazmamak — aynı sorunun bir sonraki testte tekrar keşfedilmesine yol açar.
• Yalnızca en kolay/küçük sistemleri test edip kritik sistemleri hiç test etmemek.
• Testi tek bir kişiye bağlamak — o kişi izinli/ulaşılamaz olduğunda sürecin durması.

Testi nasıl kayıt altına almalısınız?

Her test için en az şunları içeren kısa bir kayıt tutun: test tarihi, test edilen sistem ve yedek noktası, ölçülen gerçek RTO, veri bütünlüğü sonucu, karşılaşılan sorunlar ve alınan aksiyon. Bu kayıtlar hem iç denetim hem de KVKK kapsamındaki veri güvenliği yükümlülükleri açısından değerli bir kanıttır — "yedeğimiz var" demek yerine "yedeğimizi şu tarihte test ettik ve X dakikada geri döndük" diyebilmek, özellikle bir olay sonrası yapılacak değerlendirmede büyük fark yaratır. Düzenli yedekleme raporlarınızı nasıl daha etkili okuyacağınızı yedekleme raporlarını okuma rehberimizde ele almıştık; test kayıtlarını da aynı disiplinle saklamanızı öneririz.

Sık sorulan sorular

Geri yükleme testi ne sıklıkla yapılmalı?

Kritiklik düzeyine göre değişir: kritik sistemlerde ayda bir örnekleme testi ve üç ayda bir tam geri yükleme testi iyi bir başlangıç noktasıdır. Belirleyici soru, hedeflediğiniz RTO/RPO değerlerine gerçekten ulaşıp ulaşmadığınızdır.

Test için üretim sistemini durdurmak gerekir mi?

Hayır, olmamalı. Geri yükleme testleri izole bir test ortamında (sandbox/ayrı sanal ağ) yapılmalı; üretim sistemine veya ağına dokunulmamalıdır. Acronis gibi çözümlerdeki "anlık kurtarma" (instant restore) özellikleri, yedeği üretim sistemini etkilemeden ayrı bir sanal makine olarak başlatmaya izin verir.

Küçük bir işletme için tam bir DR tatbikatı gerekli mi?

Her işletme için şart değil, ama en kritik 1-2 sistem için yılda en az bir kez uçtan uca bir test yapılması önerilir. Diğer sistemler için daha hafif dosya/örnekleme testleri düzenli aralıklarla yeterli olabilir; önemli olan hiçbir sistemin tamamen test dışı kalmamasıdır.