MySQL-Backups, die wirklich wiederherstellen — XtraBackup, Binlogs und der vierteljährliche Drill

Ein Backup, das Sie nie wiederhergestellt haben, ist Hoffnung, kein Backup. Jede gemanagte MySQL-Datenbank, die wir betreiben, hat Percona XtraBackup, das physische Backups nach Zeitplan macht, kontinuierlich archivierte Binlogs für Point-in-Time-Recovery, und einen vierteljährlichen Restore-Drill, der beweist, dass beides noch funktioniert.

Der häufige Fehlermodus: Backups sind ein Jahr lang erfolgreich, dann bedeutet eine Binlog-Lücke durch einen Netzwerk-Blip vor drei Monaten, dass PITR nur bis vor die Lücke wiederherstellen kann. Wenn jemand es bemerkt, ist die Lücke zu alt, um relevant zu sein.

Der XtraBackup-Basis-Befehl

xtrabackup --backup \
  --target-dir=/var/backups/mysql/full-$(date +%F) \
  --user=backup --password=... \
  --parallel=4 --compress --compress-threads=4 \
  --no-version-check
 
# Dann versenden + verifizieren
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 ist, was das Backup tatsächlich brauchbar macht — und es ist der Schritt, der Korruption, fehlende Redo Logs oder Versions-Mismatches zutage fördert, bevor Sie restoren müssen.

Der vollständige Beitrag behandelt:

• Warum physische Backups mysqldump für jede nicht-triviale DB schlagen
• Kontinuierliche Binlog-Archivierung — das rsync/inotify-Pattern, das wir fahren
• Point-in-Time-Recovery auf eine bestimmte Binlog-Koordinate
• Der vierteljährliche Restore-Drill (sauberen Host bereitstellen, restoren, Smoke-Testen)
• Backup-Verifikation — xtrabackup --prepare und die Katastrophen, die es früh einfängt
• Backups at-rest verschlüsseln, Schlüsselrotation und Offsite-Storage

Wir fahren das für jeden gemanagten MySQL-Kunden.