Stratégies de sauvegarde automatisée pour VPS

Les sauvegardes sont ce que vous auriez souhaité avoir configuré hier. Ce guide couvre tout, des scripts rapides aux systèmes de sauvegarde automatisés à toute épreuve.

Pourquoi c’est important

Votre VPS finira par tomber en panne. Le matériel lâche, les centres de données ont des pannes, vous exécuterez une mauvaise commande, ou un ransomware vous trouvera. La question n’est pas de savoir si vous aurez besoin de sauvegardes — c’est quand.

Ce qui peut mal tourner sans sauvegardes :

• Un rm -rf / accidentel dans le mauvais répertoire
• Corruption de la base de données lors d’une mise à jour
• Le fournisseur subit une panne et perd vos données
• Un logiciel malveillant chiffre tout
• Des années de travail, perdues en quelques secondes

La règle 3-2-1 :

• 3 copies de vos données
• 2 types de stockage différents
• 1 emplacement hors site

Prérequis

• Un VPS (nous recommandons Hostinger VPS qui inclut des sauvegardes automatiques dans la plupart des plans)
• Stockage externe (S3, Backblaze B2, un autre serveur, etc.)
• Connaissances de base en scripting shell

Étape 1 : Identifier ce qui doit être sauvegardé

Tout n’a pas besoin d’être sauvegardé. Concentrez-vous sur :

Sauvegarde obligatoire :

• Bases de données (PostgreSQL, MySQL, MongoDB)
• Fichiers téléchargés par les utilisateurs et médias
• Fichiers de configuration
• Certificats SSL
• Fichiers d’environnement (.env)

Optionnel (peut être recréé) :

• Code applicatif (si dans git)
• Images Docker (si dans un registre)
• Paquets système (réinstallables)

Ne pas sauvegarder :

• Journaux (en général)
• Répertoires de cache
• Fichiers temporaires
• node_modules, vendor, etc.

Étape 2 : Configurer les sauvegardes locales

Créez une structure de répertoires de sauvegarde :

sudo mkdir -p /backups/{daily,weekly,monthly}
sudo chown $USER:$USER /backups

Script de sauvegarde de base :

#!/bin/bash
# /usr/local/bin/backup-local.sh

set -e

DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backups/daily"
RETENTION_DAYS=7

# Create backup directory
mkdir -p "$BACKUP_DIR/$DATE"

# Backup PostgreSQL
echo "Backing up PostgreSQL..."
docker exec postgres pg_dumpall -U postgres | gzip > "$BACKUP_DIR/$DATE/postgres.sql.gz"

# Backup MySQL
echo "Backing up MySQL..."
docker exec mysql mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases | gzip > "$BACKUP_DIR/$DATE/mysql.sql.gz"

# Backup application data
echo "Backing up app data..."
tar -czf "$BACKUP_DIR/$DATE/app-data.tar.gz" /home/deploy/apps/*/data/ 2>/dev/null || true

# Backup configurations
echo "Backing up configs..."
tar -czf "$BACKUP_DIR/$DATE/configs.tar.gz" \
  /etc/nginx/sites-available \
  /etc/letsencrypt \
  /home/deploy/apps/*/.env \
  /home/deploy/apps/*/docker-compose.yml \
  2>/dev/null || true

# Remove old backups
echo "Cleaning old backups..."
find "$BACKUP_DIR" -type d -mtime +$RETENTION_DAYS -exec rm -rf {} + 2>/dev/null || true

echo "Local backup completed: $BACKUP_DIR/$DATE"

Rendez-le exécutable :

chmod +x /usr/local/bin/backup-local.sh

Étape 3 : Configurer les sauvegardes distantes avec Restic

Restic est un outil de sauvegarde moderne avec chiffrement et déduplication.

Installer Restic :

sudo apt install restic -y

Option A : Backblaze B2 (Le moins cher)

Créez un compte et un bucket B2, puis :

# Set environment variables
export B2_ACCOUNT_ID="your-account-id"
export B2_ACCOUNT_KEY="your-account-key"
export RESTIC_REPOSITORY="b2:your-bucket-name:backups"
export RESTIC_PASSWORD="your-encryption-password"

# Initialize repository (only once)
restic init

# Run backup
restic backup /home/deploy/apps /etc/nginx /etc/letsencrypt

# Check snapshots
restic snapshots

Option B : AWS S3

export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/your-bucket/backups"
export RESTIC_PASSWORD="your-encryption-password"

restic init
restic backup /home/deploy/apps

Option C : Un autre serveur via SFTP

export RESTIC_REPOSITORY="sftp:user@backup-server:/backups"
export RESTIC_PASSWORD="your-encryption-password"

restic init
restic backup /home/deploy/apps

Étape 4 : Script de sauvegarde complet

#!/bin/bash
# /usr/local/bin/backup-full.sh

set -e

# Configuration
export RESTIC_REPOSITORY="b2:mybucket:vps-backups"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
export B2_ACCOUNT_ID="your-id"
export B2_ACCOUNT_KEY="your-key"

BACKUP_DIR="/tmp/backup-$(date +%Y%m%d)"
LOG_FILE="/var/log/backup.log"

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

# Create temp directory
mkdir -p "$BACKUP_DIR"

log "Starting backup..."

# Dump databases
log "Dumping PostgreSQL..."
docker exec -t postgres pg_dumpall -U postgres > "$BACKUP_DIR/postgres.sql" 2>/dev/null || log "PostgreSQL dump failed or not running"

log "Dumping MySQL..."
docker exec -t mysql mysqldump -u root -p"${MYSQL_ROOT_PASSWORD}" --all-databases > "$BACKUP_DIR/mysql.sql" 2>/dev/null || log "MySQL dump failed or not running"

# Backup Redis
log "Backing up Redis..."
docker exec -t redis redis-cli BGSAVE 2>/dev/null || true
sleep 2
docker cp $(docker ps -qf name=redis):/data/dump.rdb "$BACKUP_DIR/redis.rdb" 2>/dev/null || log "Redis backup failed or not running"

# Backup files with restic
log "Running restic backup..."
restic backup \
    --verbose \
    --exclude='*.log' \
    --exclude='node_modules' \
    --exclude='.git' \
    --exclude='__pycache__' \
    --exclude='.cache' \
    "$BACKUP_DIR" \
    /home/deploy/apps \
    /etc/nginx \
    /etc/letsencrypt

# Cleanup old snapshots (keep 7 daily, 4 weekly, 6 monthly)
log "Pruning old backups..."
restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --prune

# Cleanup temp directory
rm -rf "$BACKUP_DIR"

# Check repository health
log "Checking repository..."
restic check

log "Backup completed successfully!"

# Optional: Send notification
# curl -X POST "https://api.pushover.net/1/messages.json" \
#     -d "token=xxx&user=xxx&message=Backup completed"

Créez le fichier de mot de passe :

echo "your-secure-password" | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Étape 5 : Planification avec Cron

# Edit crontab
sudo crontab -e

Ajoutez :

# Daily backup at 3 AM
0 3 * * * /usr/local/bin/backup-full.sh >> /var/log/backup.log 2>&1

# Weekly integrity check on Sundays at 4 AM
0 4 * * 0 restic check --read-data-subset=10% >> /var/log/backup-check.log 2>&1

Étape 6 : Procédures de restauration

Apprenez à restaurer AVANT d’en avoir besoin.

Restaurer depuis Restic

# List snapshots
restic snapshots

# Restore specific snapshot
restic restore latest --target /restore-point

# Restore specific files
restic restore latest --target /restore-point --include "/home/deploy/apps/myapp"

# Mount backups (browse like filesystem)
mkdir /mnt/restic
restic mount /mnt/restic
# Browse at /mnt/restic/snapshots/

Restaurer PostgreSQL

# Drop and recreate database
docker exec -it postgres psql -U postgres -c "DROP DATABASE myapp;"
docker exec -it postgres psql -U postgres -c "CREATE DATABASE myapp;"

# Restore
cat backup/postgres.sql | docker exec -i postgres psql -U postgres

Restaurer MySQL

cat backup/mysql.sql | docker exec -i mysql mysql -u root -p"$MYSQL_ROOT_PASSWORD"

Étape 7 : Tester vos sauvegardes

Des sauvegardes non testées ne sont pas des sauvegardes. Planifiez des tests de restauration mensuels :

#!/bin/bash
# /usr/local/bin/test-restore.sh

TEST_DIR="/tmp/restore-test-$(date +%Y%m%d)"
mkdir -p "$TEST_DIR"

echo "Restoring latest snapshot to $TEST_DIR..."
restic restore latest --target "$TEST_DIR"

# Verify database dump is valid
echo "Verifying PostgreSQL dump..."
head -20 "$TEST_DIR/tmp/backup-*/postgres.sql"

# Check file integrity
echo "Checking restored files..."
find "$TEST_DIR" -type f | wc -l

# Cleanup
rm -rf "$TEST_DIR"

echo "Restore test completed. Review output above."

Étape 8 : Surveillance des sauvegardes

Soyez notifié lorsque les sauvegardes échouent :

#!/bin/bash
# Add to end of backup script

HEALTHCHECK_URL="https://hc-ping.com/your-uuid"

# On success
curl -fsS --retry 3 "$HEALTHCHECK_URL"

# On failure (add to trap)
trap 'curl -fsS --retry 3 "$HEALTHCHECK_URL/fail"' ERR

Utilisez Healthchecks.io (niveau gratuit disponible) pour surveiller :

• Recevoir une alerte si la sauvegarde ne s’exécute pas
• Suivre la durée des sauvegardes dans le temps
• Consulter l’historique des sauvegardes

Étape 9 : Stratégies spécifiques aux bases de données

Archivage continu PostgreSQL (WAL)

Pour une perte de données nulle :

# postgresql.conf
archive_mode = on
archive_command = 'restic backup --tag wal %p'

Journaux binaires MySQL

# my.cnf
log-bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 7

MongoDB

# Use mongodump for consistent backups
mongodump --archive --gzip | restic backup --stdin --stdin-filename mongo.archive.gz

Comparaison des stratégies de sauvegarde

Stratégie	RPO	Coût	Complexité
Dumps quotidiens	24h	Faible	Faible
Dumps horaires	1h	Moyen	Faible
Archivage WAL	Minutes	Moyen	Moyen
Réplication	Secondes	Élevé	Élevé

RPO = Recovery Point Objective (perte de données maximale acceptable)

Bonnes pratiques

1. Chiffrez tout - Les sauvegardes contiennent des données sensibles
2. Testez les restaurations mensuellement - Une sauvegarde que vous ne pouvez pas restaurer est inutile
3. Destinations multiples - Ne mettez pas toutes les sauvegardes au même endroit
4. Surveillez les tâches de sauvegarde - Sachez immédiatement quand elles échouent
5. Documentez les procédures - Rédigez des runbooks pour les restaurations
6. Automatisez tout - Les sauvegardes manuelles sont oubliées
7. Versionnez vos scripts de sauvegarde - Gardez-les dans git
8. Séparez les identifiants de sauvegarde - Limitez l’impact en cas de compromission

Erreurs courantes à éviter

❌ Sauvegardes uniquement locales - Le serveur tombe en panne, les sauvegardes aussi

❌ Ne jamais tester les restaurations - Vous découvrirez la corruption quand vous aurez le plus besoin des données

❌ Aucun chiffrement - Le stockage de sauvegarde se fait pirater, toutes les données sont exposées

❌ Sauvegarder des bases de données en cours d’exécution - Des dumps corrompus qui ne se restaurent pas

❌ Aucune politique de rétention - Le stockage se remplit, les sauvegardes s’arrêtent

❌ Mêmes identifiants partout - L’attaquant supprime aussi les sauvegardes

❌ Aucune surveillance - Les sauvegardes échouent silencieusement pendant des semaines

❌ Stocker le mot de passe de sauvegarde avec les sauvegardes - Annule entièrement le chiffrement

Liste de contrôle pour la récupération d’urgence

En cas de catastrophe :

1. Ne paniquez pas - Une récupération précipitée cause plus de dégâts
2. Évaluez les dommages - Qu’est-ce qui a exactement été perdu ?
3. Démarrez un nouveau serveur - Hostinger VPS peut avoir un nouveau serveur prêt en quelques minutes. Suivez notre guide de sécurité VPS lors de sa configuration
4. Restaurez la dernière sauvegarde - Utilisez votre procédure documentée
5. Restaurez les bases de données - Vérifiez l’intégrité des données
6. Mettez à jour le DNS si nécessaire - Pointez vers le nouveau serveur
7. Documentez ce qui s’est passé - Un post-mortem évite les répétitions

FAQ

À quelle fréquence devrais-je sauvegarder ?

Cela dépend de la quantité de données que vous pouvez vous permettre de perdre. Pour la plupart des sites : quotidiennement. E-commerce/financier : toutes les heures. Systèmes critiques : réplication continue.

Où devrais-je stocker les sauvegardes ?

Chez un fournisseur différent de votre VPS. Si Hostinger héberge votre serveur, utilisez Backblaze B2 ou AWS S3 pour les sauvegardes. Ne jamais utiliser le même fournisseur pour la production et les sauvegardes.

Combien de temps devrais-je conserver les sauvegardes ?

7 quotidiennes + 4 hebdomadaires + 12 mensuelles est un bon point de départ. Ajustez en fonction des exigences de conformité et des coûts de stockage.

Les instantanés du fournisseur sont-ils suffisants ?

Non. Les instantanés sont pratiques, mais ils se trouvent dans le même centre de données. Utilisez-les pour les retours arrière rapides, pas pour la reprise après sinistre.

Comment sauvegarder les volumes Docker ?

Si vous exécutez une stack Docker Compose, arrêtez brièvement le conteneur, ou utilisez des outils de sauvegarde de volumes :

docker run --rm -v myvolume:/data -v /backups:/backup alpine tar czf /backup/myvolume.tar.gz /data

Restic est-il meilleur que duplicity/borg ?

Ils sont tous bons. Restic a le meilleur support du stockage cloud. Borg est le plus rapide pour le local/SFTP. Choisissez-en un et tenez-vous-y.

---

Prochaines étapes : Configurez la surveillance pour détecter les problèmes avant d’avoir besoin de ces sauvegardes !