Beschädigte MySQL-, PostgreSQL- oder MongoDB-Datenbank wiederherstellen 2026: Schritt-für-Schritt-Verfahren

Die Datenbankwiederherstellung gehört zu den heikelsten Disziplinen der Datenrettung. Anders als bei einzelnen Dateien, wo der Einsatz binär ist (wiederhergestellt oder nicht), kann eine beschädigte Datenbank beim Start intakt erscheinen, während sie stille Inkonsistenzen enthält — desynchronisierte Indizes, verletzte Constraints, teilweise angewendete Transaktionen —, die sich erst Wochen später als Anwendungsfehler oder falsche Finanzkonten zeigen. Dieser Artikel dokumentiert das vollständige Wiederherstellungsverfahren für MySQL, PostgreSQL und MongoDB, mit nativen Werkzeugen, spezialisierten Drittanbieter-Werkzeugen, Wiederherstellungserwartungen und Schwellen für die Orientierung an ein professionelles Labor.

Drei DBMS dominieren 2026 das Consumer- und KMU-Open-Source-Segment: MySQL/MariaDB, PostgreSQL (in stetigem Wachstum) und MongoDB (der führende NoSQL-Dokumentenspeicher). Jedes verwendet eine radikal andere Speicherarchitektur — InnoDB und seine .ibd-Dateien, PostgreSQL und sein base/ mit separaten WALs, MongoDB und seine WiredTiger-Engine mit .wt-Collections —, die spezifische Wiederherstellungsverfahren erfordert. Kein generisches Dateiwiederherstellungswerkzeug (EaseUS, PhotoRec, Recuva) reicht hier aus.

Transparente Partnerschaft. Save My Disk erhält eine Provision, wenn Sie über die EaseUS-Links in diesem Artikel eine Lizenz erwerben. EaseUS greift nur auf Dateisystemebene ein — für die Wiederherstellung der .ibd-, base/-, .wt-Dateien, die die Datenbank beherbergen. Für die transaktionale Wiederherstellung selbst (innodb_force_recovery, pg_resetwal, mongod --repair) verweisen wir ausschließlich auf native DBMS-Werkzeuge oder Stellar Repair gemäß unserer öffentlichen Methodik.

MySQL und MariaDB: innodb_force_recovery und forensisches mysqldump

Die InnoDB-Speicher-Engine von MySQL 8.0.x und MariaDB 11.x speichert Daten in .ibd-Dateien, eine pro Tabelle (file-per-table standardmäßig seit MySQL 5.6) oder in einem gemeinsamen ibdata1-Tablespace. Indizes, Fremdschlüssel-Constraints und Trigger leben in .frm (bis MySQL 5.7) oder im InnoDB-Dictionary (seit MySQL 8.0). Das Binärlog (binlog) protokolliert alle Änderungen für Replikation und Point-in-Time-Recovery.

Eine typische InnoDB-Beschädigung äußert sich in einem Absturz beim Start mit einer Meldung im error.log wie InnoDB: Database page corruption on disk oder einem fehlgeschlagenen Dateilesevorgang von page X. Das Standardverfahren nutzt den Parameter innodb_force_recovery, der ganzzahlige Werte von 0 (Normalmodus) bis 6 (maximaler Forensik-Modus) annimmt. Jede Erhöhung deaktiviert einen Schutz:

• 1 deaktiviert die Prüfung beschädigter Seiten (minimaler Verlust)
• 2 deaktiviert den Purge-Thread (kann Zombie-Transaktionen hinterlassen)
• 3 deaktiviert das Transaktions-Rollback (Teiländerungen bleiben bestehen)
• 4 deaktiviert die Insert-Buffer-Zusammenführung (Index-Inkonsistenzen)
• 5 deaktiviert das Redo-Log (Verlust von Nicht-Checkpoint-Transaktionen)
• 6 deaktiviert die Crash-Recovery beim Start (schwere Beschädigung ignoriert)

Die Stufen 1 bis 3 lösen die große Mehrheit der Fälle, wobei Stufe 1 allein bereits viele abdeckt. Ab Stufe 3 bleibt der sofortige Export über mysqldump --all-databases --routines --triggers --single-transaction der einzige sichere Weg — jeder weitere Schreibvorgang riskiert eine irreversible Beschädigung.

Das Werkzeug Stellar Repair for MySQL 7 (veröffentlicht im März 2026, 299 $) bietet eine offline forensische Analyse von .ibd-Dateien, die innodb_force_recovery in Fällen ergänzt, in denen der Server überhaupt nicht mehr startet. Es stellt einen großen Teil der Zeilen aus beschädigten .ibd-Dateien mit intaktem Page-Header wieder her.

PostgreSQL: pg_resetwal, Point-in-Time-Recovery und Standby

PostgreSQL 16.x, veröffentlicht im September 2023, speichert seine Daten in einer data/base/<dbOID>/-Struktur mit einer Datei pro Tabelle, identifiziert durch die OID. Write-Ahead-Logs (WAL) in pg_wal/ protokollieren jede Änderung vor dem Commit und ermöglichen Point-in-Time-Recovery (PITR). Der regelmäßige Checkpoint leert alte WALs und synchronisiert die Datendateien.

Eine PostgreSQL-Beschädigung tritt in drei Hauptformen auf. Erstes Szenario: Absturz während eines Schreibvorgangs, der ein unvollständiges WAL hinterlässt. Beim Neustart spielt PostgreSQL das WAL erneut ab und findet einen konsistenten Zustand. In den meisten Fällen ist kein manueller Eingriff nötig — die automatische WAL-Wiedergabe von PostgreSQL erledigt das.

Zweites Szenario: Beschädigung einer Tabellenseite, gekennzeichnet durch die Meldung PANIC: corrupted item pointer. Das Verfahren erfordert zero_damaged_pages = on in der postgresql.conf beim Start, was beschädigte Seiten als leer markiert, statt abzubrechen. Daten auf diesen Seiten gehen verloren — die Option ermöglicht nur den Start, um den Rest zu exportieren.

Drittes Szenario: Unmöglichkeit des Starts selbst mit zero_damaged_pages. Dies ist der Fall, in dem pg_resetwal eingreift. Die Dokumentation postgresql.org besteht darauf: pg_resetwal ist ein Notfall-Vorgang, der den Verlust von Nicht-Checkpoint-Daten und Inkonsistenzen verursachen kann. Führen Sie es auf einer KOPIE des Datenverzeichnisses aus, niemals auf der Produktivumgebung.

Für PostgreSQL-Deployments mit Streaming-Replikations-Standby (in Produktion seit PostgreSQL 12 empfohlene Konfiguration) wird das Wiederherstellungsverfahren trivial: Befördern Sie den Standby über pg_ctl promote zum Primary und bauen Sie dann einen neuen Standby vom neuen Primary auf. Kein pg_resetwal nötig, kein Datenverlust. Deshalb lösen sich die meisten PostgreSQL-Vorfälle in gut konzipierten Produktionsumgebungen ohne jede forensische Wiederherstellung.

MongoDB WiredTiger: --repair, Replica-Set und Collection-Dump

MongoDB 7.0, veröffentlicht im August 2023, verwendet ausschließlich die WiredTiger-Speicher-Engine (die alte MMAPv1-Engine wurde seit MongoDB 4.2 entfernt). Collections werden in .wt-Dateien pro Collection gespeichert, mit einem separaten WiredTiger-Journal für die Dauerhaftigkeit. Replica-Sets duplizieren die Daten auf mindestens 3 Knoten mit einem oplog zur Synchronisation.

Eine WiredTiger-Beschädigung äußert sich typischerweise als mongod-Startabsturz mit der Meldung WT_PANIC: WiredTiger library panic oder Detected unclean shutdown - this should only occur if the storage volume was corrupted. Das --repair-Verfahren führt drei Operationen aus: Überprüfung jeder WiredTiger-Seite, Index-Neuaufbau und Entfernung beschädigter Dokumente.

mongod --repair --dbpath /var/lib/mongodb

Dieses Verfahren kann von 20 Minuten für eine 50-GB-Datenbank bis zu mehreren Stunden für eine Multi-TB-Datenbank dauern. Die Dokumentation MongoDB Manual Repair stellt fest, dass --repair Dokumente dauerhaft löschen kann — die vollständige dbpath-Kopie ist vor dem Start nicht verhandelbar.

Bei Replica-Sets ändert sich die Strategie radikal. Der beschädigte Primary muss aus dem Set entfernt werden (rs.remove("primary:27017")), ein gesunder Secondary befördert (rs.stepDown() auf dem problematischen Primary erzwingt eine Wahl) und dann der beschädigte Knoten über Initial Sync neu aufgebaut werden. Dieser Ansatz vermeidet jeden Rückgriff auf --repair und bewahrt die transaktionale ACID-Konsistenz des Replica-Sets.

Vergleich der Drittanbieter-Werkzeuge für beschädigte Datenbanken

Wenn native Werkzeuge (innodb_force_recovery, pg_resetwal, --repair) nicht ausreichen, greifen mehrere spezialisierte Drittanbieter-Werkzeuge ein. Hier sind die vier wichtigsten.

Für PostgreSQL erreicht kein kostenpflichtiges Drittanbieter-Werkzeug die nativen Werkzeuge (pg_resetwal, pg_filedump, pg_dirtyread). Erfahrene PostgreSQL-Administratoren arbeiten ausschließlich mit diesen Werkzeugen + einer robusten Streaming-Replikations-Strategie.

Professionelles Labor: Orientierungsschwellen und Kosten 2026

Vier Situationen verlangen die Orientierung an ein spezialisiertes Datenbanklabor statt eines internen Versuchs. Erstens: Transparent Data Encryption (TDE) MS SQL Server mit verlorenen OEM-Schlüsseln. Zweitens: Oracle Database mit beschädigtem ASM, die zertifizierte Oracle-DBA-Kompetenzen erfordert. Drittens: Cassandra- oder ScyllaDB-Multi-Region-Cluster mit Merkle-Tree-Beschädigung. Viertens: ausgefallenes physisches Volume, das das Software-Klonen des Datenverzeichnisses verhindert — Orientierung an ein Hardware-Labor zur SSD-/HDD-/NVMe-Wiederherstellung vor jedem DBMS-Verfahren.

Spezialisierte Datenbanklabore umfassen 2026 Ontrack Database Recovery Services (USA, UK, Deutschland), DriveSavers Database Specialist Team (USA), Stellar Data Recovery Database Services (Indien, globale Präsenz), Recoveo Database (Polen) und Kroll Ontrack Forensics Database (juristische Forensik). Im Mai 2026 beobachtete öffentliche Preise:

• MySQL oder PostgreSQL Consumer / KMU: 1.200 bis 3.500 € (Pauschaldiagnose + Wiederherstellung + Wiederherstellen)
• MongoDB WiredTiger Replica-Set: 3.500 bis 9.000 € (je nach Volumen und Anzahl der Shards)
• MS SQL Server Enterprise: 5.500 bis 16.000 € (beschädigte MDF/LDF, TDE aktiv)
• Oracle Database Enterprise: 9.000 bis 28.000 € (ASM, RAC, RMAN forensisch)
• Cassandra / ScyllaDB Cluster: 8.000 bis 22.000 € (Merkle-Tree-Rekonstruktion, Multi-Region)

Siehe unseren BitLocker-Leitfaden für die Besonderheiten der Microsoft-OEM-Schlüsselverschlüsselung. Für NAS, die beschädigte dockerisierte Datenbanken beherbergen, konsultieren Sie unseren RAID-Wiederherstellungsleitfaden.

Präventionsstrategie 2026: die einzige echte Verteidigungslinie

Die große Mehrheit der Datenbankwiederherstellungsfälle wäre vermieden oder in unter 30 Minuten gelöst worden, wenn drei Praktiken vorhanden gewesen wären. Erstens: tägliches logisches Backup (mysqldump, pg_dump, mongodump) auf Remote-Speicher, durch monatliche Wiederherstellung getestet. Zweitens: stündliches physisches Backup (Percona XtraBackup, pg_basebackup, MongoDB Cloud Backup) mit ZFS- oder Btrfs-Snapshot des Datenverzeichnisses. Drittens: Streaming-Replikation oder Replica-Set mit mindestens 2 Secondary-Knoten auf unabhängigem Speicher.

Für eingeschränkte Budgets bleibt das lebenswichtige Minimum ein tägliches mysqldump/pg_dump/mongodump auf verschlüsselten S3-Speicher + monatlicher Wiederherstellungstest auf einer Staging-Instanz. Diese Strategie genügt, um einen katastrophalen Vorfall in eine einfache zweistündige Unannehmlichkeit zu verwandeln.

FAQ — Häufig gestellte Fragen zur Datenbankwiederherstellung

MySQL InnoDB startet nicht: welches innodb_force_recovery verwenden?

Immer zuerst innodb_force_recovery=1. Die Stufen 1 bis 3 genügen in der großen Mehrheit der Fälle. Ab Stufe 4 sofort über mysqldump --all-databases exportieren, ohne zu schreiben.

PostgreSQL startet nach Absturz nicht: ist pg_resetwal die Lösung?

Nicht als erstes Mittel. pg_resetwal kann den Verlust committeter Daten verursachen. Testen Sie zuerst pg_basebackup vom Standby, prüfen Sie die WAL-Archive, werten Sie physische Backups aus. Falls unvermeidlich, auf einer KOPIE, niemals auf der Produktivumgebung.

Funktioniert MongoDB --repair auf WiredTiger 7.0.x?

Ja, aber mit Einschränkungen. Kann unzugängliche Collections dauerhaft löschen — sichern Sie den dbpath zuvor vollständig. Bei Replica-Sets ist das Stoppen des beschädigten Primary und Wiederherstellen von einem gesunden Secondary über Initial Sync sicherer.

Unterschied zwischen Datenbankwiederherstellung und klassischer Dateisystem-Wiederherstellung?

Drei Unterschiede: (1) interne Indizes, Constraints, Trigger, die nur DBMS-Werkzeuge rekonstruieren; (2) versionierte proprietäre Binärformate (.ibd, .wt, base/); (3) ACID-Transaktionen, die intakte binlog, WAL, oplog erfordern.

Wie viel kostet professionelle Datenbankwiederherstellung 2026?

MySQL/PostgreSQL Consumer: 1.200–3.500 €. MongoDB WiredTiger: 3.500–9.000 €. MS SQL Server: 5.500–16.000 €. Oracle Enterprise: 9.000–28.000 €. Cassandra-Cluster: 8.000–22.000 €. Drittanbieter-Werkzeuge: Stellar 299–599 $, EaseUS MS SQL 299 $.

Fazit: transaktionale Prävention zuerst, forensische Wiederherstellung zweitrangig

Die Datenbankwiederherstellung bleibt 2026 asymmetrisch: Prävention (getestete Backups + Replikations-Standby + proaktives Monitoring) kostet einen kleinen Bruchteil der DBA-Zeit und löst die überwiegende Mehrheit der Vorfälle in Minuten. Forensische Wiederherstellung ohne Prävention kostet je nach DBMS und Komplexität zwischen 1.200 € und 28.000 €.

Für MySQL und MariaDB genügt die Kombination Percona XtraBackup täglich + binlog aktiviert + mysqldump --single-transaction wöchentlich, um die überwiegende Mehrheit der Szenarien abzudecken. Für PostgreSQL bleibt Streaming-Replikation mit 1 synchronen und 1 asynchronen Standby + wöchentlichem pg_basebackup der Goldstandard 2026. Für MongoDB ist ein Replica-Set mit mindestens 3 Knoten, täglichen mongodump-Backups und monatlichem MongoDB Cloud Backup obligatorisch.

Wenn die Wiederherstellung unvermeidlich wird, lautet die absolute Regel in einer Zeile: immer auf einer Kopie des Datenverzeichnisses arbeiten, niemals auf der Quell-Produktivumgebung. Diese einfache Vorsichtsmaßnahme ist es, die eine saubere Wiederherstellung von einem Totalverlust trennt: Das Arbeiten von einem korrekten Klon schützt die Daten, während das Ausführen des Verfahrens direkt auf der beschädigten Produktivumgebung riskiert, alles zu verlieren.