Sauvegardes de bases de données

Comment planifier les dumps MySQL et PostgreSQL, les déplacer hors de la machine et vérifier que la sauvegarde se restaure réellement.

Mis à jour le 23 août 2026

Un VPS n'est pas livré avec des sauvegardes automatiques ni des snapshots d'état : tout ce que vous n'avez pas copié vous-même n'existe qu'en un seul exemplaire. Un dump de base de données est la première chose à mettre en place, car il n'y a nulle part où restaurer les données, alors que le site peut être redéployé à partir de zéro.

Dump manuel

PostgreSQL :

pg_dump -Fc -U shop -h 127.0.0.1 shop > /srv/backups/shop-$(date +%F).dump
pg_dumpall -U postgres --roles-only > /srv/backups/roles.sql

MySQL et MariaDB :

mysqldump --single-transaction --quick --routines --events \
  -u root shop | gzip > /srv/backups/shop-$(date +%F).sql.gz

--single-transaction produit un dump InnoDB cohérent sans verrouiller les tables — sans cette option, votre site se figera pendant l'export. Le format -Fc de PostgreSQL est compressé et permet de restaurer des tables individuelles.

Ne mettez pas les mots de passe sur la ligne de commande : créez ~/.pgpass ou ~/.my.cnf avec des permissions 600.

Planification

mkdir -p /srv/backups && chmod 700 /srv/backups
crontab -e

20 3 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

Le script /usr/local/bin/db-backup.sh :

#!/bin/bash
set -euo pipefail
DEST=/srv/backups
STAMP=$(date +%F-%H%M)
pg_dump -Fc -U shop -h 127.0.0.1 shop > "$DEST/shop-$STAMP.dump.tmp"
mv "$DEST/shop-$STAMP.dump.tmp" "$DEST/shop-$STAMP.dump"
find "$DEST" -name '*.dump' -mtime +14 -delete

Écrire dans un fichier temporaire puis le renommer est important : si le dump est interrompu, vous ne confondrez pas un fichier tronqué avec une sauvegarde complète. set -euo pipefail arrête le script à la première erreur au lieu de continuer silencieusement.

Déplacer les sauvegardes hors de la machine

Une copie sur le même disque ne vous sauvera pas d'une erreur de migration, d'un rançongiciel ou d'une réinstallation de l'OS dans l'onglet « Accès ». Envoyez les dumps hors site :

rsync -az --delete /srv/backups/ backup@other-host:/store/vds/

Ou vers n'importe quel stockage compatible S3 via rclone. Gardez à l'esprit la bande passante allant jusqu'à 500 Mbit/s et la limite d'écriture disque par palier : 60 Mo/s par cœur.

Vérification de la restauration

Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde.

createdb -U postgres shop_check
pg_restore -U postgres -d shop_check /srv/backups/shop-2026-08-23.dump
psql -U postgres -d shop_check -c "SELECT count(*) FROM users;"
dropdb -U postgres shop_check

Pour MySQL : gunzip -c dump.sql.gz | mysql -u root shop_check.

Faites-le une fois par mois et notez la date de vérification.

Erreurs courantes

Symptôme	Cause
Le dump ne fait que quelques kilo-octets	Le script a échoué à l'authentification et l'erreur est allée dans `/dev/null`
L'espace disque est épuisé	Aucune suppression des anciennes sauvegardes par `mtime`
La restauration échoue sur les permissions	Les rôles n'ont pas été dumpés — il faut `--roles-only`
Cron est silencieux, aucune sauvegarde	Cron n'a pas votre `PATH` — utilisez des chemins absolus
Le site ralentit la nuit	Le dump entre en concurrence pour le disque — décalez l'heure, ajoutez `--quick`

Conservez au moins deux copies à des emplacements différents et surveillez la taille du dump : une chute brutale de la taille signifie que la base de données n'a pas été dumpée en entier.