Yedeklerin Gerçekten Çalıştığını Test Etme Rehberi (Net Plan)

Yedek (backup) aldığınızı görmek ile yedeğin gerçekten geri yüklenebilir olması aynı şey değildir. Gün gelir disk bozulur, yanlış dosya silinir ya da güncelleme sonrasında site boşa düşer; o an yedek “işe yarıyor mu?” sorusu belirleyici olur. Bu rehberde, otomatik yedeklerinizi restore testi ile kanıtlayacağınız, ölçümlerinizi net tutacağınız ve aynı zamanda operasyonel riski azaltacağınız bir plan bulacaksınız. Hedef: Yedekleriniz “kontrol edildi” demekten çıkıp, gerçekten çalıştığını kanıtlayan bir sürece dönüşsün.

Neyi test etmelisiniz? (Yedek kalitesi checklist)

Yedek testi, tek bir kontrolle tamamlanmaz. Çünkü farklı katmanlar farklı şekillerde “başarısız” olur: Dosya sistemi bozuk olabilir, veritabanı şeması uymayabilir, şifreler veya erişim anahtarları eksik olabilir, geri dönüş süresi beklenenden uzun olabilir.

Aşağıdaki katmanları test edin:

• Dosya geri yükleme (file restore): Web kök dizinleri, eklentiler, yüklenen medya.
• Veritabanı geri yükleme (database restore): MySQL/MariaDB veya PostgreSQL dump/replica mantığı.
• Uygulama bütünlüğü: WordPress/WooCommerce ayarları, config dosyaları, environment değişkenleri.
• Erişim/kimlik bilgisi: DB kullanıcı adı, parola, SSH anahtarı, kontrol paneli (Plesk/cPanel) erişimi.
• Planlanan zaman penceresi: Restore işlemi ne kadar sürüyor ve uygulama ayağa kalkıyor mu?
• İşlevsel test: Site sayfaları, admin paneli, ödeme akışı gibi kritik akışlar.

Basit bir karar kuralı

Aşağıdaki üç soruya “evet” diyemiyorsanız test türünüz eksiktir: 1) Yedek dosyası/katmanı geri yüklenince uygulama çalışıyor mu? 2) Geri dönüş süresi (RTO) hedefinizle uyumlu mu? 3) Geri dönüşten sonra veriler tutarlı mı? (ör. siparişler, kullanıcı oturumları, son güncelleme)

Restore testi tasarımı: Test ortamı ve yöntem

“Yedeği geri yükleyip canlıya zarar vermemek” için test yöntemini baştan seçmelisiniz. En doğru yöntem, kullandığınız altyapıya göre değişir.

1) İzole test ortamı (en güvenlisi)

Bu yöntemde restore işlemi, prod (canlı) verileri etkilemeden ayrı bir ortamda yapılır: - Aynı sağlayıcı üzerinde ayrı VDS/VPS veya test altsunucusu - Aynı ağda ama farklı domain/subdomain (ör. staging-ornek.com) - Gerekirse IP allowlist ve güvenlik duvarı (firewall) ile kısıtlama

Ne kazanırsınız? - Canlı site etkilenmez. - Test sonuçları tekrar üretilebilir olur.

2) Staging klonu (kontrol paneli olanlar için pratik)

Plesk/cPanel gibi kontrol panellerinde bazı yedekler tek tıkla staging alanına taşınabilir. Buradaki kritik nokta: Bu özelliklerin “gerçek restore” yaptığını doğrulamak.

Net doğrulama adımı: - Restore sonrası uygulama loglarında hata var mı? - Web erişimi çalışıyor mu? - Veritabanı sorguları beklenen veriyi dönüyor mu?

3) “Yedek dosyasını açma” testi (yetersiz, sadece ön kontrol)

Bazı ekipler arşivi açtığını görür; bu ön kontrol olabilir ama restore testi değildir. Yedek dosyası bozulmuş veya veritabanı dump’i eksik olabilir.

Uygulama senaryolarına göre test yaklaşımı

Aşağıdaki tabloda, en yaygın sistemler için hangi testleri standartlaştırmanız gerektiğini görebilirsiniz.

Hangi sıklıkla test?

Net bir plan önerisi: - Aylık: Restore testi (en az 1 tam senaryo) - Haftalık: Dosya bütünlük kontrolü (checksum/size karşılaştırma) - Her değişiklikten sonra: Büyük güncelleme, DB şeması değişimi, eklenti güncellemesi gibi durumlarda hızlı doğrulama

Adım adım restore testi: Net prosedür

Bu bölüm, “yarın deneyeceğim” düşüncesini ortadan kaldırmak için uygulanabilir bir prosedür sunar.

1) Test hedeflerini netleştirin (RTO/RPO)

• RTO (Recovery Time Objective): Siteyi kaç dakika/saat içinde geri getirmek istiyorsunuz?
• RPO (Recovery Point Objective): En fazla kaç saat/gün veri kaybını tolere edersiniz?

Yedek testinde asıl amaç, yedeğin çalıştığını kanıtlamak kadar bu değerlerle uyumu ölçmektir.

2) Yedekten geri yükleme planını oluşturun

• Hangi yedek seti test edilecek? (örn. her ayın 1’i gece 01:00)
• Hangi ortamda restore yapılacak? (test VDS/alt domain)
• Kim neyi yapacak? (rol bazlı görevler)
• Nereden raporlanacak? (log ve kısa rapor)

3) Restore işlemini başlatın ve süreyi ölçün

Net ölçüm için tek bir kişi aynı metrikleri kullansın: - Restore başlangıç zamanı (UTC önerilir) - Dosya restore süresi - DB restore süresi - Uygulama ayağa kalkma süresi - İlk başarılı HTTP(S) yanıtı

4) Dosya ve DB tutarlılığını doğrulayın

Restore sonrası “sayfa açıldı” bile bazen yanıltır. Bu yüzden aşağıdaki kontrolleri uygulayın:

• Dosyalar: wp-content/uploads altında beklenen dosyalar var mı?
• Konfig: wp-config.php veya uygulama config’inde doğru DB bilgileri var mı?
• Veritabanı: Basit doğrulama sorguları ile tablo sayıları ve kritik kayıtlar kontrol edin.

Örnek (WordPress mantığı, tablo adları farklı olabilir): - wp_posts içinde son yayınlanan içeriğin varlığı - wp_options içinde temel ayarların güncelliği - WooCommerce için sipariş tablosunda son siparişin görünmesi

5) İşlevsel test senaryoları (en az 5 adım)

Uygulamanın türüne göre değişir; hedef “site statik olarak açıldı” değil, kritik akışlar çalışıyor mu?

Örnek 5 adımlık çekirdek set: 1) Anasayfa ve en az 1 içerik sayfası yükleniyor mu? 2) Form/arama gibi kullanıcı etkileşimi çalışıyor mu? 3) Giriş (admin veya kullanıcı) başarılı mı? 4) Önbellek/parçalı sayfa davranışı normal mi? 5) Hata loglarında (error log / application log) kritik mesaj var mı?

6) Güvenlik kontrolü: Test ortamı prod’a benzer mi?

Restore sırasında özellikle şu riskleri kapatın: - Test ortamında prod şifreleri çalışıyor mu? Çalışıyorsa test bitince erişimi kapatın. - Testte firewall/allowlist var mı? - Admin paneli yalnızca ilgili IP’lerden erişilebilir mi?

Yedek testi raporu: Her seferinde aynı format

Yedek testlerini “denedim oldu”dan çıkarıp kalıcı bir kalite sistemine dönüştürün. Her testten sonra kısa bir rapor çıkarın.

Rapor şablonu (kopyalayıp doldurun): - Test tarihi/saat: - Test edilen yedek seti (etiket/konum): - Ortam (test VDS/VPS): - Restore başlangıç/bitiş: - Dosya restore süresi: - DB restore süresi: - Uygulama ayağa kalkma süresi: - Başarılı endpoint listesi (örn. /, /wp-login.php, checkout): - Loglarda kritik hata var mı? (E/H) - RTO/RPO hedefiyle uyum: - Aksiyonlar (bir sonraki iyileştirme):

Bu raporlar, sağlayıcı değişimi veya mimari güncelleme yapacağınızda doğrudan karar girdisi olur.

Ortak sorunlar: Testte en sık görülen başarısızlıklar

Yedek testlerinde tekrarlayan problemlerin çoğu “yedekleme ayarı doğru ama restore hatalı” kategorisindedir.

• Yedek şifreli ama anahtar yok: Restore edilebiliyor sanılır, sonra erişim engeli çıkar.
• DB dump uyumsuzluğu: Sürüm farkları (ör. MySQL sürümü) restore sırasında hata verir.
• Dosya restore eksik geliyor: Yalnızca belirli dizinler yedeklenir, tema/eklenti veya config kaçırılır.
• Config çevresel fark: Test ortamında aynı environment değişkenleri yoktur.
• Zaman damgası/rotasyon hatası: Beklenen tarihli yedek aslında farklı bir saate denk gelir.

Bu nedenle kontrol listesinde “restore edilebilirlik + işlevsel test” birlikte bulunmalı.

Otomasyon: Testi sürdürülebilir hale getirme

Her şeyi manuel yapmak ilk ayda hızlıdır ama uzun vadede sürdürülebilir değildir. Testleri otomasyona yaklaştırın:

• Yedek rotasyon etiketleri standart olsun (örn. backup-YYYY-MM-DD-HHMM)
• Restore işlemi için adım adım script veya prosedür dokümante edilsin
• Test sonrası otomatik doğrulama (health check):
• HTTP(S) status kodu
• belirli bir sayfada beklenen içerik var mı
• DB bağlantısı başarılı mı

Sağlayıcı yedekleri için net kontrol

Otomatik yedek servisleri için şu sorulara net cevap alın: - Yedekler restore edilebilir formatta mı? - Test ortamı kurulduğunda aynı restore yolu kullanılabiliyor mu? - Restore işlemi kaç dakika sürüyor (en azından pratik bir ölçüm var mı)? - Yedekler hangi bölgede saklanıyor ve erişim nasıl sağlanıyor?

NetKıyas yaklaşımı: Seçim yapmadan önce test gereksinimi

Yedek testini iyi yapan ekip, aslında doğru altyapıyı da daha hızlı seçer. Çünkü doğru altyapı; restore süresini, erişilebilirliği ve yedek yönetiminin kontrolünü kolaylaştırır.

Test için altyapınızda bulunması gereken net özellikler: - Yedekleme politikası (ne sıklıkla, hangi bileşenler) - Restore için erişim (dosya/DB geri yükleme adımları) - Yeterli depolama alanı (yedekleri saklamak için) - Loglara erişim (restore sonrası hatayı bulmak için) - Uygulama uyumlu ortam (PHP/DB sürümü farkları)

Sonuç: İlk aksiyonunuz restore provası olsun

Yedeklerinizin çalıştığını test etmek, “yedek var” güvenini “kanıtlanmış geri dönüş”e çevirir. Bugün atılacak net aksiyon: En son yedek setinizi alıp izole bir test ortamında restore edin, RTO/RPO’yu ölçün ve en az 5 işlevsel kontrolü tamamlayın. Bu çıktıları aynı formatta sakladığınızda, bir sonraki arıza senaryosunda karar süreci hızlanır ve gerçek geri dönüş planınız hazır olur.