Chapitre 15.2 — Outils de backup

⏱️ TL;DR — La stratégie posée, on l’outille. rsync copie et synchronise des fichiers (utile, mais ce n’est pas de la vraie sauvegarde versionnée). Les vrais outils du métier sont restic et borg : déduplication (on ne stocke qu’une fois les données identiques), chiffrement de bout en bout, snapshots incrémentaux rapides, et dépôts distants (S3, Backblaze B2, OVH Object Storage). Les snapshots du fournisseur VPS sont pratiques pour un rollback, mais même datacenter (pas « hors-site ») et pas granulaires. On envoie donc une copie offsite vers du stockage objet, on automatise par cron ou timer systemd, et on chiffre tout — obligatoire dès qu’il y a des données personnelles (RGPD). Ce chapitre te donne un script de sauvegarde restic prêt à adapter.

🎯 Objectifs

• Situer rsync et comprendre pourquoi ce n’est pas une sauvegarde versionnée.
• Utiliser restic : initialiser un dépôt, sauvegarder, lister, purger avec une politique de rétention.
• Comprendre l’intérêt de la déduplication et du chiffrement intégrés.
• Envoyer une sauvegarde offsite vers du stockage objet (S3, Backblaze B2, OVH).
• Automatiser la sauvegarde par cron ou timer systemd.
• Savoir ce que valent (et ne valent pas) les snapshots du fournisseur.

rsync : copier et synchroniser

rsync est l’outil de base pour copier des fichiers d’un endroit à un autre, en ne transférant que ce qui a changé (copie incrémentale). Il est parfait pour synchroniser un dossier, préparer une migration, ou pousser des uploads vers un autre serveur.

🐚 Au terminal — Synchroniser un dossier d’uploads vers un serveur distant :

rsync -avz --delete /var/www/shared/uploads/ deploy@backup-host:/srv/uploads/
# -a : mode archive (permissions, dates, liens symboliques préservés)
# -v : verbeux (affiche ce qui est transféré)
# -z : compresse pendant le transfert
# --delete : supprime à la destination ce qui n'existe plus à la source

Utile — mais attention : rsync synchronise, il ne versionne pas. Avec --delete, si tu supprimes un fichier par erreur à la source, la prochaine synchro le supprime aussi à la destination. Tu n’as aucun historique : impossible de revenir à « la version d’il y a trois jours ». Pour de la vraie sauvegarde, il faut des snapshots datés — c’est là qu’interviennent restic et borg.

⚠️ Piège — Prendre rsync --delete pour une sauvegarde. C’est un miroir, pas une sauvegarde : une suppression ou une corruption à la source se propage à la copie à la synchro suivante. Sans historique de versions, tu n’as pas de filet contre l’erreur humaine — juste une deuxième copie du problème.

restic et borg : les vrais outils de sauvegarde

restic et borg (Borg Backup) sont les deux références open source de la sauvegarde moderne sur Linux. Ils partagent les mêmes qualités décisives :

• Snapshots incrémentaux : le premier envoi copie tout, les suivants ne transfèrent que les différences — rapides et légers.
• Déduplication : les blocs de données identiques ne sont stockés qu’une fois. Sauvegarder 30 fois une base qui change peu tient dans une fraction de l’espace attendu.
• Chiffrement intégré : le dépôt est chiffré de bout en bout. Même si le stockage distant est compromis, les données restent illisibles sans la clé.
• Dépôts distants : ils écrivent directement vers du stockage objet (S3, Backblaze B2, OVH…), du SFTP, un disque local — l’offsite est natif.
• Rétention automatique : une commande applique ta politique grand-père-père-fils et purge le reste.

Les deux se valent ; restic est réputé plus simple à prendre en main et gère nativement le stockage objet, donc on l’utilise ici comme exemple. Les concepts se transposent à borg.

💡 Réflexe — Choisis un outil de sauvegarde et maîtrise-le à fond plutôt que d’empiler des scripts maison. restic (ou borg) t’apporte gratuitement le chiffrement, la déduplication et la rétention — trois choses très difficiles et risquées à réimplémenter correctement à la main.

Les gestes restic de base

Un dépôt restic (repository) est l’endroit où vivent tes sauvegardes. On l’initialise une fois, puis on y pousse des snapshots.

🐚 Au terminal — Le cycle de vie d’un dépôt restic :

# 1. Initialiser un dépôt (ici sur Backblaze B2 via le protocole S3)
export RESTIC_REPOSITORY="s3:s3.eu-central-003.backblazeb2.com/formacampus-backups"
export RESTIC_PASSWORD="phrase-de-passe-longue-et-secrete"
restic init                       # crée et chiffre le dépôt (une seule fois)
 
# 2. Sauvegarder des dossiers dans un nouveau snapshot
restic backup /var/www/shared/uploads /etc /var/backups/db
 
# 3. Lister les snapshots existants
restic snapshots                  # affiche l'historique daté
 
# 4. Restaurer (aperçu — détaillé au chapitre 15.3)
restic restore latest --target /tmp/restauration

Décortiquons. Les variables RESTIC_REPOSITORY et RESTIC_PASSWORD disent à restic où est le dépôt et avec quelle clé le déchiffrer. restic init crée le dépôt chiffré (à ne faire qu’une fois). restic backup <dossiers> crée un snapshot daté : le premier prend le temps de tout envoyer, les suivants sont incrémentaux et rapides grâce à la déduplication. restic snapshots liste l’historique. Chaque snapshot est un point de restauration identifié par une date et un ID court.

Appliquer une politique de rétention

Sans nettoyage, les snapshots s’accumulent. La commande restic forget applique ta politique grand-père-père-fils, et l’option --prune libère réellement l’espace en supprimant les données devenues inutiles.

🐚 Au terminal — Purger selon la rétention 7 quotidiennes / 4 hebdo / 6 mensuelles :

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune
# --keep-daily 7   : garde les 7 dernières sauvegardes quotidiennes
# --keep-weekly 4  : garde 4 hebdomadaires
# --keep-monthly 6 : garde 6 mensuelles
# --prune          : supprime physiquement les données orphelines (libère l'espace)

Ici, restic forget décide quels snapshots garder selon la politique, et --prune compacte le dépôt en supprimant les blocs qui ne sont plus référencés par aucun snapshot conservé. Sans --prune, les snapshots sont « oubliés » mais l’espace n’est pas récupéré — d’où son importance dans le nettoyage périodique.

📚 La doc — Les options exactes (--keep-*, --prune, cibles S3/B2, exclusions) et leur syntaxe courante sont dans la doc officielle restic et via restic help backup / restic help forget au terminal. borg a sa propre doc équivalente. N’invente pas d’option : vérifie toujours sur la référence versionnée, elle fait autorité.

L’offsite : le stockage objet

Le « 1 hors-site » de la règle 3-2-1 se réalise le plus simplement avec du stockage objet — un service qui stocke des fichiers via une API HTTP, facturé au volume, hébergé ailleurs que ton VPS :

• Amazon S3 — la référence, API que tout le monde imite.
• Backblaze B2 — très bon marché, compatible avec l’API S3 (donc utilisable tel quel par restic).
• OVH Object Storage, Scaleway Object Storage — options européennes (intéressant pour le RGPD).

L’avantage : c’est hors de ton serveur, dans un autre datacenter, souvent avec de la redondance interne. restic écrit directement dedans (le dépôt s3:... de l’exemple). Tu obtiens ton offsite chiffré sans gérer un second serveur.

🔒 Sécurité — Deux règles pour l’offsite. Un : chiffre toujours avant l’envoi — restic le fait nativement, ne t’en prive pas. Deux : crée une clé d’accès dédiée au dépôt de sauvegarde, avec des droits limités à ce bucket (idéalement en écriture/append seulement, pour qu’un serveur compromis ne puisse pas effacer l’historique). Ne réutilise jamais la clé « admin » de ton compte cloud pour un script de backup.

Automatiser : cron ou timer systemd

Une sauvegarde qu’il faut lancer à la main sera oubliée. On l’automatise. Deux mécanismes (vus en Partie 14 et Partie 5) : le cron classique, ou un timer systemd (plus intégré à journalctl, avec gestion des échecs). Voici un script de sauvegarde que le planificateur appellera.

#!/usr/bin/env bash
# /usr/local/bin/backup-formacampus.sh
# Sauvegarde restic : base PostgreSQL + uploads + configs, vers stockage objet chiffré.
set -euo pipefail   # arrêt au moindre échec, variables non définies interdites
 
# --- Secrets et cible (chargés depuis un fichier protégé, PAS en dur ici) ---
export RESTIC_REPOSITORY="s3:s3.eu-central-003.backblazeb2.com/formacampus-backups"
export RESTIC_PASSWORD_FILE="/etc/restic/password"       # phrase de passe du dépôt
export AWS_ACCESS_KEY_ID_FILE="/etc/restic/b2-key-id"    # identifiants du stockage objet
# (les identifiants B2/S3 sont chargés via le fichier d'environnement du service)
 
DB_DUMP="/var/backups/db/formacampus-$(date +%F).sql.gz"
 
# --- 1. Dump de la base, compressé (voir Partie 11.5) ---
mkdir -p /var/backups/db
sudo -u postgres pg_dump formacampus | gzip > "$DB_DUMP"
 
# --- 2. Snapshot restic : dump DB + uploads + configs ---
restic backup \
  "$DB_DUMP" \
  /var/www/shared/uploads \
  /etc/nginx /etc/systemd/system
 
# --- 3. Rétention : 7 quotidiennes, 4 hebdo, 6 mensuelles + purge ---
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
 
# --- 4. Vérifier l'intégrité du dépôt de temps en temps ---
restic check
 
echo "Sauvegarde terminée : $(date)"

Ce script fait tout le cycle : il dumpe la base (pg_dump compressé au vol par gzip), crée un snapshot restic du dump + des uploads + des configs, applique la rétention et purge, puis lance un restic check qui vérifie l’intégrité du dépôt. Le set -euo pipefail en tête garantit que le script s’arrête au premier échec au lieu de continuer en silence — crucial pour une sauvegarde. Les secrets ne sont pas écrits en dur : ils viennent de fichiers protégés (RESTIC_PASSWORD_FILE) et de l’environnement du service.

🐚 Au terminal — Planifier ce script tous les jours à 3 h via un timer systemd, puis suivre son exécution :

sudo systemctl enable --now backup-formacampus.timer   # active le timer
systemctl list-timers backup-formacampus.timer         # prochaine exécution prévue
journalctl -u backup-formacampus.service -f            # suit les logs de la dernière sauvegarde

⚠️ Piège — Automatiser une sauvegarde sans jamais vérifier qu’elle tourne. Un timer qui échoue en silence pendant des semaines (dépôt plein, clé expirée, pg_dump en erreur) te laisse croire que tu es protégé alors que la dernière sauvegarde valide date d’un mois. Surveille l’échec : fais remonter une alerte si le job échoue (healthcheck, Partie 14), et vérifie les logs régulièrement.

Les snapshots du fournisseur : pratiques mais limités

Ton hébergeur VPS propose presque toujours un bouton « snapshot » : une image figée de tout ton disque à un instant T. C’est pratique — un clic avant une migration risquée, un rollback complet en cas de pépin. Mais ce n’est pas une stratégie de sauvegarde à soi seul :

• Même datacenter : le snapshot vit chez le même fournisseur, souvent dans la même région. Une panne majeure du fournisseur ou de ton compte l’emporte avec le reste → ce n’est pas du « hors-site ».
• Pas granulaire : tu restaures tout le disque, pas « juste ce fichier » ni « juste la table clients ». Pour récupérer un seul enregistrement, c’est l’artillerie lourde.
• Opaque et non testé : tu ne vois pas dans le snapshot, et tu ne peux pas facilement vérifier son contenu comme un dépôt restic.

Verdict : les snapshots fournisseur sont un excellent complément (rollback rapide, filet avant opération risquée), jamais ta seule ligne de défense. Le vrai filet, c’est le dépôt restic chiffré, granulaire et hors-site.

🧭 Sur FormaCampus — L’équipe met en place le script ci-dessus sur son VPS Ubuntu LTS. Chaque nuit à 3 h, un timer systemd dumpe la base PostgreSQL (pg_dump | gzip), crée un snapshot restic incluant le dump, les vidéos et PDF de /var/www/shared/uploads et les configs Nginx/systemd, puis pousse le tout chiffré vers un bucket Backblaze B2 en Europe — un vrai hors-site, hors du datacenter du VPS. La rétention est 7/4/6, la clé B2 est limitée à ce bucket, et un healthcheck alerte l’équipe si la sauvegarde échoue. Les snapshots OVH/Hetzner du VPS restent activés en plus, uniquement comme rollback avant une grosse migration. Reste l’étape que trop de gens sautent : vérifier que ça se restaure — c’est tout le chapitre suivant.

✏️ Exercices

Exercice 1 — rsync ou restic ? Pour chacun de ces besoins, dis lequel est adapté et pourquoi : (A) recopier une fois /var/www vers un nouveau VPS pendant une migration ; (B) garder un historique quotidien chiffré et hors-site des données utilisateurs, avec possibilité de revenir 3 semaines en arrière.

Exercice 2 — Corrige le nettoyage. Un collègue lance restic forget --keep-daily 7 chaque nuit, mais s’étonne que son bucket B2 continue de grossir sans fin et que sa facture monte. Qu’est-ce qui manque ?

Exercice 3 — Sécurise l’offsite. Tu configures l’envoi de tes sauvegardes vers un bucket S3. Cite deux mesures de sécurité indispensables avant de mettre le script en production.

🧠 Quiz de révision

Chapitre suivant : Tester la restauration — le chapitre qui sauve vraiment : une sauvegarde non testée n’existe pas.