Sauvegarder un VPS : la règle 3-2-1, version terrain

1. Pourquoi 90 % des « stratégies » sont des illusions

En cinq ans d'exploitation, nous avons vu passer toutes les variantes de la mauvaise surprise. Les quatre patterns qui reviennent sans cesse :

• Le snapshot présenté comme backup. Un snapshot vit sur le même stockage que le disque principal, dans la même infrastructure : panne du backend, compromission, erreur de manipulation — les deux partent ensemble. Un snapshot est un rollback pratique, pas une copie.
• La sauvegarde jamais restaurée. Un script qui tourne depuis un an, silencieusement vide depuis six mois parce que le chemin du dépôt a changé. Sans exercice de restauration, vous ne savez pas ce que vous avez.
• La base dumpée pendant qu'elle écrit. Un tar sur un MySQL en activité produit un dump corrompu au hasard des écritures — vous le découvrez le jour où vous en avez besoin.
• Les credentials au même endroit que le serveur. Ransomware ou utilisateur malveillant : tout ce qui est sur le VPS disparaît avec lui, y compris la clé qui déchiffre les sauvegardes.

Deux chiffres encadrent toute la stratégie. Le RPO (Recovery Point Objective) est le volume de données que vous acceptez de perdre — 24 heures de changements, 1 heure, 5 minutes. Le RTO (Recovery Time Objective) est le temps que vous acceptez de rester à terre — 4 heures, 30 minutes. Ce guide part sur un objectif honnête et accessible : RPO 24 h, RTO 4 h, tenable pour quelques dollars par mois. Si votre RPO est de 5 minutes, la bonne réponse n'est plus la sauvegarde mais la réplication — autre sujet.

2. La règle 3-2-1, adaptée au VPS

La règle d'or de l'industrie : 3 copies des données, sur 2 supports différents, dont 1 hors site. Voici sa traduction concrète pour un VPS VPSPLEX :

Le « hors site » mérite un mot dans notre contexte : héberger sa sauvegarde dans une autre juridiction n'est pas seulement une protection contre la panne — c'est aussi une diversification juridique. Une donnée sauvegardée à Rotterdam et répliquée à Panama survit à un incident qui frapperait l'une des deux localisations, technique ou judiciaire. Ce n'est pas un argument pour contourner la loi : c'est la raison d'être de notre offre multi-pays.

3. Couche 1 : les snapshots VPSPLEX

Depuis le tableau de bord (VPS → Snapshots), un snapshot capture l'état complet du disque en quelques secondes — mécanisme copy-on-write au niveau du stockage, donc quasiment instantané et transparent pour vos services. L'option coûte 1 $/mois par VPS ; l'option « backups quotidiens » (+20 % du tarif) automatise un snapshot conservé 7 jours.

• Avant une mise à jour risquée : upgrade majeur Debian, migration de version MySQL, grosse refonte
• Avant un durcissement (cf. notre guide première heure) : si vous cassez SSH, le snapshot vous évite le reinstall
• Rollback en quelques minutes : restaurer un snapshot remet le disque entier à l'heure dite, sans réinstallation

Ce qu'un snapshot n'est PAS : il vit sur le même backend de stockage que votre disque principal, dans la même infrastructure. Une corruption généralisée, une suppression malencontreuse côté exploitation ou une compromission de votre compte peut l'emporter avec le serveur. C'est votre rollback de confort, pas votre assurance-vie — les deux couches suivantes existent pour cela.

4. Couche 2 : sauvegardes fichiers avec restic

Nous standardisons sur restic en interne pour trois raisons : déduplication (une même donnée n'est stockée qu'une fois, quelle que soit la version), chiffrement côté client systématique (AES-256-CTR + Poly1305 — le dépôt peut fuiter sans que rien ne soit lisible) et vérifiabilité (restic check valide l'intégrité du dépôt). C'est aussi le moins dépendant des backends : SFTP, S3, disque local, même syntaxe.

apt install -y restic
# Debian 12 fournit restic 0.14+, Ubuntu 24.04 la 0.16 — largement suffisant

# Le mot de passe restic chiffre TOUT : perdu = sauvegardes perdues
# Générez-le dans votre gestionnaire de mots de passe, stockez-le ailleurs aussi
install -m 700 -d /root/.config/restic
echo 'votre-passphrase-longue-et-unique' > /root/.config/restic/password
chmod 600 /root/.config/restic/password

# Exclusions : pas de /proc, pas de cache, pas de logs tournants
cat > /etc/restic-excludes.txt <<'EOF'
/proc
/sys
/dev
/run
/tmp
/var/cache
/var/tmp
/var/lib/docker
EOF

# Initialisation d'un dépôt (ici : un second VPS via SFTP)
export RESTIC_REPOSITORY="sftp:[email protected]:/srv/repos/vps-prod"
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
restic init

# Premier backup
restic backup /etc /home /var/www /srv/dumps --exclude-file=/etc/restic-excludes.txt --one-file-system

Notez le --one-file-system : il empêche restic de suivre un montage réseau ou un volume chiffré monté par hasard — vous sauvegardez ce que vous pensez sauvegarder, pas une montagne de données volatiles.

5. Couche 3 : la copie hors site

Deux architectures raisonnables, selon le volume :

Option A — un second VPS VPSPLEX dans une autre juridiction

Un VPS-1 Coast à 6,99 $/mois, dans un pays différent de celui du serveur de production, avec un utilisateur dédié restic et SSH par clé uniquement. C'est l'option la plus simple à auditer : vous voyez le disque, vous maîtrisez les coûts (flat), et la donnée quitte physiquement le datacenter de prod. Sur 25 Go de NVMe, un /etc, un /var/www et des dumps tiennent des années avec la déduplication.

Option B — stockage objet S3-compatible

Pour les gros volumes (100 Go et au-delà), restic parle S3 nativement. Attention au vrai coût : le stockage est peu cher, le egress (sortie) au moment d'une restauration peut surprendre — renseignez-vous avant d'en avoir besoin. Le chiffrement restic étant appliqué côté client, le fournisseur de stockage ne voit que des objets chiffrés : il n'a aucune idée de ce que vous sauvegardez.

# Dépôt S3 : variables d'accès + repository
export AWS_ACCESS_KEY_ID="votre-cle"
export AWS_SECRET_ACCESS_KEY="votre-secret"
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.example.com/mon-bucket/vps-prod"
export RESTIC_PASSWORD_FILE=/root/.config/restic/password

restic init
restic backup /etc /home /var/www /srv/dumps --exclude-file=/etc/restic-excludes.txt --one-file-system

Dernier garde-fou, gratuit : une fois par mois, tirez une copie du dépôt sur votre propre machine (un simple rsync -avz du dépôt restic chiffré, ou un restic restore partiel). Vos données ne vivent alors plus que sur des machines que vous ne contrôlez pas.

6. Automatiser sans se tirer une balle dans le pied

Le script ci-dessous fait trois choses : le backup quotidien, l'application de la politique de rétention, et un log horodaté. Le verrou flock empêche deux exécutions de se chevaucher (backup lent + cron qui repasse) — une corruption classique de dépôt.

#!/usr/bin/env bash
set -euo pipefail

export RESTIC_REPOSITORY="sftp:[email protected]:/srv/repos/vps-prod"
export RESTIC_PASSWORD_FILE="/root/.config/restic/password"
LOCK=/run/restic-backup.lock
LOG=/var/log/restic.log

# Un seul backup à la fois
exec 9>"$LOCK"
flock -n 9 || { echo "$(date -Is) backup déjà en cours — abandon" >> "$LOG"; exit 1; }

# Backup quotidien
restic backup /etc /home /var/www /srv/dumps \
  --exclude-file=/etc/restic-excludes.txt \
  --one-file-system \
  --compression max >> "$LOG" 2>&1

# Politique de rétention : 7 jours, 4 semaines, 12 mois
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune >> "$LOG" 2>&1

echo "$(date -Is) backup OK" >> "$LOG"

# Backup quotidien à 03:15 — heure creuse, évitons :00 pile (tout le monde y est)
15 3 * * * root /usr/local/sbin/restic-backup.sh

# Vérification d'intégrité hebdomadaire (dimanche 02:30)
30 2 * * 0 root export RESTIC_REPOSITORY="sftp:[email protected]:/srv/repos/vps-prod" RESTIC_PASSWORD_FILE=/root/.config/restic/password; restic check --with-cache >> /var/log/restic.log 2>&1

Les puristes préfèrent un systemd timer : plus facile à superviser (systemctl status restic-backup.timer), journalisation native, dépendances propres. Le cron ci-dessus fait exactement le même travail avec zéro abstraction. Le seul point non négociable : une alerte quand ça échoue. Un simple || curl -X POST https://votre-webhook en fin de script sur le code de retour non nul, et vous saurez le jour où ça casse — pas le jour où vous en avez besoin.

7. Bases de données : le dump avant le backup

Sauvegarder un fichier de base de données pendant qu'elle écrit produit un dump corrompu une fois sur deux — InnoDB et PostgreSQL écrivent en permanence. La bonne séquence : dump cohérent vers un fichier, puis backup restic du fichier. Avant le cron ci-dessus, ajoutez :

# MySQL / MariaDB : --single-transaction = image cohérente InnoDB sans verrouillage
install -m 700 -d /srv/dumps
mysqldump --single-transaction --routines --triggers --quick \
  ma_base | gzip > "/srv/dumps/ma_base-$(date +%F).sql.gz"

# PostgreSQL : format custom, restaurable avec pg_restore
pg_dump -Fc ma_base > "/srv/dumps/ma_base-$(date +%F).dump"

# SQLite : la méthode .backup est atomique et sûre à chaud
sqlite3 /var/lib/monapp/db.sqlite ".backup '/srv/dumps/db-$(date +%F).sqlite'"

# Redis : un BGSAVE puis copie du dump.rdb suffit pour un RDB
redis-cli BGSAVE && sleep 2 && cp /var/lib/redis/dump.rdb "/srv/dumps/redis-$(date +%F).rdb"

/srv/dumps est inclus dans la liste des chemins sauvegardés par le script de l'étape 6. Les dumps s'empilent — ajoutez une ligne de rotation (find /srv/dumps -mtime +7 -delete dans le script) ou laissez restic les dédupliquer et les oublier selon la politique de rétention.

8. L'exercice de restauration trimestriel

Tous les trimestres, bloquez 45 minutes et restaurez pour de vrai. Pas une vérification de checksum : une restauration. Voici la procédure que nous appliquons en interne, avec un VPS temporaire (un VPS-1 Coast quelques heures coûte moins d'un euro) :

# 1. Inventaire des snapshots disponibles
export RESTIC_REPOSITORY="sftp:[email protected]:/srv/repos/vps-prod"
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
restic snapshots

# 2. Restauration complète dans un dossier neutre
restic restore latest --target /var/tmp/restore

# 3. Vérifications : structure, tailles, et un diff sur un échantillon critique
du -sh /var/tmp/restore/etc /var/tmp/restore/var/www
diff -r /etc/nginx /var/tmp/restore/etc/nginx 2>&1 | head

# 4. Restauration ciblée d'un fichier précis (le cas réel à 90 %)
restic restore latest --target /var/tmp/restore --include /var/www/monapp/config.php

# 5. Bonus : monter le dépôt comme un système de fichiers pour naviguer dedans
restic mount /mnt/restic &
ls /mnt/restic/snapshots/latest/

1. Chronométrez. Le temps écoulé entre « je lance la restauration » et « le service répond » est votre RTO réel — notez-le dans un fichier daté. Il sera presque toujours plus long que prévu la première fois.
2. Démarrez un service sur la copie. Un nginx sur un port alternatif, un MySQL sur un socket temporaire : une donnée restaurée qui ne sert pas est une donnée non testée.
3. Vérifiez un échantillon aléatoire. Cinq fichiers choisis au hasard dans /var/www, ouverts, comparés. La corruption silencieuse aime les recoins.
4. Documentez et détruisez. Notez ce qui a coincé (chemin manquant, clé introuvable, dump trop vieux), corrigez le script, supprimez le VPS de test.

9. Ce que ça coûte vraiment

Pas de langue de bois sur la facture. Pour un VPS-3 Horizon de production (19,99 $/mois) :

• Snapshots : 1 $/mois par VPS — l'assurance rollback, non négociable dès que le serveur sert quelque chose.
• VPS de destination restic : 6,99 $/mois (VPS-1 Coast, autre juridiction) — soit ~35 % du coût de la prod pour un RPO de 24 h sur vos données critiques.
• Backups quotidiens managés : +20 % du tarif du VPS si vous préférez ne rien gérer — c'est notre option « je dors tranquille » pour ceux qui ne veulent pas maintenir de script.

Total : ~28–30 $/mois pour une stack complète RPO 24 h / RTO 4 h. Comparez avec la valeur de ce que le serveur héberge. La déduplication restic fait que 25 Go de dépôt suffisent des années pour la plupart des configs ; et si le volume dépasse, un VPS-2 Reef côté destination reste sous les 12 $/mois.

Questions fréquentes