La règle 3-2-1 des sauvegardes

La règle 3-2-1 tient en une phrase : trois copies des données, sur deux supports différents, dont une hors site. Elle reste utile parce qu'elle couvre les trois scénarios qui détruisent réellement les données : panne matérielle, erreur humaine et rançongiciel. Un snapshot du fournisseur est une copie, pas une stratégie complète.

Les trois dimensions

Un snapshot conservé sur le même stockage que le VPS ne compte pas comme second support : si le stockage disparaît, les deux copies disparaissent. Les sauvegardes incluses dans l'offre VPS sont un filet de sécurité utile, mais elles ne remplacent pas une copie dont vous contrôlez la destination et la rétention.

Produire une copie exploitable

Pour les fichiers, une archive datée suffit souvent. Pour une base, le dump doit être cohérent : --single-transaction évite de capturer un état intermédiaire.

sudo tar --one-file-system -czf /var/backups/www-$(date +%F).tar.gz /var/www /etc/nginx
mysqldump --single-transaction --routines --triggers -u backup -p base > /var/backups/base-$(date +%F).sql

Ces deux fichiers restent sur le VPS : ce n'est que la première copie. Envoyez-les ailleurs, idéalement avec un outil qui gère les incréments et la vérification d'intégrité, comme restic :

export RESTIC_REPOSITORY=sftp:backup@hote-sauvegarde:/srv/restic
restic init
restic backup /var/www /etc/nginx
restic check

Le mot de passe du dépôt restic ne doit pas être stocké dans Git ni dans le script cron. Placez-le dans un fichier lisible uniquement par root (chmod 600) et sauvegardez-le séparément : sans lui, le dépôt est illisible.

Chiffrer et définir la rétention

Chiffrez avant que la copie quitte le serveur. age ou gpg --symmetric --cipher-algo AES256 produisent un fichier protégé par une phrase secrète. La clé de déchiffrement doit être conservée ailleurs que la sauvegarde, sinon un vol du support donne accès aux deux.

Fixez une rétention réaliste : par exemple 7 copies quotidiennes, 4 hebdomadaires et 6 mensuelles. Vérifiez que la purge ne supprime jamais toutes les copies d'un même jour. Si votre stockage le permet, activez l'immutabilité ou un mode ajout seul : un rançongiciel qui atteint le serveur ne doit pas pouvoir chiffrer les sauvegardes montées.

Tester la restauration

Une sauvegarde non testée est une hypothèse. Restaurez dans un dossier temporaire, sans écraser la production :

restic restore latest --target /tmp/restore-test
restic check --read-data-subset=5%

Ouvrez ensuite un fichier au hasard, vérifiez la taille de l'arborescence, importez le dump SQL dans une base de test et démarrez l'application sur un port temporaire. Notez la durée de l'opération : c'est votre temps de reprise réel, souvent très supérieur à l'estimation.

Les erreurs qui annulent la règle

• Sauvegarder la base avec un simple copier-coller des fichiers MySQL, sans dump cohérent.
• Garder la clé de chiffrement sur le même serveur que les copies.
• Laisser un cron échouer silencieusement pendant des mois.
• Restaurer une sauvegarde sans vérifier qu'elle précède l'incident.
• Supprimer les anciennes copies avant d'avoir validé la nouvelle.

Un cron doit écrire un journal, retourner un code d'erreur explicite et alerter en cas d'échec. Une sauvegarde réussie se mesure à sa restauration, pas à la taille du fichier.