Sauvegardes de serveur : la règle 3-2-1 et la restauration

La règle 3-2-1 dit : gardez trois copies de vos données importantes (l'original et deux sauvegardes), sur deux types de stockage différents, avec au moins une copie conservée ailleurs. Sur un VPS, cela signifie avoir au moins une copie en dehors du serveur, en plus des données du serveur lui-même.

La même règle est recommandée dans le document Data Backup Options, rédigé pour l'US-CERT et publié sur le site de la CISA. Son but est qu'une seule panne, erreur ou attaque ne puisse pas détruire toutes les copies à la fois.

Sauvegarde, snapshot et redondance des disques ne sont pas la même chose

• Sauvegarde : une copie séparée de vos données, généralement avec des versions antérieures. Elle permet de retrouver un fichier supprimé ou abîmé par erreur.
• Snapshot : enregistre l'état du serveur à cet instant. Il est pratique pour revenir rapidement en arrière avant une grosse mise à jour. Mais il dépend du disque d'origine, il ne remplace donc pas une sauvegarde.
• Redondance des disques : les mêmes données écrites sur deux disques à la fois. Elle vous protège en cas de panne d'un disque. Un fichier que vous supprimez l'est sur les deux disques, et des données chiffrées par un rançongiciel le sont sur les deux. Ce n'est donc pas une sauvegarde.

Appliquer la règle 3-2-1 sur un VPS

Vous pouvez compter la sauvegarde quotidienne du panneau comme l'une de vos copies. Mais la copie qui remplit la condition « ailleurs » est celle que vous configurez et contrôlez vous-même. Les conditions d'utilisation de Seturack demandent aussi de conserver séparément une copie de vos données importantes.

Que sauvegarder

Copier les fichiers d'une base de données en cours d'exécution peut donner une sauvegarde incohérente. Faites d'abord un dump. Ces commandes s'exécutent en root, comme dans un script cron :

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Pour les fichiers, ceci suffit : /etc, les fichiers de votre site, le dossier de données de votre application, les volumes Docker si vous utilisez Docker, et les fichiers .env. Ne sauvegardez pas ce que vous pouvez télécharger de nouveau, comme les paquets et les images Docker. Si votre application a une clé de chiffrement, conservez-la aussi à part. Pour certaines applications, une sauvegarde sans la clé est inutilisable.

La fréquence des sauvegardes dépend de la quantité de données que vous pouvez vous permettre de perdre. Une sauvegarde par jour signifie perdre jusqu'à une journée de données dans le pire des cas. Pour une application qui enregistre des commandes ou des paiements, il est plus prudent de faire un dump de la base toutes les heures et de l'envoyer hors du serveur.

Une sauvegarde hors serveur avec restic

restic est un outil de sauvegarde open source qui chiffre vos sauvegardes et ne stocke qu'une fois les données répétées. L'exemple ci-dessous écrit la sauvegarde sur un autre serveur joint par SFTP. La cible doit accepter la connexion SSH sans mot de passe (par clé), car une sauvegarde automatique ne peut pas répondre à une demande de mot de passe. Créez le fichier de mot de passe (/root/.restic-password) dans un éditeur de texte et exécutez chmod 600 dessus.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

La documentation de restic prévient que si vous perdez le mot de passe, vos données sont perdues définitivement. Conservez aussi le mot de passe dans un gestionnaire de mots de passe. Placez dans un script, par exemple /usr/local/bin/backup.sh, les deux lignes export, les dumps de base de données, restic backup et restic forget, dans cet ordre, et rendez-le exécutable avec chmod +x. N'oubliez pas d'ajouter à la fin une ligne qui supprime les anciens dumps, find /var/backups -name '*.sql.gz' -mtime +2 -delete, sinon les fichiers de dump finiront par remplir le disque. Lancez ensuite le script chaque nuit, par exemple depuis /etc/cron.d/backup avec cette ligne :

30 3 * * * root /usr/local/bin/backup.sh

borg est un outil similaire. Pour de simples copies de fichiers, vous pouvez utiliser rsync, et rclone pour envoyer des données vers un stockage objet.

Le vrai test : restaurer

Une sauvegarde que vous ne pouvez pas restaurer ne vaut rien. Essayez juste après la mise en place, puis à intervalles réguliers :

• Avec restic, extrayez la dernière sauvegarde dans un dossier vide et vérifiez les fichiers : restic restore latest --target /tmp/restore-test
• Chargez un dump de base de données dans une base temporaire et examinez les tables.
• Dans le panneau, cliquez sur l'icône Récupérer des fichiers à côté d'une sauvegarde, parcourez le contenu et téléchargez un fichier. Une restauration complète remplace l'intégralité du disque actuel : récupérer un seul fichier est donc la façon la plus sûre de tester.

Choisissez la durée de conservation selon le temps que vous pouvez mettre à remarquer un problème. La sauvegarde du panneau conserve les 7 derniers jours, et vous ne pouvez pas remonter plus loin. Si vous risquez d'avoir besoin de versions plus anciennes, conservez des versions hebdomadaires et mensuelles dans votre propre copie. Pour le détail de la sauvegarde du panneau, consultez l'article sur les sauvegardes quotidiennes.

Erreurs courantes

• Écrire la sauvegarde sur le disque du même serveur. Si le disque se remplit ou si le serveur est perdu, la sauvegarde disparaît avec lui.
• Garder le mot de passe ou la clé de la sauvegarde au même endroit que la sauvegarde.
• Ne pas remarquer que le script échoue. Ajoutez une notification au script, ou vérifiez de temps en temps la date de la dernière sauvegarde avec restic snapshots.
• Ne pas surveiller le remplissage de la cible de sauvegarde. Une cible pleine, ce sont des sauvegardes qui échouent en silence.