<WRAP rww-page-header>
<WRAP rww-page-header-main>
<WRAP rww-page-title>
====== MariaDB-Recovery nach InnoDB-Absturz ======
</WRAP>

<WRAP rww-page-icon>
<iconify mdi:database-alert>
</WRAP>
</WRAP>

<WRAP rww-page-back>
[[werkzeuge:mariadb:start|← MariaDB]] · [[:start|Startseite]]
</WRAP>
</WRAP>

----

Diese Anleitung dokumentiert die erfolgreiche Wiederherstellung einer beschädigten lokalen MariaDB-Installation.

Sie basiert auf einem konkreten Recovery-Fall vom **17.08.2026** unter Windows mit XAMPP und MariaDB 10.4.32.

===== Ausgangslage =====

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

XAMPP meldete:

<code>
Fehler: MySQL wurde unerwartet beendet
</code>

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:

<code>
thecruiserblog_local
</code>

===== Ziel des Recovery-Verfahrens =====

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

Stattdessen wurde folgendes Vorgehen gewählt:

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

===== 1. Erste Diagnose =====

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

<code cmd>
netstat -ano | findstr :3306
</code>

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

==== MariaDB direkt in der Konsole starten ====

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

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

Der direkte Konsolenstart zeigte anschließend die konkrete Fehlermeldung.

===== 2. Beschädigte Aria-Systemtabelle =====

Der Konsolenstart zeigte zunächst folgende Fehlermeldung:

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

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

==== Tabellentyp feststellen ====

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

<code cmd>
dir E:\xampp\mysql\data\mysql\db.*
</code>

Vorhanden waren:

<code>
db.frm
db.MAD
db.MAI
</code>

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

==== Aria-Tabelle reparieren ====

Vor der Reparatur muss MariaDB vollständig gestoppt sein.

Die beschädigte Tabelle wurde mit ''aria_chk'' repariert:

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

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

<code>
Wrong CRC on datapage at 1
- Fixing index 1
- Fixing index 2
State updated
</code>

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:

<WRAP important>
Die beschädigte Aria-Systemtabelle war nicht die einzige Ursache. Es musste eine weitere Diagnose des MariaDB-Datenbestands erfolgen.
</WRAP>

===== 3. InnoDB-Schaden feststellen =====

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:

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

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

<code>
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)
</code>

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

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

==== Wichtig: Keine vorschnellen Eingriffe ====

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

Insbesondere wurden folgende Dateien nicht verändert:

<code>
ibdata1
ib_logfile*
</code>

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

<WRAP important>
Bei einem InnoDB-Schaden sollte der vorhandene Datenbestand zunächst erhalten bleiben.

Das erste Ziel ist die **Rettung der Daten**, nicht die Reparatur durch Löschen oder Austauschen zentraler InnoDB-Dateien.
</WRAP>

==== Entscheidung für den Recovery-Modus ====

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.

===== 4. InnoDB-Recovery-Modus =====

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

Die Konfigurationsdatei befindet sich in dieser Installation unter:

<code>
E:\xampp\mysql\bin\my.ini
</code>

Unterhalb des Abschnitts

<code ini>
[mysqld]
</code>

wurde zunächst folgende Zeile ergänzt:

<code ini>
innodb_force_recovery=1
</code>

MariaDB startete damit weiterhin nicht.

==== Recovery-Level schrittweise erhöhen ====

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:

^ Recovery-Level ^ Ergebnis ^
| ''1'' | MariaDB stürzt ab |
| ''2'' | MariaDB stürzt ab |
| ''3'' | MariaDB stürzt ab |
| ''4'' | MariaDB stürzt ab |
| ''5'' | MariaDB stürzt ab |
| ''6'' | **MariaDB startet** |

Erst mit:

<code ini>
innodb_force_recovery=6
</code>

blieb MariaDB gestartet.

==== Recovery-Modus dient nur zur Datenrettung ====

<WRAP important>
''innodb_force_recovery'' repariert die beschädigte InnoDB-Datenbank **nicht**.

Der Recovery-Modus dient dazu, einen beschädigten Datenbestand möglichst noch lesbar zu machen, damit wichtige Daten exportiert werden können.
</WRAP>

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

==== Grundregel für den Recovery-Level ====

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

<code>
1 → 2 → 3 → 4 → 5 → 6
</code>

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

<WRAP tip>
Immer den **niedrigsten Recovery-Level verwenden, mit dem MariaDB startet**.

Im konkreten Fall war Level 6 notwendig.
</WRAP>

===== 5. Datenbanken sichern =====

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

Die wichtigste Datenbank war:

<code>
thecruiserblog_local
</code>

==== TCB-Datenbank mit WP-CLI exportieren ====

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:

<code cmd>
cd /d E:\xampp\htdocs\thecruiserblog
</code>

Anschließend wurde der Datenbank-Dump erstellt:

<code cmd>
wp db export E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql
</code>

WP-CLI bestätigte den erfolgreichen Export:

<code>
Success: Exported to 'E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql'.
</code>

==== SQL-Dump kontrollieren ====

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

<code cmd>
dir E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql
</code>

Der erzeugte Dump hatte eine Größe von:

<code>
8.859.273 Bytes
</code>

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

<WRAP important>
Eine Erfolgsmeldung allein sollte nicht genügen.

Nach einem Recovery-Export immer zusätzlich prüfen, ob die SQL-Datei tatsächlich vorhanden ist und eine plausible Dateigröße besitzt.
</WRAP>

==== SQL-Dump zusätzlich extern sichern ====

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.

==== Vorhandene Datenbanken anzeigen ====

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

<code cmd>
E:\xampp\mysql\bin\mysql.exe -u root -e "SHOW DATABASES;"
</code>

Die Ausgabe enthielt:

<code>
information_schema
mysql
performance_schema
phpmyadmin
rowakecms
rowakewp
test
thecruiserblog_local
</code>

Die Datenbanken

<code>
information_schema
mysql
performance_schema
phpmyadmin
</code>

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

Eigene Datenbanken waren:

<code>
rowakecms
rowakewp
test
thecruiserblog_local
</code>

==== Weitere Datenbanken sichern ====

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

Beispiel:

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

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:

<WRAP tip>
Solange eine beschädigte MariaDB-Installation im Recovery-Modus noch lesbar ist, lieber eine möglicherweise nicht mehr benötigte eigene Datenbank zusätzlich exportieren als sie später zu vermissen.
</WRAP>

==== Ergebnis der logischen Datensicherung ====

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

<code>
TCB_recovery_20260817.sql
</code>

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

===== 6. Zusätzliche Rohsicherung =====

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:

<code>
E:\xampp\mysql\data
</code>

wurde vollständig kopiert nach:

<code>
E:\xampp\mysql\data_backup_20260817
</code>

Wichtig war dabei:

<WRAP important>
Den Ordner an dieser Stelle **kopieren, nicht verschieben**.

Der originale Datenbestand bleibt zunächst unverändert erhalten.
</WRAP>

==== Warum zusätzlich zum SQL-Dump sichern? ====

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:

^ Sicherung ^ Zweck ^
| SQL-Dump | Logische Wiederherstellung der benötigten Datenbank |
| Kopie des ''data''-Ordners | Erhalt des ursprünglichen MariaDB-Datenbestands |

Die Sicherungsstruktur sah damit beispielsweise so aus:

<code>
E:\xampp\mysql\
├── data
├── data_backup_20260817
└── ...
</code>

==== Recovery-Modus anschließend deaktivieren ====

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

In:

<code>
E:\xampp\mysql\bin\my.ini
</code>

wurde die Zeile:

<code ini>
innodb_force_recovery=6
</code>

auskommentiert:

<code ini>
# innodb_force_recovery=6
</code>

MariaDB blieb während der folgenden Arbeiten weiterhin gestoppt.

<WRAP tip>
Den Recovery-Modus erst entfernen, wenn die benötigten Daten erfolgreich exportiert und zusätzlich gesichert wurden.
</WRAP>

===== 7. MariaDB sauber neu initialisieren =====

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.

==== Beschädigten Datenordner erhalten ====

Der bisherige Datenordner:

<code>
E:\xampp\mysql\data
</code>

wurde **nicht gelöscht**, sondern umbenannt in:

<code>
E:\xampp\mysql\data_defekt_20260817
</code>

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

<code>
E:\xampp\mysql\
├── data_backup_20260817
├── data_defekt_20260817
└── ...
</code>

<WRAP important>
Den beschädigten Datenbestand nicht löschen.

Er bleibt als zusätzliche Rückfallebene erhalten, bis die Wiederherstellung vollständig abgeschlossen und geprüft wurde.
</WRAP>

==== Neuen MariaDB-Datenbestand erzeugen ====

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

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

<code cmd>
cd /d E:\xampp\mysql\bin
</code>

Danach wurde die Initialisierung gestartet:

<code cmd>
mysql_install_db.exe --datadir="E:\xampp\mysql\data"
</code>

Die erfolgreiche Initialisierung wurde mit folgender Ausgabe bestätigt:

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

Damit existierte wieder ein neuer:

<code>
E:\xampp\mysql\data
</code>

mit frisch angelegten MariaDB-Systemtabellen.

==== MariaDB ohne Recovery-Modus testen ====

Nun wurde MariaDB über das XAMPP Control Panel gestartet.

Der entscheidende Test:

<code>
MySQL → Start
</code>

MariaDB blieb **grün und lief stabil**.

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

<code ini>
innodb_force_recovery
</code>

starten konnte.

<WRAP tip>
Zu diesem Zeitpunkt noch keine alten MariaDB-Systemdateien aus dem beschädigten ''data''-Ordner zurückkopieren.

Die benötigten eigenen Datenbanken werden anschließend ausschließlich aus den zuvor erstellten SQL-Dumps wiederhergestellt.
</WRAP>

===== 8. TCB-Datenbank wiederherstellen =====

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

Die benötigte Datenbank war:

<code>
thecruiserblog_local
</code>

Der zuvor erstellte SQL-Dump:

<code>
E:\xampp\htdocs\thecruiserblog\TCB_recovery_20260817.sql
</code>

==== Leere Datenbank neu anlegen ====

Zunächst wurde die Datenbank neu erstellt:

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

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

==== SQL-Dump importieren ====

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

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

Der Import lief ohne Fehlermeldung durch.

<WRAP important>
WordPress wurde zu diesem Zeitpunkt noch nicht geöffnet.

Zuerst wurde geprüft, ob die Datenbank tatsächlich korrekt wiederhergestellt worden war.
</WRAP>

==== Tabellen kontrollieren ====

Die vorhandenen Tabellen wurden mit folgendem Befehl angezeigt:

<code cmd>
E:\xampp\mysql\bin\mysql.exe -u root -e "USE thecruiserblog_local; SHOW TABLES;"
</code>

Unter anderem waren die zentralen WordPress-Tabellen wieder vorhanden:

<code>
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
</code>

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

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

==== WordPress-Adressen kontrollieren ====

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

<code cmd>
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');"
</code>

Die Ausgabe lautete:

<code>
home      http://thecruiserblog.local
siteurl   http://thecruiserblog.local
</code>

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

==== WordPress testen ====

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

Geprüft wurden:

  * Frontend
  * WordPress-Dashboard

Beide Bereiche luden wieder normal.

<WRAP tip>
Nach einer Wiederherstellung nicht sofort davon ausgehen, dass ein erfolgreicher SQL-Import automatisch eine funktionierende WordPress-Installation bedeutet.

Vor dem ersten Aufruf mindestens die vorhandenen Tabellen sowie ''home'' und ''siteurl'' kontrollieren.
</WRAP>

==== Ergebnis ====

Die Datenbank:

<code>
thecruiserblog_local
</code>

war damit erfolgreich aus dem Recovery-Dump wiederhergestellt.

TheCruiserBlog konnte anschließend wieder normal verwendet werden.

===== 9. Zusammenfassung und Merksätze =====

Das Recovery konnte erfolgreich abgeschlossen werden.

Der entscheidende Ablauf war:

<code>
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
</code>

==== Die wichtigsten Regeln ====

  * 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.

==== Was ausdrücklich nicht gemacht wurde ====

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

<WRAP important>
Bei einem Datenbank-Recovery steht zunächst die **Rettung der Daten** im Vordergrund.

Erst wenn SQL-Dumps und zusätzliche Sicherungen vorhanden sind, sollte mit dem Neuaufbau der beschädigten MariaDB-Installation begonnen werden.
</WRAP>

===== Konkreter Recovery-Fall =====

^ Punkt ^ Wert ^
| Datum | 17.08.2026 |
| Umgebung | Windows / XAMPP |
| MariaDB | 10.4.32 |
| betroffene Hauptdatenbank | ''thecruiserblog_local'' |
| erster Schaden | Aria-Systemtabelle ''mysql.db'' |
| weiterer Schaden | InnoDB-System-Tablespace |
| funktionierender Recovery-Level | ''innodb_force_recovery=6'' |
| TCB-Dump | ''TCB_recovery_20260817.sql'' |
| Dump-Größe | 8.859.273 Bytes |
| Ergebnis | **Recovery erfolgreich** |

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

<WRAP rww-to-top>
[[#mariadb-recovery_nach_innodb-absturz|↑]]
</WRAP>