Sağlayıcı snapshot'ları kullanışlı ama yeterli değil — sağlayıcıda kesinti olursa VPS ve snapshot'lara erişim kaybolur. Offsite yedekler bunu çözer. Managed offsite için Hostiger Backup-as-a-Service.
1. Yedek hedefi
- Farklı bölgede başka Hostiger VPS ($15/ay)
- Hetzner storage box (~€3/ay 1 TB)
- rclone ile S3 uyumlu bucket
2. SSH key
ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N ""
ssh-copy-id -i /root/.ssh/backup_key.pub backup@backup-host
3. Yedek scripti
/usr/local/bin/backup.sh:
#!/bin/bash
set -euo pipefail
SRC="/etc /home /var/www /var/lib/mysql-backup /root"
DEST="backup@backup-host:/backups/$(hostname)"
DATE=$(date +%Y-%m-%d)
KEY="/root/.ssh/backup_key"
mkdir -p /var/lib/mysql-backup
mysqldump --all-databases --single-transaction > /var/lib/mysql-backup/all.sql
rsync -aAXH --delete \
--link-dest="/backups/$(hostname)/latest" \
-e "ssh -i $KEY" \
$SRC "$DEST/$DATE"
ssh -i $KEY backup@backup-host "ln -sfn /backups/$(hostname)/$DATE /backups/$(hostname)/latest"
4. cron
# Her gün 03:15
15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
5. Retention — 7 günlük / 4 haftalık / 12 aylık
Hedef sunucuda cron ile eski snapshotları temizleyen script — haftalık ve aylık ilk snapshotları koru.
6. Şifreleme (opsiyonel)
tar czf - $SRC | gpg --symmetric --cipher-algo AES256 --batch --passphrase-file /root/.pass \
| ssh backup@backup-host "cat > /backups/$(hostname)/$DATE.tar.gz.gpg"
7. RESTORE'U TEST ET (en atlanan adım)
Test edilmemiş yedek yedek değildir. Ayda bir tek dosya restore edin:
rsync -av backup@host:/backups/.../var/www/site/index.html /tmp/test.html
diff /var/www/site/index.html /tmp/test.html
Üç ayda bir: yedekten spare VPS üzerine tam sistem restore. Gerçek olayda 3 saatte restore öğrenmek kötü zaman.
Ne yanlış gidebilir?
- MySQL dump kaynakta disk taşırır — dump öncesi
df -hkontrolü ekleyin - Hedef disk dolar — retention scripti gerçekten çalışmalı
- SSH key yanlışlıkla git'e commit — key /var/www dışında tutun