Stratégie de sauvegarde : la règle 3-2-1-1-0

Tout le monde sauvegarde. Beaucoup moins de monde sait restaurer. Entre les deux, il y a une poignée de règles simples, quelques outils libres et éprouvés, et une habitude que presque personne n'a : vérifier, régulièrement, que le jour où il le faudra, ça marchera.

01Ce qui n'est pas une sauvegarde

Une sauvegarde, c'est une copie séparée (sur une autre machine), versionnée (on peut remonter à hier, à la semaine dernière, au mois dernier) et vérifiée. Il manque l'un des trois, et c'est autre chose.

02La règle 3-2-1-1-0

La règle 3-2-1 a longtemps suffi. Les rançongiciels, qui cherchent et détruisent les sauvegardes avant de chiffrer le reste, ont imposé deux chiffres de plus :

1. 3 copies des données, l'original compris.
2. 2 supports différents : un serveur et un stockage objet, un disque et une bande.
3. 1 copie hors site : l'incendie, le dégât des eaux et le vol ne s'arrêtent pas à la porte de la salle serveur.
4. 1 copie immuable ou hors ligne : une copie que personne ne peut modifier ni effacer, pas même un administrateur dont le compte a été volé.
5. 0 erreur au dernier test de restauration.

03RPO et RTO, les deux chiffres qui décident

• RPO (objectif de point de reprise) : combien de données pouvez-vous perdre ? Une sauvegarde par nuit, c'est un RPO de 24 heures : tout ce qui est saisi dans la journée peut disparaître.
• RTO (objectif de temps de reprise) : combien de temps pouvez-vous rester arrêté ? C'est lui qui dicte s'il faut une copie locale rapide, ou si une restauration depuis un site distant, sur plusieurs jours, est acceptable.

Ces deux chiffres sont des décisions de direction, pas des choix techniques. Le simulateur du coût d'une panne aide à les fixer : on voit vite ce que coûte une journée de travail perdue, ou une semaine de restauration.

04Quel outil pour quoi

Il n'y a pas d'outil universel, mais il y a des outils libres excellents. Tous ceux-ci chiffrent, compressent et dédupliquent : trente jours d'historique occupent à peine plus qu'une copie complète.

Chez nos clients, le schéma le plus courant est : Proxmox Backup Server pour les machines virtuelles, synchronisé vers un second PBS sur un autre site, plus Borgmatic pour les sauvegardes applicatives fines (bases de données exportées proprement, répertoires de sites). Le chapitre haute disponibilité et sauvegardes du guide cluster détaille la partie PBS.

05Borgmatic, en vingt minutes

Borgmatic pilote Borg à partir d'un fichier de configuration unique : quoi sauvegarder, où, combien de temps garder, quelles bases exporter avant, et quoi vérifier après.

apt install borgbackup borgmatic

# la phrase de passe vit dans un fichier lisible par root seul,
# et une copie part dans le coffre-fort de mots de passe : sans elle, rien ne se restaure
install -m 600 /dev/null /root/.borg-passphrase

source_directories:
  - /etc
  - /var/www
  - /home

exclude_patterns:
  - /var/www/*/cache
  - '*.tmp'

repositories:
  - path: ssh://borg@sauvegarde.exemple.fr/./serveur-web
    label: distant

encryption_passcommand: cat /root/.borg-passphrase
compression: zstd,6

keep_daily: 7
keep_weekly: 4
keep_monthly: 12
keep_yearly: 2

# export coherent des bases avant la sauvegarde, jamais une copie des fichiers a chaud
mariadb_databases:
  - name: all

checks:
  - name: repository
    frequency: 1 week
  - name: archives
    frequency: 1 month

# repo-create sur borgmatic recent (init sur les versions anciennes)
borgmatic repo-create --encryption repokey-blake2
borgmatic --verbosity 1 --stats
borgmatic list

# exporter la cle du depot : a ranger dans le coffre-fort, avec la phrase de passe
borgmatic key export

# chaque nuit a 2 h 30, avec un delai aleatoire pour ne pas saturer le serveur distant
# (pas de % ni de $RANDOM ici : cron les interprete autrement)
30 2 * * * root sleep $(shuf -i 0-900 -n 1) && borgmatic --syslog-verbosity 1

06La copie qu'un attaquant ne peut pas effacer

Un rançongiciel moderne ne se contente pas de chiffrer : il cherche les identifiants de sauvegarde sur le serveur compromis et s'en sert pour tout effacer. Si le serveur de production peut supprimer ses sauvegardes, l'attaquant le peut aussi. La parade consiste à ce que la production puisse ajouter, jamais supprimer.

# cette cle ne peut que lancer borg serve, en ajout seul, dans son repertoire
command="borg serve --append-only --restrict-to-path /srv/borg/serveur-web",restrict ssh-ed25519 AAAA... serveur-web

En mode ajout seul, une suppression demandée par le client est journalisée mais réversible ; le nettoyage réel (prune et compactage) se fait depuis le serveur de sauvegarde, avec une autre clé, que la production ne connaît pas.

• Avec Proxmox Backup Server : le PBS distant tire les sauvegardes du PBS local (synchronisation en mode pull). La production ne possède aucun identifiant sur le site distant.
• Avec Restic : le serveur rest-server lancé avec --append-only offre la même garantie.
• Hors ligne : un disque ou une bande déconnecté après chaque copie reste la protection la plus simple à comprendre, à condition que la rotation soit vraiment faite.

07Tester la restauration

Une fois par trimestre, au minimum. Pas « vérifier que la sauvegarde existe » : restaurer pour de vrai, sur une machine de test, et constater que l'application fonctionne.

1. Choisir une cible tournante : une machine différente à chaque test, en commençant par les plus critiques.
2. Restaurer dans un réseau isolé, pour ne pas faire démarrer un second serveur de production qui enverrait des courriels ou écrirait dans une base partagée.
3. Vérifier l'application, pas les fichiers : on se connecte, on ouvre un dossier client, on lance une facture.
4. Chronométrer : le temps mesuré est votre RTO réel. Comparez-le à celui que la direction a fixé.
5. Écrire le compte rendu : date, machine, durée, problèmes rencontrés. C'est la preuve que l'assureur et l'auditeur demanderont.

08Les erreurs qui coûtent cher