Des backups MySQL qui restaurent vraiment — XtraBackup, binlogs et le drill trimestriel

Un backup que vous n'avez jamais restauré est de l'espoir, pas un backup. Chaque base MySQL managée que nous exploitons a Percona XtraBackup qui prend des backups physiques selon un calendrier, des binlogs archivés en continu pour le point-in-time recovery, et un drill de restauration trimestriel qui prouve que les deux marchent encore.

Le mode de défaillance courant : les backups réussissent pendant un an, puis un gap de binlog dû à un blip réseau il y a trois mois signifie que la PITR ne peut récupérer qu'avant le gap. Le temps que quelqu'un le remarque, le gap est trop ancien pour être pertinent.

La commande XtraBackup de base

xtrabackup --backup \
  --target-dir=/var/backups/mysql/full-$(date +%F) \
  --user=backup --password=... \
  --parallel=4 --compress --compress-threads=4 \
  --no-version-check
 
# Puis expédier + vérifier
aws s3 sync /var/backups/mysql/full-$(date +%F) s3://backups/mysql/full-$(date +%F)/
xtrabackup --prepare --target-dir=/var/backups/mysql/full-$(date +%F)

--prepare est ce qui rend le backup réellement utilisable — et c'est l'étape qui fait remonter corruption, redo log manquant ou mismatch de version avant que vous ayez besoin de restaurer.

L'article complet couvre :

• Pourquoi les backups physiques battent mysqldump pour toute DB non triviale
• Archivage continu de binlog — le pattern rsync/inotify que nous utilisons
• Point-in-time recovery à une coordonnée binlog spécifique
• Le drill de restauration trimestriel (provisionner un hôte propre, restaurer, smoke-tester)
• Vérification de backup — xtrabackup --prepare et les catastrophes qu'il attrape tôt
• Chiffrer les backups au repos, rotation de clés et stockage offsite

Nous faisons tourner ceci pour chaque client MySQL managé.