Rsync ile Yedekleme Doğrulama: Checksum Kontrolü

Tarafındankomut
0 Comments

Yedekleme almak bir alışkanlık, ama yedeklemenin doğru çalıştığını kontrol etmek ayrı bir disiplin gerektirir. Onlarca sistem yöneticisiyle konuştuğumda hep aynı şeyi duyuyorum: “Yedek alıyorum ama hiç restore denemedim.” İşte tam burada checksum doğrulama devreye giriyor. Rsync’in checksum özelliklerini kullanarak sadece dosyaları kopyalamakla kalmıyor, her byte’ın eksiksiz aktarıldığını matematiksel olarak ispatlayabiliyorsunuz.

Rsync Neden Sadece Kopyalamaktan Fazlasını Yapar

Rsync varsayılan davranışında oldukça akıllıca çalışır. Dosyaların boyutuna ve son değiştirilme zamanına (mtime) bakarak hangi dosyaların değiştiğine karar verir. Bu yaklaşım çoğu durumda yeterli ve hızlıdır. Ama burada gizli bir sorun yatıyor: bit rot denen fenomen.

Bit rot, özellikle uzun süre erişilmeyen disklerde veya uzun mesafeli ağ transferlerinde ortaya çıkan veri bozulmalarıdır. Dosyanın mtime’ı aynı kalır, boyutu aynı görünür, ama içindeki birkaç byte bozulmuştur. Rsync bunu standart modda fark etmez. Kaynak ve hedefteki bu bozuk dosyalar “aynı” olarak işaretlenir ve üzerine yazılmaz.

İşte burada --checksum bayrağı hayat kurtarıcı olur.

Checksum Nasıl Çalışır

Rsync checksum modunda çalıştırıldığında her dosya için MD5 veya xxHash gibi bir özet değeri hesaplar. Kaynak ve hedef dosyaların bu özetleri karşılaştırılır. Özetler eşleşmiyorsa dosya yeniden transfer edilir. Bu işlem dosya boyutundan ve tarihten bağımsız çalışır.

# Temel checksum ile yedekleme
rsync -av --checksum /kaynak/dizin/ /hedef/dizin/

Buradaki -a arşiv modunu, -v verbose çıktıyı, --checksum ise checksum tabanlı karşılaştırmayı aktif eder. Peki bu komutun çıktısında ne görürsünüz?

# Örnek çıktı
sending incremental file list
./
belgeler/
belgeler/rapor.pdf
belgeler/sunum.pptx
config/
config/nginx.conf

sent 14,523,847 bytes  received 342 bytes  1,234,567.23 bytes/sec
total size is 2,847,234,123  speedup is 195.98

Checksum eşleşmeyen dosyalar otomatik olarak yeniden gönderilir. Logda bu dosyaları görmek, sisteminizdeki sessiz veri bozulmalarının ilk uyarısı olabilir.

Uzak Sunucuya Checksum ile Yedekleme

Gerçek dünyada çoğu zaman yerel diskten uzak sunucuya yedek alırsınız. SSH üzerinden checksum doğrulamalı yedekleme şöyle görünür:

# SSH üzerinden checksum ile uzak yedekleme
rsync -avz --checksum 
  --delete 
  --backup --backup-dir=/yedek/arsiv/$(date +%Y%m%d) 
  -e "ssh -p 22 -i /root/.ssh/yedek_key" 
  /var/www/html/ 
  [email protected]:/yedekler/web/

Bu komutta kullanılan parametrelerin ne işe yaradığına bakalım:

  • -a: Arşiv modu, sembolik linkler, izinler, timestamps ve ownership korunur
  • -v: Verbose, hangi dosyaların transfer edildiğini gösterir
  • -z: Sıkıştırma, ağ üzerinden transfer hızını artırır
  • –checksum: MD5/xxHash ile dosya bütünlüğü doğrulaması
  • –delete: Kaynakta silinmiş dosyaları hedefteki yedekten de siler
  • –backup: Üzerine yazılacak dosyaların eski versiyonunu saklar
  • –backup-dir: Yedeklerin tarih bazlı klasöre taşınacağı dizin
  • -e: SSH bağlantısı için özel anahtar ve port ayarı

Checksum ile Yedek Doğrulama Scripti

Yedekleme sonrasında otomatik doğrulama yapmak için elimdeki en sağlam yöntemlerden biri olan bu scripti production ortamlarımda kullanıyorum:

#!/bin/bash
# rsync_verify.sh - Yedek doğrulama scripti

KAYNAK="/var/www/html"
HEDEF="/mnt/yedek/web"
LOG_DOSYA="/var/log/yedek_dogrulama.log"
HATA_SAYACI=0

echo "=== Yedek Doğrulama Başladı: $(date) ===" | tee -a $LOG_DOSYA

# Önce normal yedekleme
rsync -a --checksum --stats 
  "$KAYNAK/" "$HEDEF/" 2>&1 | tee -a $LOG_DOSYA

RSYNC_CIKIS=$?

if [ $RSYNC_CIKIS -ne 0 ]; then
  echo "HATA: Rsync başarısız oldu. Çıkış kodu: $RSYNC_CIKIS" | tee -a $LOG_DOSYA
  exit 1
fi

# Doğrulama aşaması: Sadece checksum karşılaştırması
echo "=== Doğrulama Aşaması Başladı ===" | tee -a $LOG_DOSYA

DOGRULAMA=$(rsync -av --checksum --dry-run 
  "$KAYNAK/" "$HEDEF/" 2>&1)

FARK_SAYISI=$(echo "$DOGRULAMA" | grep -v "^sending|^sent|^total|^$|./|/$" | wc -l)

if [ $FARK_SAYISI -gt 0 ]; then
  echo "UYARI: $FARK_SAYISI dosya hala farklı görünüyor!" | tee -a $LOG_DOSYA
  echo "$DOGRULAMA" | tee -a $LOG_DOSYA
  HATA_SAYACI=$((HATA_SAYACI + 1))
else
  echo "BAŞARILI: Tüm dosyalar doğrulandı." | tee -a $LOG_DOSYA
fi

echo "=== Doğrulama Tamamlandı: $(date) ===" | tee -a $LOG_DOSYA
exit $HATA_SAYACI

Bu scriptin en kritik kısmı --dry-run ile yapılan ikinci tarama. Yedekleme tamamlandıktan sonra “eğer şimdi tekrar çalıştırsaydım ne değişirdi?” sorusunu sormak, yedeklemenin gerçekten başarılı olduğunu kanıtlar. Hiçbir şey değişmeyecekse yedek doğrudur.

Büyük Dosya Sistemleri için Paralel Checksum Doğrulama

Yüzlerce gigabyte veya terabyte büyüklüğündeki yedeklerde tek bir rsync process ile checksum yapmak saatler alabilir. Bu durumda GNU Parallel ile işi paralele taşıyabilirsiniz:

#!/bin/bash
# parallel_checksum.sh - Büyük yedekler için paralel doğrulama

HEDEF_DIZIN="/mnt/yedek"
IS_SAYISI=4  # Paralel iş sayısı

# Hedef dizindeki her alt dizin için ayrı checksum
find "$HEDEF_DIZIN" -maxdepth 1 -mindepth 1 -type d | 
  parallel -j $IS_SAYISI 
  "echo 'Doğrulanıyor: {}' && 
   find '{}' -type f -exec md5sum {} ; >> /tmp/checksum_{/.}.txt 2>&1 && 
   echo 'Tamamlandı: {}'"

echo "Tüm checksum dosyaları /tmp/ dizininde oluşturuldu."
ls -la /tmp/checksum_*.txt

Peki bu checksum dosyalarını nasıl kullanırsınız? Şöyle bir senaryo düşünün: Aylık tam yedekten sonra bu checksum listesini saklamak ve bir dahaki doğrulamada karşılaştırmak için kullanmak.

# Mevcut durumun checksum özetini al
find /mnt/yedek/web -type f | sort | 
  xargs md5sum 2>/dev/null > /var/log/yedek_checksum_$(date +%Y%m%d).txt

# Önceki hafta ile karşılaştır
diff /var/log/yedek_checksum_$(date -d 'last week' +%Y%m%d).txt 
     /var/log/yedek_checksum_$(date +%Y%m%d).txt | 
  grep "^[<>]" | head -50

Gerçek Dünya Senaryosu: E-Ticaret Sitesi Felaket Kurtarma Testi

Geçen yıl bir e-ticaret şirketinde danışmanlık yaparken şöyle bir durumla karşılaştım. Günlük rsync yedeklemeleri aylar boyunca sorunsuz görünüyordu. Ama checksum doğrulaması eklediğimizde ilginç bir şeyle karşılaştık: Upload klasöründeki ürün resimlerinin yaklaşık 0.3%’i hedefteki yedekte bozulmuştu. Bu oran küçük görünse de 50.000 ürün fotoğrafında 150 bozuk görsel demekti.

Sorunun kaynağı ağ geçişindeki bir MTU uyumsuzluğuydu. Rsync standart modda bunu fark etmemişti çünkü dosya boyutları aynıydı. Checksum eklediğimizde sorun hemen gün yüzüne çıktı.

Bu senaryo için kullandığımız üretim yedekleme scriptini paylaşıyorum:

#!/bin/bash
# eticaret_yedek.sh - Üretim e-ticaret yedekleme scripti

set -euo pipefail

# Konfigürasyon
KAYNAK_SUNUCU="web01.sirket.com"
YEDEK_SUNUCU="backup01.sirket.com"
KAYNAK_DIZIN="/var/www/eticaret"
YEDEK_DIZIN="/yedekler/eticaret"
SSH_KEY="/root/.ssh/backup_rsa"
LOG="/var/log/eticaret_yedek/$(date +%Y%m%d_%H%M%S).log"
EMAIL="[email protected]"
CHECKSUM_DB="/var/log/eticaret_yedek/checksum_db.txt"

mkdir -p "$(dirname $LOG)"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG"
}

hata_gonder() {
  local MESAJ="$1"
  log "KRİTİK HATA: $MESAJ"
  mail -s "[ALARM] Yedekleme Hatası - $(date +%Y%m%d)" 
    "$EMAIL" < "$LOG" 2>/dev/null || true
}

# Aşama 1: Checksum ile yedekleme
log "Yedekleme başlıyor..."

rsync -avz 
  --checksum 
  --delete 
  --stats 
  --log-file="$LOG" 
  -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=no" 
  "${KAYNAK_SUNUCU}:${KAYNAK_DIZIN}/" 
  "${YEDEK_DIZIN}/guncel/" || {
    hata_gonder "Rsync transfer başarısız"
    exit 1
  }

# Aşama 2: Kritik dosyalar için checksum doğrulama
log "Kritik dosyalar için checksum doğrulaması yapılıyor..."

ssh -i "$SSH_KEY" "$KAYNAK_SUNUCU" 
  "find ${KAYNAK_DIZIN}/uploads -type f -newer /tmp/.son_yedek_zamani 
   -exec md5sum {} ;" > /tmp/kaynak_checksum.txt 2>/dev/null

find "${YEDEK_DIZIN}/guncel/uploads" -type f 
  -exec md5sum {} ; | 
  sed "s|${YEDEK_DIZIN}/guncel||" | sort > /tmp/hedef_checksum.txt

KAYNAK_COUNT=$(wc -l < /tmp/kaynak_checksum.txt)
HEDEF_COUNT=$(wc -l < /tmp/hedef_checksum.txt)

log "Kaynak dosya sayısı: $KAYNAK_COUNT"
log "Hedef dosya sayısı: $HEDEF_COUNT"

if [ "$KAYNAK_COUNT" -ne "$HEDEF_COUNT" ]; then
  hata_gonder "Dosya sayısı uyuşmazlığı! Kaynak: $KAYNAK_COUNT, Hedef: $HEDEF_COUNT"
fi

# Touch: bir sonraki run için zaman damgası
touch /tmp/.son_yedek_zamani

log "Yedekleme ve doğrulama başarıyla tamamlandı."

–checksum-seed Parametresi ile Deterministik Doğrulama

Checksum doğrulamada az bilinen ama çok işe yarayan bir parametre daha var: --checksum-seed. Bu parametre, checksum hesaplamasında kullanılan seed değerini sabitlemenizi sağlar. Birden fazla rsync işleminin tutarlı checksum değerleri üretmesi gerektiğinde veya delta transfer algoritmalarını daha öngörülebilir yapmak istediğinizde kullanışlıdır.

# Checksum seed ile deterministik yedekleme
rsync -av --checksum --checksum-seed=12345 
  /kaynak/ [email protected]:/hedef/

# Aynı seed ile doğrulama (tutarsız checksum üretimini önler)
rsync -av --checksum --checksum-seed=12345 --dry-run 
  /kaynak/ [email protected]:/hedef/

Bu yöntemi özellikle çoklu datacenter replikasyonunda kullanıyorum. Her iki tarafta da aynı seed ile checksum üretince karşılaştırma tutarlı hale geliyor.

Checksum Doğrulamanın Maliyeti ve Optimizasyon

Checksum’ın büyük bir dezavantajı var: her dosyayı okumak zorunda. Standart rsync stat() çağrısıyla metadata kontrolü yaparken, checksum modu her dosyayı baştan sona okuyup özet hesaplar. Bu, özellikle büyük arşivlerde ciddi I/O yükü yaratır.

Bu maliyeti optimize etmek için birkaç strateji var:

  • Kısmi checksum doğrulama: Sadece kritik dizinler için checksum kullanın, büyük medya arşivleri için standart modu bırakın
  • Scheduling: Checksum doğrulamayı düşük trafikli saatlere alın (gece 02.00-05.00 gibi)
  • Sıklık azaltma: Her gece normal rsync, haftada bir checksum doğrulama
  • ionice ile I/O önceliklendirme: Checksum’ı düşük I/O önceliğiyle çalıştırın
# Düşük öncelikli checksum doğrulama (sistem etkilenmez)
ionice -c 3 nice -n 19 rsync -av --checksum 
  --bwlimit=10000 
  /kaynak/ /hedef/ 
  2>&1 | tee /var/log/checksum_dogrulama.log
  • -c 3: I/O scheduling class “idle”, sistem boşta olduğunda çalışır
  • nice -n 19: CPU önceliği en düşük seviye
  • –bwlimit=10000: Saniyede 10MB ile bant genişliği sınırlama (kilobyte cinsinden)

Cron ile Otomatik Checksum Doğrulama

Tüm bu scriptleri bir araya getirip otomatize etmek için crontab düzenlemesi:

# /etc/cron.d/rsync-yedek dosyası

# Her gece 01:00'da normal yedekleme
0 1 * * * root /usr/local/bin/rsync_yedek.sh >> /var/log/yedek.log 2>&1

# Her Pazar 03:00'da checksum doğrulama
0 3 * * 0 root /usr/local/bin/rsync_verify.sh >> /var/log/yedek_dogrulama.log 2>&1

# Her ayın 1'inde tam checksum veritabanı oluşturma
0 4 1 * * root find /mnt/yedek -type f | sort | xargs md5sum > /var/log/checksum_$(date +%Y%m).txt 2>&1

Sistemrc veya systemd timer kullanıyorsanız daha modern bir yaklaşım için:

# /etc/systemd/system/rsync-checksum.service
[Unit]
Description=Rsync Checksum Doğrulama
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/rsync_verify.sh
StandardOutput=journal
StandardError=journal
User=root

# /etc/systemd/system/rsync-checksum.timer
[Unit]
Description=Haftalık Rsync Checksum Doğrulama

[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target
# Timer'ı etkinleştir
systemctl enable rsync-checksum.timer
systemctl start rsync-checksum.timer
systemctl list-timers | grep rsync

Sonuç

Rsync checksum doğrulaması, yedekleme stratejinizin kör noktasını ortadan kaldıran bir güvenlik ağıdır. Sadece “dosyaların aktarıldığını” değil, “doğru aktarıldığını” kanıtlar. Özellikle bit rot riski taşıyan uzun vadeli arşivlerde, yüksek trafikli ağ transferlerinde ve düzenleyici uyumluluk gerektiren sistemlerde bu fark hayati önem taşır.

Şu pratik yaklaşımı öneriyorum: Günlük yedeklemelerde standart rsync modunu kullanın, hız ve verimlilik açısından bu yeterlidir. Haftada bir --checksum ile doğrulama yapın. Ayda bir de tam checksum veritabanı oluşturun ve arşivleyin. Bu üç katmanlı yaklaşım hem performans hem de güvenilirlik açısından dengeli bir çözüm sunar.

En önemli nokta şu: Doğrulanmamış yedek, yedek değildir. Checksum sadece teknik bir detay değil, felaket kurtarma planınızın olmazsa olmaz bir parçasıdır. Yarın sabah production ortamınızı restore etmeniz gerektiğinde, checksum doğrulamasına zaman ayırmış olmanın değerini anlayacaksınız.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir