Aller au contenu principal

Sauvegarder MariaDB sans bloquer le site, avec rotation des archives

Fiche écrite en 2020, pour les navigateurs et les versions de l’époque. Vérifiez qu’elle correspond encore à votre environnement avant de l’appliquer.

Un mysqldump lancé sans option verrouille les tables pendant toute la sauvegarde : sur une boutique, les commandes attendent. Avec --single-transaction, la sauvegarde lit une photographie cohérente de la base sans rien bloquer, à condition que les tables soient en InnoDB, ce qui est le cas de PrestaShop et WordPress récents.

Terminal
#!/bin/bash
# /usr/local/sbin/sauvegarde-bases.sh
set -euo pipefail

DEST=/var/backups/mysql
JOUR=$(date +%F)
mkdir -p "$DEST"

# Sous Debian, root se connecte à MariaDB par le socket, sans mot de passe
for BASE in $(mysql -N -e "SHOW DATABASES" | grep -Ev '^(information_schema|performance_schema|sys)$'); do
    mysqldump --single-transaction --quick --routines --triggers --events "$BASE" \
        | gzip > "$DEST/$BASE-$JOUR.sql.gz"
done

# Quatorze jours d'historique
find "$DEST" -name '*.sql.gz' -mtime +14 -delete

set -o pipefail est la ligne que l’on oublie : sans elle, un mysqldump qui échoue passe inaperçu parce que gzip, derrière lui, réussit. On obtient alors chaque nuit une archive vide, et on ne le découvre que le jour où l’on en a besoin. Deux compléments indispensables : copier ces archives hors du serveur, et tester une restauration de temps en temps. Une sauvegarde jamais restaurée reste une hypothèse.

Terminal
chmod 700 /usr/local/sbin/sauvegarde-bases.sh

# crontab de root : chaque nuit à 2 h 30
30 2 * * * /usr/local/sbin/sauvegarde-bases.sh

# Test de restauration, sur une base à part
mysql -e "CREATE DATABASE test_restauration"
gunzip < /var/backups/mysql/boutique-2020-10-15.sql.gz | mysql test_restauration

Sources

  1. MariaDB Knowledge Base, mysqldump mariadb.com