Un plan de sauvegarde pour votre serveur

Module 8: Sauvegardes et surveillance · Temps de lecture : 11 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez établir un plan de sauvegarde pour votre propre serveur : ce que vous conservez, où, à quelle fréquence et pendant combien de temps, et comment vous assurer que la restauration fonctionne.

Notions clés : règle 3-2-1, snapshot, sauvegarde de l'hébergeur, sauvegarde personnelle hors de l'hébergeur, RPO, RTO, dump de base de données (mariadb-dump, pg_dump), configuration dans /etc, volumes Docker, chiffrement, ransomware, append-only, test de restauration

Pourquoi un plan, et pas simplement « il y a bien une sauvegarde » ?

Presque tous ceux qui ont perdu un serveur pensaient avoir une sauvegarde. On découvre alors qu'elle ne contient que le système d'exploitation et pas la base de données, ou qu'elle se trouve sur le serveur même qui a disparu, ou qu'elle a été chiffrée par le même ransomware, ou que personne ne connaît le mot de passe. Une sauvegarde ne vaut quelque chose que si vous pouvez la restaurer. C'est pourquoi vous commencez par un plan et terminez par un test.

Un plan répond à cinq questions :

1. Que faut-il pouvoir restaurer ?
2. Combien de données pouvez-vous vous permettre de perdre ? (RPO)
3. En combien de temps tout doit-il refonctionner ? (RTO)
4. Où se trouvent les copies, et combien y en a-t-il ?
5. Comment savez-vous que cela fonctionne ?

Que faut-il pouvoir restaurer ?

Un serveur se compose de plusieurs couches. Toutes n'ont pas besoin d'être sauvegardées :

Faites particulièrement attention aux bases de données. Une base de données en fonctionnement écrit en permanence. Si vous copiez les fichiers d'un MariaDB ou d'un PostgreSQL en cours d'exécution, vous risquez d'obtenir une copie endommagée. Faites donc d'abord un dump : un instantané cohérent sous forme de fichier, que vous incluez ensuite dans la sauvegarde.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump s'appelait autrefois mysqldump ; cette commande fonctionne généralement encore.) Si la base de données tourne dans un conteneur, vous faites la même chose avec docker compose exec (leçon 9.4).

RPO et RTO : combien pouvez-vous perdre ?

Deux notions issues de la pratique professionnelle vous aident à faire des choix :

• RPO (recovery point objective) : quelle durée de données pouvez-vous perdre au maximum ? Une sauvegarde quotidienne à 03:00 signifie que si le serveur plante à 22:00, vous perdez presque une journée. Pour une boutique en ligne qui reçoit des commandes, c'est trop ; pour un blog qui change une fois par semaine, c'est parfait.
• RTO (recovery time objective) : combien de temps peut-il s'écouler avant que tout refonctionne ? Restaurer une sauvegarde complète de l'hébergeur peut prendre quelques minutes ; monter un nouveau serveur et tout restaurer à la main peut prendre des heures.

Notez-les pour votre propre serveur. Ils déterminent la fréquence de vos sauvegardes et la manière de les conserver.

Snapshot, sauvegarde de l'hébergeur, sauvegarde personnelle

Sur un VPS, vous disposez généralement de trois types de filet de sécurité. Ils se ressemblent, mais ne protègent pas contre les mêmes choses.

1. Le snapshot. Un instantané de l'ensemble du disque virtuel, réalisé dans le panneau de votre hébergeur. Rapide à créer, rapide à restaurer. Idéal juste avant une mise à niveau (leçon 4.3). Mais chez la plupart des hébergeurs, un snapshot se trouve sur le même stockage que votre serveur. Si ce stockage tombe en panne, ou si vous perdez votre compte, le snapshot disparaît aussi. Et un snapshot ne se conserve pas longtemps : il grossit avec toutes les modifications ultérieures. Un snapshot n'est pas une sauvegarde.

2. La sauvegarde de l'hébergeur. De nombreux hébergeurs réalisent (éventuellement en option) une copie automatique quotidienne de votre serveur entier, sur un autre stockage. Chez WebOké, il s'agit par exemple d'une sauvegarde quotidienne du VPS complet, conservée sept jours ; chez d'autres hébergeurs, le principe est comparable, avec leurs propres durées. C'est une bonne deuxième couche contre les pannes matérielles et contre vos propres erreurs de la veille. Mais cela reste un seul prestataire : votre compte, votre paiement, leur panne. Et la restauration porte généralement sur le serveur entier en une fois.

3. Votre propre sauvegarde, hors de l'hébergeur. Une copie de vos données chez un autre prestataire ou dans un autre lieu, que vous créez et gérez vous-même (leçon 8.2). C'est la couche qui reste quand tout le reste a échoué.

La règle 3-2-1

Une règle empirique courante :

• 3 copies de vos données (l'original plus deux sauvegardes) ;
• sur 2 types de stockage ou systèmes différents ;
• dont 1 dans un autre lieu.

Pour un VPS, cela peut donner : les données sur le serveur, la sauvegarde quotidienne de l'hébergeur et une sauvegarde personnelle chiffrée avec restic vers un stockage chez un autre prestataire. Un complément moderne consiste à ce qu'au moins une copie ne puisse pas être effacée par quiconque prend le contrôle du serveur (hors ligne, ou append-only, leçon 8.2). Un ransomware présent sur un serveur recherche activement les sauvegardes pour les chiffrer ou les effacer elles aussi. Une sauvegarde que le serveur lui-même a le droit d'effacer n'offre aucune protection contre cela.

Le chiffrement et le mot de passe de votre sauvegarde

Une sauvegarde stockée chez un autre prestataire doit être chiffrée : elle contient des données clients, des mots de passe et des clés. restic (leçon 8.2) chiffre par défaut. Mais cela crée un nouveau risque : le mot de passe de votre sauvegarde. Si vous le perdez, la sauvegarde devient inutilisable. Et s'il ne se trouve que sur le serveur que vous avez perdu, c'est la même chose.

Conservez donc aussi ce mot de passe hors du serveur : dans votre gestionnaire de mots de passe, et éventuellement sur papier dans un coffre-fort. Il en va de même pour les identifiants d'accès au stockage où se trouve votre sauvegarde.

Tester la restauration

C'est la partie la plus importante du plan. Un test de restauration signifie que vous restaurez réellement une sauvegarde, à un endroit où cela ne casse rien, et que vous vérifiez que le résultat fonctionne.

• Petit et souvent : restaurer un seul fichier ou un seul dossier dans /tmp/terug et comparer (diff). Par exemple chaque mois.
• Grand et de temps en temps : monter un serveur de test complet à partir de la sauvegarde, importer la base de données, démarrer le site web. Par exemple une fois par an, ou à chaque modification importante. C'est en même temps l'entraînement pour le jour où tout tourne vraiment mal (leçon 10.3).

Notez le temps que cela a pris : c'est votre RTO réel.

Durées de conservation

Ne conservez pas uniquement la dernière sauvegarde. Si vous ne découvrez qu'au bout de deux semaines qu'un fichier a été endommagé ou supprimé, il vous faut une sauvegarde d'il y a trois semaines. Un schéma courant : sept versions quotidiennes, quatre hebdomadaires et six mensuelles. restic gère cela avec forget (leçon 8.2). Pensez aussi au RGPD : vous ne conservez pas les données personnelles plus longtemps que nécessaire, y compris dans les sauvegardes. Consignez vos durées de conservation.

En pratique

Utilisez le snapshot de votre hébergeur juste avant des modifications risquées et supprimez-le ensuite ; laissez activée la sauvegarde quotidienne de l'hébergeur si elle existe ; et réalisez en plus votre propre sauvegarde chiffrée des données et de la configuration vers un autre prestataire. Chez WebOké, cela s'appelle Snapshots et Backups dans l'écran du VPS ; chez d'autres hébergeurs, les noms et les durées diffèrent, mais le principe est le même. Un pack d'hébergement ou un service géré prévoit souvent d'autres modalités : vérifiez ce qui est prévu dans votre cas.

Résumé

• Une sauvegarde ne vaut quelque chose que si la restauration fonctionne ; commencez par un plan et terminez par un test.
• Sauvegardez surtout les données et la configuration : les bases de données sous forme de dump, /etc, les sites web, les volumes Docker, les fichiers compose.
• Déterminez le RPO (combien vous pouvez perdre) et le RTO (en combien de temps tout doit refonctionner).
• Le snapshot (même stockage, court terme), la sauvegarde de l'hébergeur (autre stockage, même prestataire) et une sauvegarde personnelle hors de l'hébergeur sont trois couches différentes ; appliquez la règle 3-2-1 avec au moins une copie que le serveur lui-même ne peut pas effacer.
• Chiffrez, conservez le mot de passe de sauvegarde hors du serveur, et testez la restauration : en petit et souvent, en grand de temps en temps.

Quiz

Exercice

Exercice O8.1 : Votre plan de sauvegarde. Rédigez pour votre propre serveur un plan de sauvegarde tenant sur une seule page : ce qu'il faut pouvoir restaurer (par couche), votre RPO et votre RTO, les copies dont vous disposez (snapshot, hébergeur, personnelle) et où elles se trouvent, vos durées de conservation, l'endroit où se trouve le mot de passe de sauvegarde, et quand vous effectuez un test de restauration. Remplissez le formulaire ; après l'envoi, vous verrez un exemple de plan à comparer avec le vôtre.

Pour aller plus loin

• Snapshots et sauvegardes de votre VPS
• Stratégie de sauvegarde : la règle du 3-2-1 pour votre propre entreprise
• Comment faire une sauvegarde de ma base de données MySQL ?
• Dans la formation « Sécurité en ligne » : les leçons sur la règle 3-2-1 et sur les sauvegardes qui résistent aux ransomwares.
• MariaDB, mariadb-dump : https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump) : https://www.postgresql.org/docs/current/backup-dump.html