J’ai cru sauvegarder Postgres pendant 2 ans — la nuit où la restauration a échoué, et les 7 étapes qui ont corrigé ça

Le disque a lâché un mardi à 23 h 40. Nous avions un dump quotidien depuis deux ans, un script propre, une tâche planifiée qui n’avait jamais échoué, et des fichiers bien rangés dans un répertoire. J’étais tranquille pendant exactement onze minutes — le temps de lancer la restauration.

Le dump se restaurait. Partiellement. Une extension présente en production n’était pas installée sur la machine de secours, et l’import s’arrêtait au milieu, laissant une base à moitié peuplée dans un état que personne n’aurait su qualifier. Il a fallu deux heures pour comprendre, et la sauvegarde la plus récente datait de la veille au soir : dix-neuf heures de données perdues sur un service de facturation.

Personne n’avait été négligent. Le script fonctionnait. C’est exactement le piège : un dispositif de sauvegarde peut réussir tous les jours pendant deux ans et être inutile la seule nuit qui compte. Voici la méthode que j’applique depuis, dans l’ordre, et ce qu’elle coûte réellement.

Étape 1 — Écrire les deux nombres avant de toucher à un outil

La quasi-totalité des dispositifs de sauvegarde défaillants que j’ai vus partagent une même origine : ils ont été conçus en partant de l’outil, jamais de l’exigence. Avant toute chose, il faut écrire deux nombres et les faire valider par quelqu’un qui porte la responsabilité du service.

Combien de données acceptez-vous de perdre ? Exprimé en minutes. Sur un blog, vingt-quatre heures sont tolérables. Sur de la facturation, quinze minutes sont déjà douloureuses. Ce nombre détermine à lui seul si un dump quotidien peut convenir ou si l’archivage continu est obligatoire.

En combien de temps devez-vous être de retour ? Exprimé en heures. Ce nombre détermine la technique : restaurer cent gigaoctets depuis un dump logique prend des heures, depuis une sauvegarde physique quelques dizaines de minutes.

La conversation est parfois inconfortable, parce que la première réponse spontanée est toujours « zéro perte, retour immédiat », et que le budget correspondant fait reculer. C’est précisément l’intérêt de l’exercice : il transforme une exigence implicite en arbitrage explicite et assumé.

Étape 2 — Passer du dump logique à la sauvegarde physique

Le dump logique produit un fichier d’instructions SQL. C’est excellent pour migrer entre versions majeures ou pour inspecter le contenu, et c’est un mauvais outil de reprise après incident dès que la base dépasse quelques gigaoctets, parce que la restauration doit rejouer chaque insertion et reconstruire chaque index.

La sauvegarde physique copie les fichiers de données de l’instance. La restauration consiste alors à remettre ces fichiers en place et à démarrer — sans rejeu, sans reconstruction d’index. L’outil que je recommande pour l’auto-hébergement est pgBackRest : il gère la sauvegarde complète, incrémentale et différentielle, la compression, le chiffrement, la rétention et l’envoi vers un stockage objet, en un seul fichier de configuration.

Gardez néanmoins un dump logique hebdomadaire en parallèle. Il coûte peu et il vous sauvera dans un cas précis que la sauvegarde physique ne couvre pas : la corruption logique silencieuse, où les fichiers sont parfaitement sains mais contiennent des données fausses depuis trois semaines. C’est aussi votre seule porte de sortie si vous devez changer de version majeure dans l’urgence.

Étape 3 — Activer l’archivage continu des journaux WAL

C’est l’étape qui change tout, et c’est celle que la plupart des équipes auto-hébergées n’ont jamais franchie.

PostgreSQL écrit chaque modification dans un journal des écritures anticipées, le WAL, avant de l’appliquer aux fichiers de données. Si vous archivez ce journal en continu vers un stockage externe, vous pouvez repartir d’une sauvegarde physique de la nuit et rejouer les transactions jusqu’à un instant précis — par exemple juste avant la requête de suppression malencontreuse de 14 h 32.

Cette capacité change la nature des incidents que vous savez traiter. Sans elle, une suppression accidentelle de données à midi vous ramène à la sauvegarde de la nuit : vous perdez la matinée entière. Avec elle, vous perdez les quelques secondes qui séparent la suppression du point de restauration choisi.

Un piège de configuration mérite d’être signalé : si l’archivage échoue — stockage plein, identifiants expirés — PostgreSQL conserve les journaux localement en attendant, et remplit progressivement le disque de la machine de production. Un archivage cassé non supervisé finit par provoquer l’incident qu’il devait aider à traiter. Nous y revenons à l’étape 7.

Étape 4 — Sortir les sauvegardes de la machine et les chiffrer

Une sauvegarde stockée sur le même serveur que la base protège d’une seule chose : l’erreur humaine sur les données. Elle ne protège ni de la panne matérielle, ni de la suppression du serveur, ni d’un rançongiciel qui chiffrera les deux avec le même bonheur.

Poussez vos sauvegardes et vos journaux archivés vers un stockage objet chez un fournisseur différent de celui qui héberge le VPS. Le point important est la séparation des comptes : si les identifiants de votre machine compromise permettent d’effacer les sauvegardes, vous n’avez pas de sauvegarde hors site, vous avez une copie synchronisée. Utilisez des identifiants dédiés, en écriture seule si votre fournisseur le permet, et activez le verrouillage d’objet quand il est disponible.

Chiffrez côté client, avant l’envoi. La clé ne doit exister ni sur le serveur de production ni chez l’hébergeur du stockage — sinon le chiffrement ne protège que des curieux. Et testez la procédure de récupération de cette clé : une sauvegarde chiffrée dont la clé a disparu est mathématiquement équivalente à une absence de sauvegarde.

Étape 5 — Restaurer une première fois, manuellement et intégralement

Avant toute automatisation, faites-le à la main, en entier, sur une machine neuve, en chronométrant. Cette première restauration manuelle est le moment où vous découvrez tout ce que votre documentation ne dit pas.

Dans mon cas, elle a révélé quatre écarts en une soirée : une extension absente, un rôle référencé mais jamais créé sur la machine de secours, une version mineure de PostgreSQL différente, et un paramètre de locale qui changeait l’ordre de tri des index. Aucun de ces quatre points n’était documenté nulle part. Tous auraient fait échouer une restauration d’urgence.

Écrivez la procédure pendant que vous l’exécutez, pas après. Et écrivez-la pour quelqu’un qui la lira à trois heures du matin, sous stress, sans contexte : chaque commande explicite, aucun « puis configurez normalement ». La qualité de ce document conditionne votre temps de retour bien plus que la performance de votre outil.

Étape 6 — Automatiser le test de restauration hebdomadaire

C’est l’étape qui distingue un dispositif crédible d’un dispositif décoratif, et c’est la moins souvent mise en place parce qu’elle ne produit rien de visible quand tout va bien.

Le mécanisme est simple : une tâche hebdomadaire provisionne un conteneur ou une machine éphémère, restaure la dernière sauvegarde, rejoue les journaux jusqu’au point le plus récent, exécute une poignée de requêtes de vérification, puis détruit la machine. Un échec à n’importe quelle étape produit une alerte.

Les requêtes de vérification sont le détail qui compte. Ne vous contentez pas de vérifier que l’instance démarre : une base vide démarre parfaitement. Vérifiez un nombre de lignes sur vos deux ou trois tables principales, la présence de l’enregistrement le plus récent, et la cohérence d’un agrégat métier — un total de facturation, par exemple. Ce sont ces contrôles qui détectent une restauration techniquement réussie mais fonctionnellement vide.

La logique est exactement celle que nous appliquons aux chaînes d’intégration continue, et elle rejoint la discipline de cloisonnement décrite dans notre analyse de l’attaque de chaîne d’approvisionnement Rust : une machine jetable, des droits minimaux, aucun secret de production monté.

Étape 7 — Superviser la fraîcheur, pas le succès du script

Presque toutes les supervisions de sauvegarde que je rencontre surveillent la mauvaise chose : le code de retour de la tâche planifiée. Ce signal est trompeur, parce qu’un script peut se terminer proprement en n’ayant rien sauvegardé du tout.

La métrique juste est l’âge de la dernière sauvegarde valide, mesuré depuis le stockage hors site, pas depuis la machine qui produit la sauvegarde. Si cet âge dépasse le seuil que vous avez défini à l’étape 1, une alerte se déclenche — que le script ait réussi, échoué ou n’ait jamais démarré.

Ajoutez deux surveillances complémentaires : le retard d’archivage des journaux WAL, qui détecte l’archivage cassé avant qu’il ne remplisse le disque de production, et la date du dernier test de restauration réussi, qui vous évite de découvrir six mois plus tard que le test hebdomadaire échoue silencieusement depuis février.

Trois métriques, trois seuils, trois alertes. C’est tout le dispositif de supervision nécessaire, et il tient dans une demi-journée de mise en place.

Ce que ça coûte réellement, et ce que ça rapporte

Cinq jours-homme, une dizaine d’euros par mois de stockage, et un coût récurrent quasi nul une fois le test automatisé en place. À comparer aux dix-neuf heures de données de facturation que nous avons perdues, et aux deux journées passées à en reconstruire une partie à la main depuis des exports comptables.

Si vous auto-hébergez plus largement, cette brique s’articule naturellement avec le reste : notre guide sur le remplacement de Vercel par Coolify auto-hébergé couvre le dimensionnement du VPS et la bascule DNS, et le parcours Comment créer une application fintech applique les mêmes exigences de restauration aux volumes de données d’entraînement.

Sur le volet réglementaire, enfin, la capacité à restaurer dans un délai défini n’est plus seulement une bonne pratique d’exploitation : les équipes de WebGuard Agency rappellent régulièrement qu’elle est explicitement attendue dans les référentiels de continuité d’activité auxquels les PME sont désormais confrontées.

Questions fréquentes