Backup-Strategien im Vergleich: mysqldump vs. XtraBackup

1. Logische versus physische Backups

Jede Backup-Strategie für MySQL beginnt mit einer grundlegenden Entscheidung: logisches oder physisches Backup. mysqldump erzeugt ein logisches Backup, also eine textbasierte Sammlung von SQL-Anweisungen, die die Datenbankstruktur und alle Daten als CREATE TABLE und INSERT-Statements abbilden. XtraBackup dagegen erstellt ein physisches Backup, indem es die tatsächlichen InnoDB-Datendateien auf Blockebene kopiert, ohne den Umweg über SQL zu nehmen.

Dieser Unterschied wirkt sich auf jeden Aspekt der Backup-Strategie aus: Geschwindigkeit, Sperrzeiten, Portabilität und Restore-Dauer. Ein logisches Backup lässt sich problemlos auf einer anderen MySQL-Version oder sogar einem anderen Datenbanksystem einspielen, weil es aus portablem SQL besteht. Ein physisches Backup ist dagegen deutlich schneller wiederherzustellen, aber an dieselbe MySQL-Version und Storage-Engine-Konfiguration gebunden wie der Quellserver.

2. mysqldump im Detail

mysqldump ist seit jeher Bestandteil jeder MySQL-Installation und eignet sich für kleinere Datenbanken oder Situationen, in denen Portabilität wichtiger ist als Geschwindigkeit. Die Option --single-transaction ist bei InnoDB-Tabellen essenziell: sie startet den Dump innerhalb einer einzelnen Transaktion mit Repeatable-Read-Isolation und erlaubt so ein konsistentes Backup, ohne die Tabellen für Schreibzugriffe zu sperren.

Ohne --single-transaction greift mysqldump standardmäßig auf FLUSH TABLES WITH READ LOCK zurück, was alle Tabellen für die Dauer des Dumps komplett sperrt und in produktiven Systemen meist inakzeptabel ist. Der grosse Nachteil von mysqldump bleibt trotzdem die Geschwindigkeit: bei mehreren hundert Gigabyte Datenbankgröße kann ein vollständiger Dump mehrere Stunden dauern, weil jede Zeile als Text geschrieben und beim Restore wieder als SQL geparst und ausgeführt werden muss.

# Konsistentes logisches Backup mit mysqldump erstellen
mysqldump \
  --single-transaction \
  --routines --triggers --events \
  --master-data=2 \
  --quick \
  -u backup_user -p shop_db | gzip > /backup/shop_db_$(date +%F).sql.gz

# Restore aus einem komprimierten Dump
gunzip < /backup/shop_db_2026-07-23.sql.gz | mysql -u root -p shop_db

3. Percona XtraBackup im Detail

XtraBackup kopiert die InnoDB-Datendateien direkt vom Dateisystem, während der Server weiterläuft, und zeichnet parallel alle während des Kopiervorgangs anfallenden Änderungen über das InnoDB-Redo-Log auf. Nach dem eigentlichen Kopieren wendet ein separater --prepare-Schritt dieses Redo-Log auf die kopierten Dateien an, um einen konsistenten Zustand herzustellen, exakt so, wie InnoDB es auch nach einem harten Serverabsturz tun würde.

Der entscheidende Vorteil von XtraBackup gegenüber mysqldump ist, dass während des gesamten Backup-Vorgangs keine langen Tabellensperren nötig sind und der Server durchgehend voll schreibbar bleibt. Bei Datenbanken im Terabyte-Bereich ist XtraBackup deshalb oft die einzige praktikable Backup-Strategie, weil ein logisches Backup schlicht zu lange dauern würde, um es täglich durchzuführen.

# Physisches Voll-Backup mit XtraBackup erstellen
xtrabackup --backup \
  --target-dir=/backup/full/$(date +%F) \
  --user=backup_user --password="$BACKUP_PW"

# Backup vorbereiten (Redo-Log anwenden, konsistenten Zustand herstellen)
xtrabackup --prepare --target-dir=/backup/full/$(date +%F)

# Restore: Datenverzeichnis leeren und Backup zurückkopieren
systemctl stop mysql
xtrabackup --copy-back --target-dir=/backup/full/2026-07-23
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

4. Inkrementelle Backups mit XtraBackup

Ein zentraler Vorteil von XtraBackup gegenüber mysqldump ist die Fähigkeit zu echten inkrementellen Backups. Nach einem initialen Voll-Backup speichert XtraBackup bei jedem weiteren Lauf nur noch die Seiten, die sich seit dem letzten Backup tatsächlich geändert haben, erkennbar an der LSN, der Log Sequence Number von InnoDB. Das reduziert Backup-Größe und Backup-Dauer bei täglichen Sicherungen drastisch, während mysqldump immer den vollständigen Datenbestand exportieren muss.

Eine typische Backup-Strategie kombiniert ein wöchentliches Voll-Backup mit täglichen inkrementellen Backups dazwischen. Beim Restore werden zunächst das Voll-Backup und danach alle inkrementellen Backups in der richtigen Reihenfolge auf den vorbereiteten Zustand angewendet, bevor ein finaler --prepare-Schritt ohne --apply-log-only den Datenbestand endgültig konsistent macht.

# Inkrementelles Backup auf Basis des letzten Voll-Backups
xtrabackup --backup \
  --target-dir=/backup/incr/day1 \
  --incremental-basedir=/backup/full/2026-07-23 \
  --user=backup_user --password="$BACKUP_PW"

# Voll-Backup vorbereiten, aber Redo-Log für weitere Inkremente offenhalten
xtrabackup --prepare --apply-log-only --target-dir=/backup/full/2026-07-23

# Inkrementelles Backup einspielen
xtrabackup --prepare --apply-log-only \
  --target-dir=/backup/full/2026-07-23 \
  --incremental-dir=/backup/incr/day1

# Finalen Zustand konsistent machen (letztes Inkrement ohne apply-log-only)
xtrabackup --prepare --target-dir=/backup/full/2026-07-23

5. Restore-Geschwindigkeit im Vergleich

Die Restore-Geschwindigkeit ist der Punkt, an dem sich beide Ansätze am deutlichsten unterscheiden, und oft der entscheidende Faktor für die Wahl der Backup-Strategie. Ein mysqldump-Restore muss jede Zeile als SQL-Statement parsen, Indizes während des Einfügens pflegen und Constraints prüfen, was bei großen Tabellen erheblich Zeit kostet. XtraBackup kopiert dagegen bereits fertige, indizierte InnoDB-Seiten zurück, ohne dass die Datenbank die Daten erneut verarbeiten muss.

In der Praxis bedeutet das: bei einer 200-Gigabyte-Datenbank kann ein mysqldump-Restore mehrere Stunden dauern, während ein XtraBackup-Restore oft in weniger als 30 Minuten abgeschlossen ist, im Wesentlichen begrenzt durch die Kopiergeschwindigkeit des Speichersystems. Für jede Backup-Strategie mit definierter Recovery Time Objective sollte diese Differenz gemessen und nicht angenommen werden.

6. Konsistenz sicherstellen

Konsistenz ist bei beiden Werkzeugen kein Selbstläufer, sondern muss aktiv erzwungen werden. Bei mysqldump garantiert nur --single-transaction in Kombination mit InnoDB-Tabellen einen konsistenten Snapshot, weil MyISAM-Tabellen keine Transaktionen unterstützen und stattdessen weiterhin gesperrt werden müssen. Eine gemischte Datenbank mit InnoDB- und MyISAM-Tabellen erfordert deshalb besondere Aufmerksamkeit bei der Backup-Strategie, da MyISAM-Tabellen die Konsistenzgarantie sonst unterlaufen.

Bei XtraBackup wird Konsistenz über das InnoDB-Redo-Log sichergestellt: Änderungen, die während des Kopiervorgangs passieren, werden protokolliert und im --prepare-Schritt nachträglich angewendet, sodass das fertige Backup exakt dem Datenbankzustand zu einem einzigen konsistenten Zeitpunkt entspricht. Wichtig ist, dass innodb_flush_log_at_trx_commit und sync_binlog in Produktion auf sicheren Werten stehen, damit das Redo-Log selbst keine Lücken gegenüber tatsächlich committeten Transaktionen aufweist.

7. Automatisierung und Aufbewahrungsstrategien

Eine belastbare Backup-Strategie automatisiert nicht nur die Erstellung, sondern auch die Aufbewahrung und Bereinigung alter Backups nach einem klaren Schema. Eine gängige Retention-Regel hält tägliche Backups sieben Tage, wöchentliche Backups vier Wochen und monatliche Backups zwölf Monate vor, um sowohl kurzfristige Fehler als auch langfristig entdeckte Probleme abdecken zu können.

Cron-Jobs oder systemd-Timer sollten Backup-Skripte mit klaren Exit-Codes und Benachrichtigung bei Fehlschlag ausführen, da ein stillschweigend fehlgeschlagenes Backup erst beim nächsten Restore-Versuch auffällt, wenn es bereits zu spät ist. Ein Monitoring-Check, der prüft, ob die jüngste Backup-Datei nicht älter als das erwartete Intervall ist, gehört in jede produktive Backup-Strategie.

# Retention-Bereinigung: tägliche Backups älter als 7 Tage entfernen
find /backup/daily -name "*.sql.gz" -mtime +7 -delete
find /backup/full -maxdepth 1 -mtime +28 -exec rm -rf {} \;

# Monitoring-Check: jüngstes Backup darf nicht älter als 26 Stunden sein
newest=$(find /backup/daily -name "*.sql.gz" -mtime -2 | wc -l)
if [[ "$newest" -eq 0 ]]; then
  echo "[ALERT] Kein aktuelles Backup gefunden" | mail -s "Backup-Alarm" ops@mironsoft.de
fi

8. Verschlüsselung und Offsite-Storage

Backups enthalten dieselben sensiblen Daten wie die produktive Datenbank und müssen deshalb denselben Schutzstandards unterliegen. XtraBackup unterstützt native Verschlüsselung über --encrypt=AES256 direkt während der Erstellung, während mysqldump-Ausgaben über eine separate Pipe an openssl enc oder gpg verschlüsselt werden. In beiden Fällen müssen die Schlüssel getrennt von den Backups selbst und mit eingeschränktem Zugriff aufbewahrt werden.

Ebenso wichtig wie Verschlüsselung ist Offsite-Storage: ein Backup, das auf demselben physischen Server oder im selben Rechenzentrum liegt wie die Produktionsdatenbank, schützt nicht vor Hardware-Ausfall, Feuer oder einem kompromittierten Server. Eine solide Backup-Strategie repliziert Backups automatisiert in einen unabhängigen Object-Storage wie S3 oder ein zweites Rechenzentrum, idealerweise mit unveränderlichem Speicher gegen nachträgliche Manipulation.

# XtraBackup mit nativer Verschluesselung erstellen
xtrabackup --backup \
  --target-dir=/backup/encrypted/$(date +%F) \
  --encrypt=AES256 --encrypt-key-file=/etc/mysql/backup.key \
  --user=backup_user --password="$BACKUP_PW"

# mysqldump-Ausgabe per gpg verschluesseln und nach S3 hochladen
mysqldump --single-transaction -u backup_user -p shop_db \
  | gzip | gpg --encrypt --recipient backups@mironsoft.de \
  > /backup/shop_db_$(date +%F).sql.gz.gpg

aws s3 cp /backup/shop_db_$(date +%F).sql.gz.gpg \
  s3://mironsoft-backups-offsite/mysql/ --storage-class STANDARD_IA

9. Warum Backups einen Restore-Test brauchen

Ein Backup, das nie erfolgreich wiederhergestellt wurde, ist nur eine unbestätigte Annahme, keine funktionierende Backup-Strategie. In der Praxis scheitern Restores an überraschend banalen Ursachen: fehlende Berechtigungen, ein zu klein dimensioniertes Zielverzeichnis, eine inkompatible MySQL-Version oder ein Backup-Job, der seit Wochen stillschweigend fehlschlägt, ohne dass es jemand bemerkt hat.

Regelmäßige, automatisierte Restore-Tests auf einer isolierten Instanz decken solche Probleme auf, bevor ein echter Datenverlust eintritt. Ein einfacher, aber wirksamer Ansatz ist, jede Nacht das aktuelle Backup automatisch auf einem Test-Server einzuspielen und per Checksumme oder Zeilenanzahl zu verifizieren, dass der wiederhergestellte Datenbestand plausibel ist, bevor der nächste Arbeitstag beginnt.

10. Zusammenfassung

Die Wahl zwischen mysqldump und XtraBackup ist keine Geschmacksfrage, sondern hängt direkt von Datenbankgröße, erlaubter Downtime und geforderter Restore-Geschwindigkeit ab. mysqldump bleibt für kleine Datenbanken und portable, versionsübergreifende Backups sinnvoll, während XtraBackup ab mittleren bis großen Datenmengen durch schnelleren Restore und echte inkrementelle Backups klar im Vorteil ist.

Unabhängig vom gewählten Werkzeug gilt: Konsistenz muss aktiv erzwungen werden, Aufbewahrung und Bereinigung gehören automatisiert, Backups müssen verschlüsselt und offsite gelagert werden, und nur ein regelmäßig getesteter Restore beweist, dass die Backup-Strategie im Ernstfall tatsächlich funktioniert.

11. FAQ: Backup-Strategien mysqldump vs. XtraBackup