MariaDB-Recovery nach InnoDB-Absturz

MariaDB ließ sich über das XAMPP Control Panel nicht mehr dauerhaft starten.

XAMPP meldete:

Fehler: MySQL wurde unerwartet beendet

Im Verlauf der Diagnose wurden zwei unterschiedliche Schäden festgestellt:

• beschädigte Aria-Systemtabelle mysql.db
• anschließender InnoDB-Absturz während der Crash-Recovery

Die wichtigste zu rettende Datenbank war:

thecruiserblog_local

Ziel war nicht, die beschädigte MariaDB-Installation dauerhaft weiterzuverwenden.

Stattdessen wurde folgendes Vorgehen gewählt:

1. Ursache des Fehlers feststellen
2. Daten möglichst sicher exportieren
3. beschädigten Datenbestand zusätzlich sichern
4. MariaDB sauber neu initialisieren
5. benötigte Datenbank aus dem SQL-Dump wiederherstellen

Zunächst wurde geprüft, ob der MariaDB-Standard-Port 3306 bereits von einem anderen Prozess verwendet wurde.

netstat -ano | findstr :3306

Im konkreten Fall gab es keine Ausgabe. Ein Portkonflikt konnte damit ausgeschlossen werden.

Um die eigentliche Ursache sichtbar zu machen, wurde MariaDB direkt über die Windows-Eingabeaufforderung gestartet:

cd /d E:\xampp\mysql\bin
mysqld.exe --defaults-file="E:\xampp\mysql\bin\my.ini" --console

Der direkte Konsolenstart zeigte anschließend die konkrete Fehlermeldung.

Der Konsolenstart zeigte zunächst folgende Fehlermeldung:

Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
Fatal error: Can't open and lock privilege tables

Damit war die MariaDB-Systemtabelle mysql.db als beschädigt erkannt.

Zunächst wurden die zugehörigen Dateien geprüft:

dir E:\xampp\mysql\data\mysql\db.*

Vorhanden waren:

db.frm
db.MAD
db.MAI

Die Dateiendungen .MAD und .MAI zeigen, dass es sich um eine Aria-Tabelle handelt.

Vor der Reparatur muss MariaDB vollständig gestoppt sein.

Die beschädigte Tabelle wurde mit aria_chk repariert:

cd /d E:\xampp\mysql\bin
aria_chk.exe -r E:\xampp\mysql\data\mysql\db.MAI

Während der Reparatur wurden unter anderem folgende Meldungen ausgegeben:

Wrong CRC on datapage at 1
- Fixing index 1
- Fixing index 2
State updated

Die Meldung Wrong CRC on datapage bestätigte eine beschädigte Datenseite.

Nach der Reparatur ließ sich MariaDB zunächst wieder starten.

Beim anschließenden Zugriff auf WordPress stürzte MariaDB jedoch erneut ab.

Damit war klar:

Nach der Reparatur der Aria-Systemtabelle ließ sich MariaDB zunächst starten, stürzte beim Zugriff auf WordPress jedoch erneut ab.

Deshalb wurde MariaDB nochmals direkt über die Konsole gestartet:

cd /d E:\xampp\mysql\bin
mysqld.exe --defaults-file="E:\xampp\mysql\bin\my.ini" --console

Diesmal erschien während der InnoDB-Crash-Recovery die entscheidende Fehlermeldung:

InnoDB: Starting crash recovery from checkpoint LSN=58097070
InnoDB: Starting final batch to recover 2 pages from redo log.

[FATAL] InnoDB: Trying to read page number 14650 in space 0,
space name innodb_system, which is outside the tablespace bounds.

Please check that the configuration matches the
InnoDB system tablespace location (ibdata files)

Damit war klar, dass zusätzlich ein Problem im InnoDB-System-Tablespace vorlag.

Der normale Start von MariaDB war nicht mehr möglich.

An diesem Punkt wurden bewusst keine InnoDB-Dateien gelöscht oder ersetzt.

Insbesondere wurden folgende Dateien nicht verändert:

ibdata1
ib_logfile*

Auch der vorhandene MariaDB-Datenordner wurde nicht gelöscht.

Da MariaDB nicht mehr normal gestartet werden konnte, wurde als nächster Schritt der InnoDB-Recovery-Modus verwendet.

Dabei sollte zunächst der niedrigste Recovery-Level getestet und nur bei Bedarf schrittweise erhöht werden.

Für die Datenrettung wurde in der MariaDB-Konfiguration der Parameter innodb_force_recovery verwendet.

Die Konfigurationsdatei befindet sich in dieser Installation unter:

E:\xampp\mysql\bin\my.ini

Unterhalb des Abschnitts

[mysqld]

wurde zunächst folgende Zeile ergänzt:

innodb_force_recovery=1

MariaDB startete damit weiterhin nicht.

Der Wert wurde deshalb schrittweise erhöht.

Nach jeder Änderung wurde my.ini gespeichert und MariaDB erneut über das XAMPP Control Panel gestartet.

Das Ergebnis des konkreten Recovery-Falls:

Erst mit:

innodb_force_recovery=6

blieb MariaDB gestartet.

Deshalb wurde MariaDB mit Recovery-Level 6 nicht wieder normal verwendet.

Insbesondere wurde:

• TheCruiserBlog nicht im Browser geöffnet
• nicht mit WordPress weitergearbeitet
• keine Datenbankänderung durchgeführt
• unmittelbar mit der Datensicherung begonnen

Es sollte immer mit dem niedrigsten Recovery-Level begonnen werden:

1 → 2 → 3 → 4 → 5 → 6

Nur wenn MariaDB mit dem jeweiligen Level nicht startet, wird der Wert erhöht.

Nachdem MariaDB mit innodb_force_recovery=6 gestartet war, wurde sofort mit der Datensicherung begonnen.

Die wichtigste Datenbank war:

thecruiserblog_local

Da WP-CLI für TheCruiserBlog bereits eingerichtet war, wurde die Datenbank direkt aus dem WordPress-Verzeichnis exportiert.

Zunächst wurde in das Projektverzeichnis gewechselt:

cd /d E:\xampp\htdocs\thecruiserblog

Anschließend wurde der Datenbank-Dump erstellt:

wp db export E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

WP-CLI bestätigte den erfolgreichen Export:

Success: Exported to 'E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql'.

Nach dem Export wurde geprüft, ob die Datei tatsächlich vorhanden war:

dir E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

Der erzeugte Dump hatte eine Größe von:

8.859.273 Bytes

Damit lag eine plausible SQL-Sicherung der TCB-Datenbank vor.

Der erzeugte Dump wurde anschließend zusätzlich außerhalb des XAMPP-Bereichs gesichert.

Damit blieb die Datenbanksicherung auch dann erhalten, wenn beim späteren Neuaufbau der lokalen MariaDB-Installation etwas schiefgehen sollte.

Bevor MariaDB neu aufgebaut wurde, wurden alle vorhandenen Datenbanken aufgelistet:

E:\xampp\mysql\bin\mysql.exe -u root -e "SHOW DATABASES;"

Die Ausgabe enthielt:

information_schema
mysql
performance_schema
phpmyadmin
rowakecms
rowakewp
test
thecruiserblog_local

Die Datenbanken

information_schema
mysql
performance_schema
phpmyadmin

gehörten zum MariaDB-/XAMPP-System und waren nicht die Grundlage für die spätere Wiederherstellung.

Eigene Datenbanken waren:

rowakecms
rowakewp
test
thecruiserblog_local

Solange MariaDB im Recovery-Modus noch lief, wurden vorsichtshalber auch die übrigen eigenen Datenbanken exportiert.

Beispiel:

E:\xampp\mysql\bin\mysqldump.exe -u root rowakecms > E:\xampp\htdocs\rowakecms_recovery_20260817.sql

Analog wurden auch rowakewp und test gesichert.

Später stellte sich heraus, dass diese drei Datenbanken nicht mehr benötigt wurden.

Die Sicherung war trotzdem sinnvoll:

Für die benötigte TCB-Datenbank stand nun ein eigenständiger SQL-Dump zur Verfügung:

TCB_recovery_20260817.sql

Damit war die wichtigste Voraussetzung für den anschließenden Neuaufbau von MariaDB erfüllt.

Nachdem die benötigten Datenbanken als SQL-Dumps gesichert waren, wurde zusätzlich der komplette MariaDB-Datenordner gesichert.

Dazu wurde MariaDB zunächst über das XAMPP Control Panel vollständig gestoppt.

Der vorhandene Datenordner:

E:\xampp\mysql\data

wurde vollständig kopiert nach:

E:\xampp\mysql\data_backup_20260817

Wichtig war dabei:

Der SQL-Dump ist die wichtigste Grundlage für die spätere Wiederherstellung der benötigten Datenbank.

Die zusätzliche Kopie des kompletten data-Ordners bildet jedoch eine zweite Rückfallebene.

Damit standen zwei voneinander unabhängige Sicherungen zur Verfügung:

Die Sicherungsstruktur sah damit beispielsweise so aus:

E:\xampp\mysql\
├── data
├── data_backup_20260817
└── ...

Erst nachdem SQL-Dump und Rohsicherung vorhanden waren, wurde der Recovery-Modus wieder deaktiviert.

In:

E:\xampp\mysql\bin\my.ini

wurde die Zeile:

innodb_force_recovery=6

auskommentiert:

# innodb_force_recovery=6

MariaDB blieb während der folgenden Arbeiten weiterhin gestoppt.

Nachdem SQL-Dump und Rohsicherung vorhanden waren und der Recovery-Modus deaktiviert war, konnte MariaDB neu aufgebaut werden.

MariaDB musste dabei weiterhin vollständig gestoppt sein.

Der bisherige Datenordner:

E:\xampp\mysql\data

wurde nicht gelöscht, sondern umbenannt in:

E:\xampp\mysql\data_defekt_20260817

Damit waren nun zwei Kopien des ursprünglichen Datenbestands vorhanden:

E:\xampp\mysql\
├── data_backup_20260817
├── data_defekt_20260817
└── ...

Anschließend wurde eine neue, leere MariaDB-Datenstruktur erzeugt.

Dazu wurde zunächst in das MariaDB-Programmverzeichnis gewechselt:

cd /d E:\xampp\mysql\bin

Danach wurde die Initialisierung gestartet:

mysql_install_db.exe --datadir="E:\xampp\mysql\data"

Die erfolgreiche Initialisierung wurde mit folgender Ausgabe bestätigt:

Running bootstrap
Removing default user
Creating my.ini file
Creation of the database was successful

Damit existierte wieder ein neuer:

E:\xampp\mysql\data

mit frisch angelegten MariaDB-Systemtabellen.

Nun wurde MariaDB über das XAMPP Control Panel gestartet.

Der entscheidende Test:

MySQL → Start

MariaDB blieb grün und lief stabil.

Damit war bestätigt, dass die frisch initialisierte MariaDB-Installation wieder ohne:

innodb_force_recovery

starten konnte.

Nachdem MariaDB mit einem frisch initialisierten Datenbestand wieder stabil lief, konnte die zuvor gesicherte WordPress-Datenbank wiederhergestellt werden.

Die benötigte Datenbank war:

thecruiserblog_local

Der zuvor erstellte SQL-Dump:

E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

Zunächst wurde die Datenbank neu erstellt:

E:\xampp\mysql\bin\mysql.exe -u root -e "CREATE DATABASE thecruiserblog_local CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Damit stand eine neue und leere Datenbank für den Import zur Verfügung.

Anschließend wurde der zuvor gerettete SQL-Dump importiert:

E:\xampp\mysql\bin\mysql.exe -u root thecruiserblog_local < E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql

Der Import lief ohne Fehlermeldung durch.

Die vorhandenen Tabellen wurden mit folgendem Befehl angezeigt:

E:\xampp\mysql\bin\mysql.exe -u root -e "USE thecruiserblog_local; SHOW TABLES;"

Unter anderem waren die zentralen WordPress-Tabellen wieder vorhanden:

wp_commentmeta
wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_term_relationships
wp_term_taxonomy
wp_termmeta
wp_terms
wp_usermeta
wp_users

Zusätzlich waren auch die Tabellen der verwendeten Plugins wieder vorhanden.

Damit war bestätigt, dass der SQL-Dump erfolgreich importiert worden war.

Vor dem ersten Aufruf von WordPress wurden zusätzlich die beiden zentralen Einstellungen home und siteurl geprüft:

E:\xampp\mysql\bin\mysql.exe -u root -e "USE thecruiserblog_local; SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Die Ausgabe lautete:

home      http://thecruiserblog.local
siteurl   http://thecruiserblog.local

Damit zeigte die wiederhergestellte Datenbank weiterhin auf die korrekte lokale WordPress-Installation.

Erst nach diesen Prüfungen wurde TheCruiserBlog wieder im Browser geöffnet.

Geprüft wurden:

• Frontend
• WordPress-Dashboard

Beide Bereiche luden wieder normal.

Die Datenbank:

thecruiserblog_local

war damit erfolgreich aus dem Recovery-Dump wiederhergestellt.

TheCruiserBlog konnte anschließend wieder normal verwendet werden.

Das Recovery konnte erfolgreich abgeschlossen werden.

Der entscheidende Ablauf war:

Fehler diagnostizieren
        ↓
Aria-Systemtabelle prüfen und reparieren
        ↓
InnoDB-Schaden erkennen
        ↓
innodb_force_recovery schrittweise erhöhen
        ↓
MariaDB startet im Recovery-Modus
        ↓
SQL-Dumps erstellen
        ↓
SQL-Dumps zusätzlich sichern
        ↓
kompletten data-Ordner sichern
        ↓
Recovery-Modus deaktivieren
        ↓
beschädigten data-Ordner erhalten
        ↓
MariaDB neu initialisieren
        ↓
Datenbank neu anlegen
        ↓
SQL-Dump importieren
        ↓
Tabellen und WordPress-URLs prüfen
        ↓
Frontend und Dashboard testen

• Nicht sofort Dateien aus mysql\data löschen.
• Zuerst das MariaDB-Error-Log prüfen.
• MariaDB bei Bedarf direkt mit –console starten, um die konkrete Fehlermeldung zu sehen.
• Einen möglichen Portkonflikt auf Port 3306 ausschließen.
• .MAI und .MAD weisen auf eine Aria-Tabelle hin.
• aria_chk nur verwenden, wenn MariaDB gestoppt ist.
• innodb_force_recovery immer mit Level 1 beginnen.
• Den Recovery-Level nur erhöhen, wenn MariaDB mit dem niedrigeren Level nicht startet.
• Immer den niedrigsten funktionierenden Recovery-Level verwenden.
• Recovery-Modus ausschließlich zur Datenrettung verwenden.
• Sobald MariaDB im Recovery-Modus läuft, zuerst die benötigten Datenbanken exportieren.
• SQL-Dumps nach dem Export auf Existenz und plausible Dateigröße prüfen.
• Wichtige Dumps zusätzlich außerhalb des XAMPP-Bereichs sichern.
• Vor dem Neuaufbau zusätzlich den kompletten data-Ordner sichern.
• Den beschädigten Datenbestand nicht vorschnell löschen.
• Alte MariaDB-Systemdateien nicht ungeprüft in eine frisch initialisierte Installation zurückkopieren.
• Eigene Datenbanken bevorzugt aus SQL-Dumps wiederherstellen.
• Nach dem Import die vorhandenen Tabellen kontrollieren.
• Bei WordPress zusätzlich home und siteurl prüfen.
• Erst danach WordPress wieder normal verwenden.

Während des Recovery-Verfahrens wurden insbesondere folgende Maßnahmen vermieden:

• ibdata1 löschen
• ib_logfile* vorschnell löschen
• beschädigte Systemtabellen ungeprüft zurückkopieren
• WordPress während des Recovery-Modus normal weiterverwenden
• den beschädigten data-Ordner vor erfolgreicher Wiederherstellung löschen

TheCruiserBlog konnte nach der Neuinitialisierung von MariaDB und dem Import des SQL-Dumps wieder normal über Frontend und WordPress-Dashboard verwendet werden.