Yedekler Gerçekten Çalışıyor mu? Test ve Doğrulama Rehberi

Yedek aldığınızı bilmek ile yedeklerinizin çalıştığından emin olmak birbirinden tamamen farklı iki durumdur. Hosting forumlarında en sık karşılaşılan feryat şudur: "Yedek alıyordum ama geri yükleyemedim." Bu yazıda yedek almayı değil — aldığınız yedeklerin gerçekten işe yarayıp yaramadığını test etmeyi ele alıyoruz. Hangi dosyaları kontrol edeceğinizi, hangi araçları kullanacağınızı ve ne sıklıkla test yapmanız gerektiğini adım adım öğreneceksiniz.

Neden "Yedek Var" Demek Yetmez

Yedek dosyanızın varlığı, içeriğinin sağlam olduğu anlamına gelmez. Aşağıdaki senaryolar gerçek olaylardan derlendi:

• Disk hatası sırasında yarım kalan bir sıkıştırma işlemi, .tar.gz dosyasının boyutunu korumasına rağmen içeriğini bozar.
• Otomatik MySQL yedekleri, tablo kilitlenmesi sorunundan ötürü eksik tablolarla tamamlanabilir.
• Hosting sağlayıcısının kontrol panelinden alınan snapshot (anlık görüntü), sistemin yazma işlemi sırasındaki tutarsız bir anını yakalayabilir.
• Sıkıştırılmış yedekler uzun süre dokunulmadan beklerken bozulabilir; buna bit rot (bit çürümesi) denir ve soğuk depolama ortamlarında 2-3 yılda kendini gösterir.

Bu nedenle bir yedeğin var olması değil, başarılı biçimde geri yüklenebilmesi tek geçerli başarı kriteridir. Yedek doğrulama sürecini hiç kurmamış biri, yedek almıyor biriyle aynı riskle karşı karşıyadır.

Adım 1: SHA256 Doğrulamasıyla Dosya Bütünlüğünü Kontrol Edin

Yedek dosyasını oluştururken yanına bir sağlama (checksum) dosyası üretin. Bu, dosyanın sonradan bozulup bozulmadığını saniyeler içinde anlamanızı sağlar.

Yedek oluştururken:

tar -czf /backup/site_2026-05-08.tar.gz /var/www/html
sha256sum /backup/site_2026-05-08.tar.gz > /backup/site_2026-05-08.sha256

Sonraki doğrulama sırasında:

sha256sum -c /backup/site_2026-05-08.sha256

Çıktı OK ise dosya bozulmamıştır. FAILED görürseniz yeni bir yedek alın ve depolama ortamını gözden geçirin. Birden fazla yedeği yönetiyorsanız hashdeep aracı klasör bazlı toplu doğrulama yapar:

hashdeep -r /backup/ > /backup/manifest_2026-05-08.txt

Bu manifest dosyasını, yedek klasöründen farklı bir konuma kopyalayın. Yedek klasörüyle birlikte aynı disk bozulursa manifest de kaybolur; o zaman elinizde karşılaştırılacak referans kalmaz.

Adım 2: Kısmi Dosya Geri Yükleme Testi

Tam sistem geri yüklemesi zaman alır; haftalık doğrulama için kısmi test yeterlidir. Fikir basittir: yedekten rastgele birkaç dosya çıkarın, orijinaliyle karşılaştırın.

# Yedekten tek bir dosya çıkar
tar -xzf /backup/site_2026-05-08.tar.gz \
  var/www/html/wp-config.php \
  -C /tmp/restore_test/

# Orijinalle karşılaştır
diff /tmp/restore_test/var/www/html/wp-config.php \
  /var/www/html/wp-config.php

diff çıktısı boşsa dosyalar özdeştir. Fark varsa nedenini araştırın: yedek alındıktan sonra dosya değişmiş olabilir — bu normaldir. Ama yedek anındaki sürüm bile hatalıysa sorun yedek mekanizmasındadır.

WordPress siteleri için pratik kontrol listesi:

Adım 3: Veritabanı Yedeğini Gerçek Veriye Karşı Doğrulayın

MySQL ya da MariaDB yedeklerini doğrulamak için en güvenilir yöntem, yedeği ayrı bir veritabanına geri yüklemek ve tablo ile satır sayılarını canlı veriyle karşılaştırmaktır.

# Test veritabanı oluştur
mysql -u root -p -e "CREATE DATABASE backup_test_db;"

# Yedeği geri yükle
mysql -u root -p backup_test_db < /backup/mysite_db_2026-05-08.sql

# Tablo sayısını karşılaştır
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables
  WHERE table_schema='mysite_db';"
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables
  WHERE table_schema='backup_test_db';"

Sayılar eşit olmalı. Ardından en kritik tablonuzun satır sayısını karşılaştırın:

mysql -u root -p -e "SELECT COUNT(*) FROM mysite_db.wp_posts;"
mysql -u root -p -e "SELECT COUNT(*) FROM backup_test_db.wp_posts;"

Testten sonra geçici veritabanını silin:

mysql -u root -p -e "DROP DATABASE backup_test_db;"

Kritik not: --single-transaction bayrağı olmadan alınan MySQL yedekleri, aktif yazma işlemi sırasında tutarsız olabilir. Yedek scriptinizde bu bayrağın varlığını kontrol edin:

mysqldump --single-transaction --routines --triggers \
  -u root -p mysite_db > /backup/mysite_db_2026-05-08.sql

Bu bayrak olmadan alınan yedeklerde tablo sayısı eşleşse bile satır sayısında kayıp olabilir.

Adım 4: Tam Sistem Geri Yükleme Tatbikatı

Kısmi testler günlük güveni sağlar; ancak gerçek felaket kurtarma (disaster recovery) tatbikatı yılda en az iki kez yapılmalıdır. Üretim sunucusuna dokunmadan ayrı bir ortamda tam geri yükleme gerçekleştirirsiniz.

Hızlı tatbikat için Docker yalıtılmış bir ortam sunar:

# Boş bir Ubuntu konteyneri başlat
docker run -it --name dr_test ubuntu:22.04 /bin/bash

# İçinde LAMP/LEMP kurun, yedeği geri yükleyin
# ve uygulamanın ayağa kalkıp kalkmadığını test edin

VDS veya bulut sunucu kullanıyorsanız sağlayıcının anlık snapshot özelliğiyle test amaçlı bir kopya oluşturup test sonrası silebilirsiniz.

Tatbikat sırasında ölçmeniz gereken iki kritik değer:

Örneğin 4 saatte bir yedek alıyorsanız RPO'nuz 4 saattir; tam geri yükleme 3 saat sürüyorsa RTO'nuz 3 saattir. Bu değerleri tatbikat sonrasında belgeleyin. Bir sonraki tatbikata kadar iyileştirme hedefiniz olsun.

Adım 5: Otomatik Doğrulama Scripti Kurun

Manuel testler unutulur. Aşağıdaki script, her sabah yedek bütünlüğünü otomatik kontrol eder ve sonucu log dosyasına yazar.

#!/bin/bash
BACKUP_DIR="/backup"
LOG="/var/log/backup_verify.log"
DATE=$(date +%Y-%m-%d)
BACKUP_FILE="$BACKUP_DIR/site_$DATE.tar.gz"

echo "[$DATE] Dogrulama basladi" >> $LOG

if [ ! -f "$BACKUP_FILE" ]; then
    echo "[$DATE] HATA: Yedek dosyasi bulunamadi" >> $LOG
    exit 1
fi

if sha256sum -c "$BACKUP_DIR/site_$DATE.sha256" >> $LOG 2>&1; then
    echo "[$DATE] BASARILI: SHA256 dogrulamasi gecti" >> $LOG
else
    echo "[$DATE] HATA: SHA256 dogrulamasi basarisiz" >> $LOG
    echo "Yedek dogrulama hatasi: $DATE" | \
      mail -s "KRITIK: Yedek Bozuk" [email protected]
fi

Bu scripti cron ile her sabah 07:00'de çalıştırın:

crontab -e
# Eklenecek satir:
0 7 * * * /usr/local/bin/verify_backup.sh

E-posta bildirimi için mailutils paketi ve sistemde yapılandırılmış bir SMTP yeterlidir. Script başarısız olduğunda bildirimi siz arayana kadar beklemeyin — otomasyon sizi bulsun.

Test Takvimi: Ne Sıklıkla, Neyi Test Etmeli?

Son satıra özellikle dikkat edin: eski yedeklerden dosya çekmeyi test etmek çoğunlukla atlanır. Bir kullanıcı "60 gün önceki siteye dönmem lazım" dediğinde o arşivin hâlâ erişilebilir ve bütün olması gerekir. Arşiv yedekleri bazen farklı bir depolama katmanına taşınır ve bu süreçte sessizce bozulabilir.

Sonuç

Yedek doğrulama, bir kere kurup unutulan bir sistem değil; düzenli tekrar gerektiren bir alışkanlıktır. Bugün şu üç adımla başlayın: mevcut yedeğiniz için bir SHA256 sağlaması oluşturun, veritabanı yedeğinizi ayrı bir veritabanına geri yükleyip tablo sayısını karşılaştırın ve takvime 6 aylık tam tatbikat için somut bir tarih ekleyin. Bu üç adım, yedekleriniz hakkında "sanırım çalışır" yerine "test ettim, çalışıyor" demenizi sağlar — ve bu fark, kriz anında her şeyi değiştirir.