L’image disque d’une VM ne remplace pas une copie logique de PostgreSQL. Le jour où l’on reconstruit le service sur une machine neuve, il faut un fichier que l’on peut restaurer dans un PostgreSQL vide, et ce fichier ne doit pas rester sur le disque qui vient de lâcher.
Produire le fichier
Le format personnalisé de pg_dump se restaure avec pg_restore et permet de choisir une table si besoin.
pg_dump -Fc --no-owner --dbname="$DATABASE_URL" \
--file="/var/backups/app-$(date +%F).dump"Le fichier contient les données. On le chiffre avant de le faire sortir du serveur, par exemple avec gpg --symmetric. La phrase de passe est dans un fichier lisible seulement par root, pas dans la crontab en clair et pas dans le dépôt.
L’envoyer ailleurs
La destination est un bucket R2, une zone Bunny Storage, ou un autre dépôt qui ne dépend pas du VPS. L’outil d’envoi (rclone, l’API S3, le client du fournisseur) utilise une clé limitée à ce bucket. On garde plusieurs dates. Écraser chaque nuit le même objet unique revient à n’avoir aucune historique le jour où la corruption date d’avant-hier.
Ce n’est pas la réplication vers une base de développement. Cette réplication, déjà décrite sur le blog, alimente un poste de travail. Elle ne constitue pas une sauvegarde : une erreur SQL rejouée sur la cible copie aussi l’erreur.
Restaurer sur une base vide
Une fois par mois, on télécharge une archive, on la déchiffre, et on la charge dans une base de test créée pour l’occasion.
pg_restore --no-owner --dbname="app_restauration" app.dumpOn compte les tables, on ouvre l’application de test, on vérifie qu’une fiche récente est là. Une sauvegarde que personne n’a restaurée n’est qu’un fichier. L’image Proxmox, traitée dans l’article sur la copie hors du VPS, reste utile pour reconstruire la machine autour.
