Sauvegarder PostgreSQL sur un VPS
pg_dump, cron, et pourquoi ça ne suffit pas en production.
Vous hébergez PostgreSQL sur un VPS (OVH, Scaleway, Hetzner, DigitalOcean) et vous voulez des sauvegardes automatiques. Voici la méthode classique avec pg_dump et cron, puis ses limites réelles en production.
Tout le code ci-dessous fonctionne sur une distribution Linux standard avec le client PostgreSQL installé (paquet postgresql-client).
1. Sauvegarder une base avec pg_dump
pg_dump exporte une base PostgreSQL dans un fichier. Le format personnalisé (-Fc) est compressé et se restaure avec pg_restore, base par base.
pg_dump -Fc -U postgres -h localhost ma_base > /var/backups/ma_base_$(date +%F).dump
Pour toutes les bases d'un coup, utilisez pg_dumpall (format SQL, non compressé).
2. Automatiser avec cron
Placez la commande dans un script, ajoutez une rétention, rendez-le exécutable, puis planifiez-le dans la crontab.
#!/usr/bin/env bash
set -euo pipefail
DEST=/var/backups/postgres
mkdir -p "$DEST"
pg_dump -Fc -U postgres ma_base > "$DEST/ma_base_$(date +%F_%H%M).dump"
# rétention : supprimer les dumps de plus de 7 jours
find "$DEST" -name '*.dump' -mtime +7 -delete
Puis, dans crontab -e : 0 3 * * * /usr/local/bin/backup-pg.sh (tous les jours à 3 h).
3. Chiffrer et externaliser la sauvegarde
Un dump en clair, sur le même serveur que la base, ne protège de rien. Chiffrez-le et copiez-le ailleurs : un autre fournisseur, une autre région, un bucket S3.
age est un outil de chiffrement moderne, simple et robuste, parfait pour ça.
# chiffrer le dump avec age, puis l'envoyer vers un bucket S3
age -r age1exemple... -o ma_base.dump.age ma_base.dump
aws s3 cp ma_base.dump.age s3://mon-bucket/postgres/
4. Restaurer
Pour restaurer, déchiffrez le dump puis rejouez-le avec pg_restore dans une base cible. Testez toujours la restauration dans une base séparée, jamais en production.
age -d -i ma_cle.txt -o ma_base.dump ma_base.dump.age
pg_restore -U postgres -d ma_base_restauree --clean ma_base.dump
Les limites de pg_dump + cron
- Un cron qui échoue le fait en silence : vous ne le découvrez que le jour de la restauration.
- Aucune alerte si le VPS est éteint, si le disque est plein, ou si pg_dump plante.
- Rétention, chiffrement, envoi hors-site et rotation des clés sont à écrire et maintenir à la main.
- Une sauvegarde jamais testée n'est qu'un espoir, pas une garantie.
- Si le VPS brûle ou est compromis, les dumps stockés à côté disparaissent avec lui.
Faites-le en 5 minutes avec rlbk
rlbk installe un agent léger sur votre VPS, planifie vos sauvegardes PostgreSQL, les chiffre avec age directement sur le serveur, les envoie chez rlbk ou dans votre propre bucket S3, et vous alerte au moindre échec.
Vos données ne transitent que chiffrées, et vous pouvez tester une restauration dans un environnement isolé sans jamais toucher à la production.