Sauvegarder et restaurer une base MySQL/MariaDB

Une base de données se sauvegarde par un dump logique, pas en copiant ses fichiers pendant qu'elle écrit. Le dump doit être cohérent, compressé, conservé hors du VPS et surtout restauré au moins une fois. Cette procédure utilise les outils MariaDB de Debian 13 et reste valable pour MySQL.

Produire un dump cohérent

Pour InnoDB, --single-transaction ouvre un instantané cohérent sans bloquer les écritures. --quick transmet les lignes au fur et à mesure au lieu de charger une table en mémoire. --routines, --triggers et --events conservent procédures, déclencheurs et tâches planifiées.

sudo install -d -m 700 /var/backups/mysql
sudo sh -c 'mariadb-dump --defaults-extra-file=/etc/backup-mysql.cnf \
  --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 app \
  | gzip > /var/backups/mysql/app-$(date +%F).sql.gz'

mariadb-dump est l'outil natif ; mysqldump reste un alias. Ne mettez pas le mot de passe dans la ligne de commande : il est visible dans ps. Créez plutôt /etc/backup-mysql.cnf, lisible par root uniquement :

[client]
user=backup
password=mot-de-passe-fort

sudo chmod 600 /etc/backup-mysql.cnf. Pour un utilisateur non root, utilisez $HOME/.my.cnf avec les mêmes clés.

Le dump logique n'est pas atomique pour MyISAM. Si des tables utilisent encore ce moteur, planifiez une fenêtre ou convertissez-les en InnoDB avant de compter sur --single-transaction.

Restaurer sans écraser la production

sudo mariadb -e "CREATE DATABASE test_restauration"
sudo sh -c 'gunzip -c /var/backups/mysql/app-2026-11-07.sql.gz | mariadb test_restauration'

Comparez le nombre de lignes des tables critiques et lancez l'application sur cette copie. Restaurer directement dans la base de production pendant que l'application écrit produit des doublons ou des incohérences. Pour une vraie restauration : arrêtez l'application, sauvegardez l'état actuel, restaurez, vérifiez, puis redémarrez.

Automatiser et conserver

Un script court vaut mieux qu'une commande cron illisible :

#!/bin/sh
set -eu
umask 077
exec 9>/run/lock/backup-app.lock
flock -n 9 || exit 0
mariadb-dump --defaults-extra-file=/etc/backup-mysql.cnf \
  --single-transaction --quick --routines --triggers \
  --default-character-set=utf8mb4 app \
  | gzip > /var/backups/mysql/app-$(date +%F).sql.gz
find /var/backups/mysql -type f -name '*.sql.gz' -mtime +14 -delete

Planifiez-le avec cron (30 2 * * *) et redirigez la sortie vers un journal. flock évite deux exécutions simultanées ; le fichier d'identifiants évite toute interaction, indispensable depuis cron. Copiez ensuite les archives hors site avec rsync ou rclone, et chiffrez-les avant l'envoi avec age ou gpg. Un dump sur le même disque que la base ne survit pas à la perte du VPS.

Tester la sauvegarde

Une sauvegarde jamais restaurée est une hypothèse. Faites un test mensuel : téléchargez l'archive, décompressez-la, importez-la dans une base jetable, vérifiez CHECKSUM TABLE ou un comptage, et notez la durée. Surveillez l'espace disque : un dump complet peut dépasser la taille de la base compressée, et une archive tronquée échoue seulement au moment où vous en avez besoin.