Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- werkzeuge:mariadb:recovery-innodb [18.08.2026 06:55] – admin
+++ werkzeuge:mariadb:recovery-innodb [29.09.2026 05:55] (aktuell) – admin
@@ Zeile 1: / Zeile 1: @@
-<WRAP rww-topic-header>
+<WRAP rww-page-header>
+<WRAP rww-page-header-main>
-<WRAP rww-topic-heading>
+<WRAP rww-page-title>
 ====== MariaDB-Recovery nach InnoDB-Absturz ======
 </WRAP>
-<WRAP rww-topic-symbol>
+<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.
-<WRAP rww-back>
-[[werkzeuge:mariadb:start|←]] [[werkzeuge:mariadb:start|MariaDB]]
-</WRAP>
-----
 ===== Ausgangslage =====
@@ Zeile 476: / Zeile 476: @@
 </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>