58 Prozent der Unternehmen konnten nach einem Datenverlust nicht alle Daten vollständig wiederherstellen. So lautet das Ergebnis der Backblaze-Studie 2024. Das ist keine Minderheit. Das ist die Mehrheit.
Woran liegt das? Häufig nicht am fehlenden Willen, sondern an einem Missverständnis: Ein laufender Dump-Job gilt als Datenbank-Backup. Die Status-Mail ist grün. Die Datenbank läuft. Alles in Ordnung. Bis zum Ernstfall.
pg_dump und mysqldump sind keine schlechten Werkzeuge. Sie leisten das, wofür sie entwickelt wurden. Das Problem beginnt dort, wo sie als vollständige Backup-Strategie eingesetzt werden. Und das ist häufiger der Fall, als die meisten IT-Teams vermuten würden.
Nach diesem Artikel wissen Sie, wo die Grenzen logischer Datenbank-Exports liegen, welche Lücken crash-konsistente VM-Snapshots hinterlassen und an welchen drei Punkten Sie Ihren eigenen Stand heute überprüfen können.
Ein Dump ist ein logischer Export. pg_dump liest den Datenbankinhalt zum Zeitpunkt des Dump-Starts aus und schreibt ihn als SQL-Befehle oder im binären Format in eine Datei. Der Snapshot ist intern konsistent. Was er nicht enthält: die Transaktionslogs der Datenbank.
Das ist der entscheidende Unterschied:
Dump: Logischer Export des Datenbankzustands zu einem Zeitpunkt. Kein Transaktionslog, keine Point-in-Time-Recovery-Fähigkeit.
Backup: Physische Sicherung plus Transaktionslogs plus getestete Wiederherstellung. Ermöglicht Recovery zu einem beliebigen Zeitpunkt innerhalb des Retention-Fensters.
Ab PostgreSQL 18 zieht die offizielle Dokumentation diese Grenze explizit: pg_dump wird dort nicht mehr als Backup-, sondern als Export-Werkzeug beschrieben. Der Hinweis ist direkt: "pg_dump is not a general-purpose backup tool." Das ist keine kosmetische Änderung. Es ist die Dokumentation eines jahrelangen Missverständnisses in der Praxis.
Hinzu kommt: Globale Cluster-Objekte wie Roles und Tablespaces sind aus pg_dump-Exporten ausgeschlossen. In Multi-Datenbank-Umgebungen führt das beim Restore zu stillen Inkonsistenzen, die erst dann sichtbar werden, wenn es darauf ankommt.
pg_dump ohne WAL-Archivierung bedeutet: kein Point-in-Time Recovery (PITR). Alle Transaktionen zwischen dem letzten Dump und dem Ausfall sind unwiederbringlich verloren.
Die Voraussetzung für echtes PITR bei PostgreSQL ist pg_basebackup als physisches Basis-Backup, kombiniert mit kontinuierlicher WAL-Archivierung. Erst damit kann die Datenbank auf einen beliebigen Zeitpunkt innerhalb des Retention-Fensters zurückgesetzt werden. Alternativ bietet pgBackRest ein ausgereifteres Tooling für denselben Zweck.
mysqldump --single-transaction sichert InnoDB-Tabellen konsistent. Für MyISAM-Tabellen gilt das nicht: Sie werden während des Dumps nicht gesperrt und können in inkonsistentem Zustand gesichert werden.
PITR setzt bei MySQL zwingend aktiviertes Binary Logging (Binlog) voraus. Ohne Binlog ist kein PITR möglich. Ist Binlog aktiv, läuft der Prozess über drei Schritte: vollständiges Backup restoren, Binlog-Position identifizieren, Binary Logs bis zum Zielzeitpunkt via mysqlbinlog einspielen.
Physische Hot-Backup-Tools wie Percona XtraBackup sichern ohne Datenbanksperre und können je nach Setup erheblich schneller sichern und wiederherstellen als mysqldump. Bei grossen produktiven Datenbanken ist das relevant.
Das Recovery Model entscheidet, ob PITR bei SQL Server überhaupt möglich ist. Im Simple Recovery Model sind Transaction Log Backups grundsätzlich ausgeschlossen. SQL Server Express verwendet standardmässig das Simple Model; viele KMU haben es auch in anderen Editionen auf Simple gesetzt, um Log-Wachstum zu kontrollieren.
Im Full Recovery Model gilt: PITR ist nur möglich, wenn die vollständige Log Chain lückenlos vorhanden ist. Eine bekannte Falle ist der kombinierte Einsatz von nativem SQL Server Backup und einem externen Backup-Tool ohne COPY_ONLY-Flag. Das externe Tool bricht die Log Sequence Number. Backup-Jobs melden "Succeeded". Eine Wiederherstellung ist trotzdem nicht möglich.
Zur Einordnung: Ein täglicher Dump ergibt ein Recovery Point Objective (RPO) von bis zu 24 Stunden. Für kritische, kundenseitige Systeme liegt der Industriestandard bei 0 bis 2 Stunden.
Pixar, 1998. Ein Mitarbeiter führt versehentlich einen Löschbefehl auf dem Root-Ordner von Toy Story 2 aus. Rund 90 Prozent der Produktionsdaten werden gelöscht.
Das Band-Backup-System hatte seit Monaten still fehlgeschlagen. Neue Dateien wurden gespeichert, indem ältere überschrieben wurden, weil die Tape-Kapazität bei 4 GB überschritten war. Das Error-Log lag auf demselben vollen Volume und hatte 0 Bytes. Backup-Jobs meldeten Erfolg. Die Daten waren trotzdem verloren.
Gerettet wurde Toy Story 2 durch eine Kopie auf dem Heim-PC von Galyn Susman, Supervising Technical Director bei Pixar. Ein Zufallsfund. Keine Recovery-Strategie.
Mai 2024. Google Cloud löscht versehentlich die gesamte Cloud-Umgebung von UniSuper, einem australischen Pensionsfonds. Laut dem gemeinsamen Statement von UniSuper-CEO Peter Chen und Google Cloud CEO Thomas Kurian: eine unbeabsichtigte Fehlkonfiguration beim Provisionierungsprozess. Zwei Wochen lang hatten Kunden keinen Zugriff auf ihre Daten.
UniSuper konnte wiederhergestellt werden, weil entgegen der üblichen Single-Cloud-Praxis Backups bei einem zweiten Cloud-Anbieter lagen.
In beiden Fällen hatte niemand den Restore getestet, bevor es darauf ankam. Das ist das eigentliche Muster. Nicht technisches Versagen, sondern unterlassene Verifikation.
Viele Backup-Lösungen sichern Datenbankserver per VM-Snapshot (VMware, Hyper-V, AWS EBS) oder Filesystem-Snapshot, ohne den Datenbankprozess zu koordinieren. Das Ergebnis ist ein crash-konsistenter Snapshot.
Was das konkret bedeutet: Der Snapshot erfasst den Zustand mitten in laufenden Transaktionen. Open Transactions sind noch aktiv, WAL-Segmente möglicherweise nicht geflusht, Buffer Pools noch nicht auf Disk. Beim Restore muss die Datenbank-Engine ihre eigene Recovery durchführen. Das schlägt fehl, wenn WAL-Segmente fehlen oder auf einem anderen, nicht gesicherten Volume lagen.
Das Risiko ist nicht symmetrisch. Crash-konsistente Backups verlagern die Ungewissheit von der Backup-Zeit auf die Restore-Zeit. Der Job meldet Erfolg. Ob eine Recovery möglich ist, bleibt unbekannt.
Richtig gemacht: application-konsistente Backups, die den Datenbankagenten einbeziehen (VSS Writer bei Windows, Freeze/Thaw bei Linux). Oder: datenbankspezifische Sicherung parallel zur VM-Sicherung.
Fünf Voraussetzungen:
Die technischen Voraussetzungen für ein Recovery-fähiges Datenbank-Backup sind bekannt und lösbar. Die eigentliche Lücke entsteht nicht durch fehlende Werkzeuge, sondern durch Annahmen, die nie überprüft wurden.
Drei Fragen für die direkte Anwendung auf Ihr Setup:
Wenn eine dieser Fragen offen bleibt, ist das der Ausgangspunkt. Nicht das Ende der Analyse.
Für Unternehmen, die ihre Datenbank-Sicherung auf ein belastbares Fundament stellen wollen, ohne den gesamten Betrieb intern abbilden zu müssen: Backup ONE bietet Managed Backup Services mit datenbankspezifischer Sicherung, automatisierten Restore-Tests und georedundanter Speicherung in Schweizer Rechenzentren. Der Backup-Prozess wird professionell betreut, überwacht und dokumentiert. So wird aus einer Annahme eine nachweisbare Sicherheit.
Haben Sie Fragen zu Ihrer Datenbank-Backup-Strategie? Kontaktieren Sie uns.
Das sind weitere Beiträge, die Sie interessieren könnten.
Zur Blogübersicht