Une sauvegarde que tu n'as pas restaurée est une hypothèse

Le job de sauvegarde ici est banal : pg_dump -Fc depuis le conteneur de base en fonctionnement chaque nuit, une copie locale gardée sur une fenêtre de rétention, une copie expédiée vers un stockage objet hors site via l'API S3, les deux élaguées au-delà de la fenêtre. L'expédition hors site est obligatoire par défaut — le script refuse de tourner sans la config hors site à moins de la contourner explicitement, parce qu'une sauvegarde qui n'existe que sur le même disque que la base n'est presque pas une sauvegarde.

Cette partie est facile. La partie facile à sauter, c'est de prouver que quoi que ce soit marche.

Le job séparé qui compte vraiment

Un second workflow, sur son propre calendrier, télécharge la sauvegarde hors site la plus récente, la restaure dans un conteneur de base jetable — jamais le conteneur en direct — et affirme que quelques tables centrales reviennent avec au moins une ligne. Puis il démonte le conteneur.

C'est le job qui te dit quelque chose de vrai. pg_dump qui sort avec zéro te dit qu'un fichier a été écrit. Il ne te dit rien sur le fait que pg_restore acceptera ce fichier, que le schéma fait l'aller-retour, qu'un type ou une extension personnalisée manque du côté restauration, que la copie hors site s'est uploadée intacte. J'ai vu des scripts de restauration qui « marchaient » depuis des mois casser la première fois qu'ils ont été réellement lancés, parce que personne ne les avait lancés.

Des détails qui ont mordu

• Le script de restauration lance pg_restore --clean --if-exists et supprime et recrée le schéma cible. Pointe-le vers un nom de base jetable par config, toujours. Répéter une restauration contre la base en direct parce que tu as mal tapé une variable d'environnement est un incident auto-infligé.
• Marque le volume de base external: true dans le fichier compose de production, épinglé à son nom existant exact. Compose refuse alors de supprimer un volume qu'il ne possède pas — donc un down -v contre le mauvais fichier, ou une future erreur de nommage de projet, ne peut pas emporter les données. Ça ne protège pas contre un docker volume prune manuel ; rien au niveau config ne le fait complètement. La seule vraie protection là, c'est la règle : aucun élagage --volumes, jamais, sur une machine où le conteneur de base pourrait être momentanément arrêté.
• Fais alerter le cron de sauvegarde lui-même en cas d'échec. Le mien échouait silencieusement vers un fichier de log que personne ne lisait. Il poste maintenant sur un canal de discussion en cas d'échec, avec des appels autonomes pour ne pas dépendre de la présence d'un checkout du dépôt.