mysqldump: sicher sichern und testen

Ein mysqldump-Backup ist erst brauchbar, wenn der Export konsistent endet und sich in einer getrennten Testdatenbank vollständig einspielen lässt. Nutzen Sie für InnoDB –single-transaction, sichern Sie Routinen und Events ausdrücklich, halten Sie Kennwörter aus der Kommandozeile heraus und prüfen Sie Rückgabecode, Protokoll sowie Wiederherstellung.

mysqldump erzeugt einen logischen Export: SQL-Anweisungen bilden Strukturen und Daten nach. Das ist gut lesbar, transportabel und für einzelne Datenbanken praktisch. Bei großen Datenmengen kann der Import jedoch lange dauern, weil Tabellen und Indizes neu aufgebaut werden.

Der belastbare Ablauf besteht aus fünf Stationen:

Umfang festlegen: Datenbanken, Tabellen, Routinen, Trigger, Events und erforderliche Konten erfassen.
Konsistenz wählen: Speicher-Engines und laufende Schemaänderungen berücksichtigen.
Ergebnis prüfen: Rückgabecode, Fehlerprotokoll, Dateigröße und plausiblen Inhalt kontrollieren.
Getrennt lagern: Aufbewahrung, Zugriff, Verschlüsselung und Löschung festlegen.
Wiederherstellen: Import in einer isolierten Umgebung samt Anwendungstest üben.

Prüfen Sie zuerst die Speicher-Engines

–single-transaction startet für den Export eine konsistente Transaktionssicht. Bei InnoDB kann mysqldump dadurch Daten ohne langes Sperren der Tabellen lesen. Kombinieren Sie die Option mit –quick, damit Zeilen schrittweise verarbeitet werden und nicht vollständig im Arbeitsspeicher des Clients landen.

Die Grenze ist wichtig: Nichttransaktionale Tabellen erhalten durch diese Option keine konsistente Sicht. Werden MyISAM- oder MEMORY-Tabellen während des Exports verändert, kann ihr Inhalt unterschiedliche Zeitstände enthalten. Planen Sie dafür ein Wartungsfenster, geeignete Sperren oder eine andere Sicherungsmethode.

Auch gleichzeitige Schemaänderungen sind ein Risiko. ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE und TRUNCATE TABLE können einen laufenden Export unbrauchbar machen. Stoppen Sie Deployment und Migration während des Sicherungsfensters. Ein Server ist eine Maschine im Betrieb, kein Ausstellungsstück.

Situation	Passender Prüfpunkt	Entscheidung
Nur InnoDB, keine DDL-Änderung	Konsistente Transaktionssicht und Exit-Code	Logischen Online-Export testen
Gemischte Speicher-Engines	Schreibaktivität der nichttransaktionalen Tabellen	Wartungsfenster oder anderes Verfahren
Sehr große Datenbank	Gemessene Export- und Importdauer	Logischen und physischen Ansatz vergleichen
Viele Datenbanken mit Abhängigkeiten	Gemeinsamer Zeitpunkt und Objektumfang	Wiederherstellung als Gesamtsystem testen

Verwenden Sie einen klaren Exportbefehl

Richten Sie die Verbindung vorab über einen geschützten MySQL-Login-Pfad oder eine nur für den Sicherungsnutzer lesbare Optionsdatei ein. Schreiben Sie kein Kennwort als Argument in den Befehl: Es kann in Prozesslisten, Terminaltiteln oder der Shell-Historie sichtbar werden.

Ein nachvollziehbarer Export für eine benannte Datenbank sieht so aus:

mysqldump \
  --login-path=BACKUP_LOGIN \
  --single-transaction \
  --quick \
  --routines \
  --events \
  --triggers \
  --databases DB_NAME \
  --result-file=/BACKUP_DIR/DB_NAME-YYYY-MM-DD.sql

Ersetzen Sie nur die großgeschriebenen Platzhalter. –databases nimmt die Anweisungen zum Anlegen und Auswählen der Datenbank in den Dump auf. Für einen gezielten Tabellenexport muss der spätere Import anders vorbereitet werden.

Trigger sind standardmäßig enthalten. Die explizite Option dokumentiert hier die Absicht. Gespeicherte Prozeduren und Funktionen benötigen –routines, geplante Ereignisse –events. Prüfen Sie außerdem Views und die verwendeten DEFINER-Konten, weil sie auf dem Zielsystem fehlen oder anders berechtigt sein können.

Geben Sie dem Sicherungskonto nur nötige Rechte

Die erforderlichen Rechte hängen von Objekten, Serverkonfiguration und Optionen ab. Tabellen benötigen Leserechte; Views, Trigger, Routinen und Events bringen weitere Anforderungen mit. Bestimmte GTID-Konfigurationen können bei –single-transaction zusätzliche globale Rechte verlangen.

Erst Risiko, dann Prüfpunkt, dann Entscheidung: Lassen Sie den geplanten Befehl mit dem echten Sicherungskonto laufen. Erweitern Sie Rechte nur für eine konkrete Fehlermeldung und dokumentierte Option. Ein pauschales Administratorkonto kaschiert Berechtigungsfehler und vergrößert den Schadensbereich.

Sichern Sie Konten und Berechtigungen bewusst separat, wenn sie zur Wiederherstellung gehören. Ein Anwendungsdump ist nicht automatisch eine vollständige Sicherung aller Serverkonten, Rollen und globalen Einstellungen.

Prüfen Sie Rückgabecode und Datei

Eine vorhandene Datei beweist keinen erfolgreichen Export. Automatisierung muss den Rückgabecode von mysqldump auswerten und Standardfehler protokollieren. Erst bei Erfolg darf die Datei komprimiert, verschoben und im Monitoring als gültig gemeldet werden.

Für eine einfache manuelle Kompression sind getrennte Schritte leichter zu prüfen als eine ungesicherte Befehlskette:

gzip --keep /BACKUP_DIR/DB_NAME-YYYY-MM-DD.sql

Bei einer Befehlskette muss die Shell Fehler aller Stufen erkennen, etwa mit pipefail; sonst kann eine erfolgreiche Kompression einen fehlgeschlagenen Export verdecken. Verwenden Sie in produktiver Automatisierung temporäre Dateinamen und veröffentlichen Sie den endgültigen Namen erst nach erfolgreicher Prüfung.

Kontrollieren Sie zusätzlich:

Plausible Größe: ungewöhnlich kleine oder sprunghaft große Dumps alarmieren.
Lesbarkeit: Kompressionsprüfung und kontrolliertes Öffnen erkennen beschädigte Dateien.
Erwartete Objekte: Tabellen, Routinen und Events mit einer Inventarliste abgleichen.
Protokoll: Warnungen und Fehler mit Zeit, Host, Datenbank und Jobkennung erfassen.
Aufbewahrung: mehrere Generationen nach einer dokumentierten Regel behalten.

Betrieb schlägt Prospekt: Ein Dump zählt erst, wenn die Prüfkette bis zur Anwendung durchläuft.

Ein erfolgreicher Export ist nur die erste Station: Exit-Code, Datei, Testimport und Anwendung müssen ebenfalls geprüft werden.

Stellen Sie in einer Testdatenbank wieder her

Testen Sie nicht zuerst auf dem Produktionssystem. Stellen Sie eine kompatible, isolierte MySQL-Instanz bereit und verwenden Sie ein Zielkonto ohne Zugriff auf die Produktion. Prüfen Sie freien Speicher, Zeichensatz, SQL-Modi und Versionen vor dem Import.

Wenn der Dump mit –databases DB_NAME erstellt wurde, kann der MySQL-Client die enthaltene Datenbankauswahl verarbeiten:

mysql --login-path=RESTORE_LOGIN < /BACKUP_DIR/DB_NAME-YYYY-MM-DD.sql

Vermeiden Sie –force: Die Option lässt den Client nach SQL-Fehlern weiterarbeiten und kann einen teilweise importierten Stand als scheinbar fertigen Lauf hinterlassen. Brechen Sie bei Fehlern ab, bewahren Sie das Protokoll und beginnen Sie mit einer leeren Testumgebung neu.

Nach dem Import folgen technische und fachliche Kontrollen. Vergleichen Sie Tabellen und erwartete Objekte, führen Sie Integritätsprüfungen der Anwendung aus, testen Sie Anmeldung, Lesen, Schreiben und eine zentrale Geschäftsaktion. Fragen Sie nach dem Ausfallpfad: Wer erkennt den Fehler, wer entscheidet und wie lange dauert der vollständige Lauf?

Planen Sie Speicher und Aufbewahrung vom Restore her

Der Dump benötigt Platz während Export, Kompression, Übertragung und Testimport. Rechnen Sie nicht nur mit der Größe der komprimierten Datei. Der Zielserver braucht Raum für Tabellen, Indizes, temporäre Daten und Protokolle.

Definieren Sie Generationen nach Wiederherstellungsbedarf statt nach Gewohnheit. Kurze Abstände begrenzen möglichen Datenverlust; längere Aufbewahrung hilft bei spät erkannten Fehlern. Beides kostet Speicher und Prüfzeit. Löschen Sie erst, wenn eine jüngere Generation erfolgreich getestet wurde und die Regel den älteren Stand nicht mehr verlangt.

Lagern Sie mindestens eine Kopie außerhalb des Datenbankservers und seiner Administrationsrechte. Verschlüsselung schützt vertrauliche Inhalte, verlangt aber eine getrennt verfügbare Schlüssel- und Wiederherstellungsprozedur.

Logical Dump oder physische Sicherung

Ein logischer Dump eignet sich für überschaubare Datenmengen, selektive Exporte, Migrationen und lesbare SQL-Artefakte. Seine Schwäche ist die Wiederherstellungszeit: SQL wird erneut ausgeführt, Daten werden geschrieben und Indizes aufgebaut.

Eine physische Sicherung kopiert Datenstrukturen näher am Speicherformat und kann große Instanzen schneller zurückbringen. Dafür ist sie stärker an Version, Plattform, Werkzeug und Betriebsverfahren gebunden. Entscheiden Sie anhand gemessener Sicherungs- und Wiederherstellungszeiten, nicht anhand der Dateiendung.

Prüfliste

Inventarisieren Sie Speicher-Engines, Routinen, Trigger, Events, Views und Konten vor dem ersten Export.
Sperren Sie Schemaänderungen im Sicherungsfenster und klären Sie die Konsistenz nichttransaktionaler Tabellen.
Halten Sie Kennwörter aus Argumenten heraus und prüfen Sie das Sicherungskonto mit minimalen Rechten.
Werten Sie Rückgabecode, Fehlerprotokoll, Dateigröße und erwartete Objekte vor Kompression und Ablage aus.
Stellen Sie jede relevante Generation isoliert wieder her und messen Sie den vollständigen Anwendungstest.

Der Restore entscheidet

Eine tägliche Datei ohne geprüften Import ist eine Annahme. Ein belastbarer Prozess dokumentiert Umfang, Konsistenzgrenzen, Rechte, Rückgabecode, Ablage, Aufbewahrung und Test. Reaktionszeit zählt in Minuten; deshalb gehört die Wiederherstellungsdauer ins Monitoring.

Wählen Sie mysqldump, wenn Portabilität und ein logisches Format wichtiger sind als die kürzeste Wiederherstellung. Ergänzen oder ersetzen Sie es durch eine physische Sicherung, sobald der gemessene Import Ihr Wiederherstellungsziel verfehlt.

Häufige Fragen

Reicht --single-transaction für jede MySQL-Datenbank?

Nein. Die konsistente Sicht gilt für transaktionale Tabellen wie InnoDB; nichttransaktionale Tabellen und parallele Schemaänderungen brauchen eine eigene Strategie.

Sichert mysqldump Routinen, Events und Trigger automatisch?

Trigger sind standardmäßig enthalten; Routinen und geplante Events sollten mit den entsprechenden Optionen ausdrücklich aufgenommen und nach dem Import geprüft werden.

Wie prüfe ich einen SQL-Dump?

Prüfen Sie Rückgabecode, Protokoll, Größe und erwartete Objekte und führen Sie anschließend einen vollständigen Import mit Anwendungstest in einer isolierten Umgebung aus.

Wann ist ein physisches Backup besser?

Wenn der logische Export oder Import das Sicherungs- beziehungsweise Wiederherstellungsziel verfehlt und das physische Verfahren zur Version und Betriebsumgebung passt.