Sauvegardes serveur : appliquer la règle 3-2-1 sans se compliquer la vie

Tout le monde est d’accord pour dire qu’il faut des sauvegardes. Beaucoup moins de monde peut répondre précisément à ces trois questions :

• Où sont stockées vos sauvegardes ?
• Que contiennent-elles exactement ?
• Quand avez-vous testé une restauration pour la dernière fois ?

Si l’une de ces réponses est floue, vos sauvegardes sont probablement moins solides que vous ne le pensez. J’en parlais dans mon article sur ce que couvre l’infogérance serveur : une sauvegarde n’existe vraiment que si elle est automatique, externalisée et testée. Voici comment le mettre en pratique.

La règle 3-2-1

C’est la règle de base, et elle reste d’actualité :

• 3 copies de vos données : l’original et deux sauvegardes ;
• sur 2 supports différents ;
• dont 1 hors site, c’est-à-dire ailleurs que là où tournent vos données.

Pour un serveur web, ça se traduit simplement : les données en production sur le serveur, une sauvegarde locale ou chez le même hébergeur pour restaurer vite, et une sauvegarde chez un autre prestataire, dans un autre datacenter.

On parle aussi aujourd’hui de 3-2-1-1-0 : une copie supplémentaire immuable ou hors ligne (impossible à modifier ou supprimer, même avec les accès du serveur), et 0 erreur lors des tests de restauration. C’est la version adaptée à l’ère des rançongiciels, et on y revient plus bas.

Le snapshot de l’hébergeur ne suffit pas

La plupart des hébergeurs proposent des snapshots ou une option « sauvegarde automatique » du VPS. C’est utile, mais ce n’est pas une stratégie de sauvegarde à part entière :

• c’est chez le même prestataire : un incident sur le compte, un litige de facturation ou un problème dans le datacenter peut emporter le serveur et ses sauvegardes en même temps ;
• c’est une image complète du disque : pratique pour tout remettre en état, beaucoup moins pour récupérer un seul fichier ou une seule table ;
• la base de données n’est pas forcément cohérente : un snapshot pris pendant une écriture MySQL peut donner une base qui redémarre mal ;
• la rétention est souvent courte : quelques jours, parfois un seul point de restauration.

Gardez les snapshots, ils dépannent bien avant une mise à jour risquée. Mais considérez-les comme un bonus, pas comme votre sauvegarde.

Quoi sauvegarder

Sur un serveur qui héberge des sites WordPress, PrestaShop ou similaires, il faut couvrir trois choses :

Les fichiers des sites. En général /var/www, avec en priorité ce qui n’est pas reproductible : les médias envoyés, les fichiers de configuration (wp-config.php, parameters.php), les thèmes et modules personnalisés.

Les bases de données. C’est la partie la plus critique : commandes, clients, contenus. On ne sauvegarde jamais les fichiers bruts de MySQL pendant que le service tourne. On fait un export propre avec mysqldump, puis on sauvegarde cet export.

La configuration du serveur. /etc (vhosts Nginx ou Apache, configuration PHP, pare-feu), les tâches planifiées (crontab -l), et la liste des paquets installés. Sans ça, une restauration complète devient une reconstruction à l’aveugle.

Un outil : restic

Il existe de nombreux outils de sauvegarde. Je recommande restic pour la majorité des serveurs web, pour des raisons simples :

• chiffrement systématique : les données sont chiffrées avant de quitter le serveur, le stockage distant ne voit jamais rien en clair ;
• déduplication : seuls les blocs modifiés sont envoyés, une sauvegarde quotidienne reste rapide et peu volumineuse ;
• nombreuses destinations : stockage objet compatible S3, SFTP, Backblaze B2, serveur dédié avec rest-server, etc. ;
• un seul binaire, simple à installer et à mettre à jour.

BorgBackup est une excellente alternative, avec des principes proches. Il nécessite en revanche Borg installé côté destination, ce qui oriente plutôt vers un serveur de sauvegarde accessible en SSH ou un service spécialisé.

Un script de sauvegarde minimal

Voici la base que j’utilise, à adapter selon le serveur :

#!/usr/bin/env bash
set -euo pipefail
umask 077  # les exports SQL ne doivent être lisibles que par root

# Dépôt et mot de passe restic définis dans un fichier protégé (chmod 600)
source /root/.restic-env

# 1. Export des bases de données et de la liste des paquets
mkdir -p /var/backups/mysql
dpkg --get-selections > /var/backups/paquets.txt
mysqldump --single-transaction --quick --all-databases \
  | gzip > /var/backups/mysql/all-databases.sql.gz

# 2. Sauvegarde chiffrée et dédupliquée vers le stockage distant
restic backup /var/www /etc /var/spool/cron /var/backups --tag quotidien

# 3. Rétention : 7 jours, 4 semaines, 6 mois
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# 4. Signal de bonne exécution (voir plus bas)
curl -fsS --retry 3 https://hc-ping.com/VOTRE-IDENTIFIANT > /dev/null

Quelques détails qui comptent :

• set -euo pipefail fait échouer le script si une commande échoue, y compris au milieu d’un pipe. Sans pipefail, un mysqldump en erreur suivi de gzip passe pour un succès : on se retrouve avec des exports vides, en silence, pendant des mois.
• umask 077 garantit que l’export SQL, qui contient toutes vos données clients, n’est pas lisible par les autres utilisateurs du serveur.
• --single-transaction produit un export cohérent des tables InnoDB sans bloquer le site pendant la sauvegarde.
• Le fichier .restic-env contient export RESTIC_REPOSITORY=... et export RESTIC_PASSWORD=... (le export est indispensable pour que restic voie ces variables), plus les identifiants du stockage distant si besoin. Ce mot de passe doit aussi être conservé en dehors du serveur, dans un gestionnaire de mots de passe. Sans lui, les sauvegardes sont illisibles, y compris pour vous.

Le script est ensuite lancé chaque nuit par une tâche cron ou un timer systemd.

Être prévenu quand ça ne tourne pas

Le piège classique, c’est la sauvegarde qui s’arrête sans que personne ne s’en aperçoive : un disque plein, un mot de passe de base de données changé, un stockage distant arrivé à saturation.

Recevoir un email à chaque sauvegarde réussie ne fonctionne pas : au bout d’une semaine, plus personne ne les lit. Le bon principe est inverse : être alerté quand le signal de réussite n’arrive pas.

C’est le rôle de la dernière ligne du script. Des services comme Healthchecks.io (également auto-hébergeable) ou Uptime Kuma attendent un signal à intervalle régulier. S’il ne vient pas dans le délai prévu, ils envoient une alerte. Comme le script s’arrête à la première erreur, le signal n’est envoyé que si tout s’est bien passé.

Tester la restauration

C’est l’étape que presque tout le monde saute, et c’est la seule qui prouve que le reste fonctionne.

Vérifier l’intégrité du dépôt, par exemple une fois par semaine :

restic check --read-data-subset=5%

Restaurer réellement, au minimum une fois par trimestre, sur une machine ou un dossier de test :

restic restore latest --target /tmp/test-restauration

Puis contrôler concrètement :

• le dump SQL se décompresse et s’importe dans une base de test ;
• le nombre de commandes, d’articles ou de clients correspond à la production ;
• les médias récents sont bien présents ;
• le site démarre à partir de ces données.

Et surtout, chronométrez. Savoir qu’une restauration complète prend 40 minutes, c’est une information précieuse le jour où le site est en panne et que quelqu’un vous demande quand il reviendra.

Se protéger des rançongiciels

Un point souvent négligé : si votre serveur est compromis, l’attaquant dispose des mêmes accès que le script de sauvegarde. S’il peut écrire dans le dépôt, il peut aussi le supprimer.

Pour éviter ce scénario, la copie hors site doit être protégée contre la suppression depuis le serveur :

• rest-server en mode --append-only : le serveur peut ajouter des sauvegardes, mais pas en supprimer. L’étape 3 du script (forget --prune) doit alors être retirée et lancée depuis une autre machine, sinon elle échoue et le signal de réussite n’est jamais envoyé ;
• stockage objet avec versionnage et verrouillage (Object Lock) : les versions des fichiers ne peuvent pas être supprimées avant l’expiration d’une durée définie, même avec les identifiants du compte ;
• sauvegarde « tirée » : c’est une machine de sauvegarde qui vient chercher les données, et non le serveur qui les pousse. Le serveur de production n’a alors aucun accès au stockage.

Et le RGPD ?

Vos sauvegardes contiennent les mêmes données personnelles que votre production : comptes clients, adresses, historiques de commandes. Elles sont donc soumises aux mêmes obligations.

Concrètement :

• chiffrez-les, ce que restic fait par défaut ;
• privilégiez un stockage situé dans l’Union européenne ;
• définissez une durée de conservation cohérente, plutôt que de tout garder indéfiniment ;
• limitez les accès au dépôt et au mot de passe de chiffrement.

En résumé

• Appliquez la règle 3-2-1, avec une copie hors site chez un autre prestataire.
• Ne comptez pas uniquement sur les snapshots de l’hébergeur.
• Sauvegardez fichiers, bases de données et configuration.
• Faites échouer le script au moindre problème, et soyez alerté en cas d’absence de signal.
• Testez la restauration régulièrement et chronométrez-la.
• Protégez au moins une copie contre la suppression depuis le serveur.

Rien de tout ça n’est très complexe. Ce qui est difficile, c’est de le faire proprement une fois, puis de vérifier dans la durée que ça fonctionne toujours. C’est une partie centrale de mon infogérance serveur. Pour un site WordPress, les sauvegardes et leurs tests sont inclus dans l’infogérance WordPress, en complément des bons réflexes de sécurité.