Sauvegarder un serveur à soi : ce qui casse vraiment

En bref

• La règle 3-2-1 : trois copies des données, sur deux supports, dont une hors ligne, et au moins une sur un autre site.
• Une base de données se sauvegarde avec ses propres outils, jamais en copiant son dossier pendant qu’elle tourne.
• Une sauvegarde n’existe qu’une fois restaurée, et la restauration se juge sur le contenu, pas sur le code de retour.
• Sur un serveur de production, pas de nettoyage global : un inventaire écrit des services et de leurs volumes, et des commandes ciblées.

Pourquoi une sauvegarde qui tourne ne suffit pas

Sauvegarder un serveur auto-hébergé tient en une règle connue : trois copies, deux supports, une copie à l’écart. Ce qui protège vraiment, c’est d’y ajouter des restaurations essayées pour de vrai. Tout le reste est du détail d’exécution, mais c’est dans ce détail que les données se perdent.

Notre serveur fait tourner une douzaine de services en conteneurs Docker pour cinq entreprises clientes, derrière un routeur Traefik : le CRM Twenty, l’automatisation n8n, les statistiques Matomo, la signature électronique, la facturation et des modèles d’IA. Ce qui suit vient de cette exploitation, y compris de nos erreurs, et ce sont les règles de notre sortie du SaaS, livrée avec des sauvegardes automatiques hors du serveur et une restauration testée.

La règle 3-2-1, et ce qu’elle ne dit pas

La CNIL la présente comme l’état de l’art dans sa fiche sur la sauvegarde des données : trois copies des données, sur deux supports différents, dont une hors ligne. La même fiche recommande d’en garder au moins une sur un site géographiquement distinct, et met en garde contre des sauvegardes conservées sur les mêmes systèmes que les données sans être isolées : un rançongiciel pourrait alors atteindre les unes comme les autres.

Pour un serveur loué, cela donne concrètement :

1. les données vivantes sur le serveur ;
2. une sauvegarde sur un autre stockage, chez le même hébergeur ou non ;
3. une copie chez un autre fournisseur, dans un autre lieu, sur un compte dont les identifiants ne sont pas sur le serveur, et, pour la copie hors ligne, un support déconnecté que rien sur le serveur ne peut atteindre.

Ce dernier point compte : si un attaquant ou une erreur de script obtient les droits sur le serveur, il ne doit pas pouvoir effacer la copie distante avec les mêmes clés.

Ce que la règle ne dit pas, c’est comment copier une base de données en cours d’utilisation, ni comment savoir que la copie sert à quelque chose. C’est là que ça casse.

Ce qui casse vraiment

1. La base copiée comme un simple dossier

Copier le répertoire de données d’une base PostgreSQL pendant qu’elle tourne ne donne pas une sauvegarde fiable. La documentation de PostgreSQL sur la sauvegarde des fichiers le dit sans détour : le serveur de base doit être arrêté pour obtenir une copie utilisable, à moins de passer par un instantané cohérent du volume. Une base se sauvegarde donc avec ses propres outils : un export logique (pg_dump) pour les petites bases, ou une sauvegarde de base complétée par l’archivage continu du journal de transactions pour les plus grosses.

Ce second mécanisme permet de revenir à un instant précis. La documentation de PostgreSQL sur l’archivage continu l’explique : en rejouant le journal jusqu’au moment voulu, on retrouve la base telle qu’elle était à n’importe quel instant depuis la sauvegarde de base. Elle précise aussi qu’il faut mettre en place et tester l’archivage du journal avant de faire la première sauvegarde de base. Le mot « tester » est dans la documentation officielle : ce n’est pas une précaution d’agence.

2. Le volume oublié

Avec Docker, les données utiles vivent dans des volumes ou des dossiers montés. Un service ajouté en vitesse, avec un volume que personne n’a ajouté au script de sauvegarde, et le jour de la panne on découvre qu’il n’a jamais été copié. La parade est bête et efficace : une liste écrite des services, de leurs volumes et de leur méthode de sauvegarde, relue à chaque ajout de service.

3. La commande de nettoyage global

C’est notre erreur, et nous la racontons parce qu’elle est instructive. En juillet 2026, une commande docker system prune a supprimé les conteneurs de dix services sur notre serveur. La documentation de docker system prune est pourtant claire : par défaut, elle supprime tous les conteneurs arrêtés, les réseaux qu’aucun conteneur n’utilise, les images orphelines (sans étiquette) et le cache de construction inutilisé ; avec l’option --all, toutes les images inutilisées. Sur un serveur où un service est momentanément arrêté, « inutilisé » peut vouloir dire « en production, mais pas à cet instant ».

Les volumes ne sont pas supprimés par défaut, pour ne pas effacer des données importantes qu’aucun conteneur n’utilise à cet instant : c’est ce qui a sauvé nos données. Avec l’option --volumes, ce n’est plus vrai pour les volumes anonymes.

Ce qui est sorti de cet incident, ce sont des règles écrites, pas une promesse de faire attention : des politiques de redémarrage et des règles qui encadrent les commandes destructrices. Notre conseil : sur un serveur de production, pas de nettoyage global, un nettoyage ciblé à la place, et un inventaire des services à jour. Un incident qui ne laisse pas de règle écrite se reproduira.

4. La sauvegarde jamais restaurée

Le cas le plus silencieux. Le script tourne chaque nuit, il ne signale aucune erreur, et personne n’a jamais vérifié que l’archive se décompresse, que la base se recharge, que l’application démarre dessus. Une sauvegarde n’existe qu’à partir du jour où elle a été restaurée avec succès.

Et le succès se juge sur le contenu, pas sur le code de retour. Sur l’un des projets que nous opérons, l’outil de restauration renvoyait une erreur pour de simples avertissements : nous validons donc une restauration sur le nombre de tables et d’enregistrements retrouvés.

5. L’alerte qui ne part pas

Un script de sauvegarde qui échoue sans prévenir est pire qu’une absence de script, parce qu’il donne une fausse assurance. Chaque sauvegarde doit envoyer un signal en cas d’échec, et idéalement un signal quand elle n’a pas tourné du tout.

La procédure que nous recommandons

Pour une PME qui fait tourner quelques services sur un serveur à elle :

• Chaque nuit : export de chaque base avec son outil, copie des volumes listés, envoi chiffré vers un stockage distant avec ses propres identifiants.
• Chaque semaine : vérification automatique que les fichiers de la nuit existent, ont une taille plausible et se décompressent.
• Chaque trimestre : restauration complète d’un service dans un conteneur jetable ou sur une machine de test, chronométrée et validée sur le contenu. Le temps mesuré devient votre délai réel de reprise, celui que vous pouvez annoncer à la direction.
• À chaque nouveau service : mise à jour de l’inventaire et du script, avant la mise en production, pas après.
• Rétention : des copies quotidiennes sur quelques semaines, des copies mensuelles plus longtemps. La durée dépend de vos obligations et de vos données personnelles : garder des données plus longtemps que nécessaire n’est pas une sécurité, c’est une dette.

Les limites honnêtes

Cette procédure protège contre la perte de données. Elle ne garantit pas la disponibilité : restaurer un service prend du temps, et pendant ce temps il est arrêté. Si votre activité ne supporte pas quelques heures d’interruption, il faut de la redondance (un second serveur prêt à prendre le relais), ce qui change le coût. C’est une ligne à intégrer dans le calcul du coût réel de sortie du SaaS sur trois ans.

Et un hébergeur qui « fait les sauvegardes » ne vous dispense pas de cette discipline. Lisez ce que son offre couvre : fréquence, durée de rétention, restauration à la demande ou non, et surtout ce que vous pouvez restaurer vous-même.

Par où commencer

Écrivez l’inventaire : chaque service, sa base, ses volumes et sa méthode de sauvegarde. Puis restaurez un service complet, même petit, et notez le temps que ça prend. Les sauvegardes ne sont qu’une brique du socle d’infrastructure commun à vos projets, à côté des accès, de la surveillance et des budgets. Si vous n’avez pas encore de serveur, commencez par un outil peu critique, comme le conseille notre guide des outils à auto-héberger en premier. Pour déléguer, l’infogérance de notre sortie du SaaS couvre la supervision, les mises à jour et des sauvegardes testées. Les autres sujets d’exploitation sont dans notre rubrique infrastructure et cloud.

Questions fréquentes

Qu’est-ce que la règle 3-2-1 de sauvegarde ?

C’est la règle que la CNIL présente comme l’état de l’art : trois copies des données, sur deux supports différents, dont une hors ligne. Sa fiche recommande aussi d’en garder au moins une sur un site géographiquement distinct. Pour un serveur loué, la copie hors ligne est la plus difficile à tenir, et c’est pourtant elle qui reste hors d’atteinte d’un rançongiciel.

À quelle fréquence tester la restauration ?

La CNIL demande de tester régulièrement l’intégrité des sauvegardes et la capacité de les restaurer, sans fixer de rythme. Nous recommandons une vérification automatique chaque semaine et un exercice complet chaque trimestre, chronométré. Le bon rythme reste celui que vous tenez vraiment : un test annuel fait vaut mieux qu’un test mensuel prévu.

Comment sauvegarder des conteneurs Docker et leurs bases de données ?

On ne sauvegarde pas les conteneurs, on sauvegarde leurs données : les bases avec leurs propres outils d’export, les volumes et dossiers montés par copie, et les fichiers de configuration dans un dépôt versionné. Un conteneur se reconstruit, une base perdue ne se reconstruit pas. Tenez une liste écrite des services et de leurs volumes, relue à chaque ajout.

Qui est responsable si l’hébergeur perd mes données ?

Cela dépend de votre contrat : lisez ce que l’offre dit des sauvegardes, de leur fréquence, de leur durée de conservation et de la responsabilité de l’hébergeur en cas de perte. Le plus sûr reste de ne pas dépendre de cette réponse : gardez une copie chez un autre fournisseur, avec des identifiants distincts, et vérifiez que vous savez la restaurer vous-même.