Beschädigte SQLite-Datenbank reparieren — ohne sie hochzuladen

Datenbank lässt sich nicht öffnen? Stelle sie jetzt wieder her

1. Leg die .db- / .sqlite-Datei ab
2. Die Wiederherstellung läuft lokal
3. Lade eine frische, öffnungsfähige Datenbank herunter

Um eine malformed SQLite-Datenbank wiederherzustellen, „reparierst“ du nicht die kaputte Datei an Ort und Stelle — du liest alles heraus, was noch dekodierbar ist, und schreibst es in eine brandneue Datenbank, genau so, wie es SQLites eigener Befehl .recover macht. Das läuft direkt hier in deinem Browser: Leg die Datei oben ab, die Diagnose zeigt, was beschädigt ist, und die Wiederherstellungs-Engine baut das Schema neu auf und fügt jede Zeile wieder ein, die sie lesen kann. Es wird nichts installiert, und die Datenbank wird nie hochgeladen.

Die Fehler, die das abdeckt

Der klassische SQLITE_CORRUPT. Etwas in der Seitenstruktur der Datei ist inkonsistent — eine beschädigte B-Tree-Seite, ein falscher Cell-Pointer, ein Page-Count, der mit der Dateigröße nicht übereinstimmt. Die Engine stoppt beim ersten Problem, auf das sie trifft, aber die Seiten, die sie nie erreicht hat, sind meist in Ordnung, und ein Raw-Scan kann die Zeilen direkt aus ihnen herausziehen.

Das sagt SQLite, wenn die 16-Byte-Header-Magic („SQLite format 3\0“) falsch ist. Zwei sehr verschiedene Ursachen: Die Header-Bytes wurden beschädigt (die Seiten dahinter sind oft intakt und wiederherstellbar), oder die Datei ist tatsächlich etwas anderes — oder eine verschlüsselte (SQLCipher/SEE) Datenbank, die als hochentropisches Rauschen gelesen wird und sich ohne den Schlüssel nicht wiederherstellen lässt. Die Diagnose unterscheidet die beiden.

Nachgelagerte Symptome desselben zugrunde liegenden Seitenschadens. Wenn das erneute Öffnen der Datei denselben Fehler erzeugt, sind In-Place-Fixes am Ende, und ein Neuaufbau aus den überlebenden Seiten ist der nächste Schritt.

Wie eine SQLite-Datei kaputtgeht: Seiten und Zeiger

Eine SQLite-Datenbank ist ein flaches Array aus Seitenfester Größe (meist je 4 KB). Seite 1 enthält den Header und das Schema; jede Tabelle und jeder Index ist ein B-Tree, dessen innere Seiten hinunter auf Leaf-Seiten zeigen, die deine eigentlichen Zeilen enthalten. Software liest den Header, findet das Schema und folgt dann diesen Zeigern zu den Daten.

Die Zeiger sind die Schwachstelle. Ein einziger unterbrochener Schreibvorgang, ein defekter Sektor, ein auf halbem Weg gestoppter Sync oder ein Byte-Flip in einer inneren Seite, und die Zeigerkette bricht — SQLite trifft auf eine Inkonsistenz und erklärt das ganze Image für malformed, obwohl deine Zeilen unberührt in ihren Leaf-Seiten liegen. Es ist dieselbe Geschichte wie beim fehlenden Index eines Videos oder dem kaputten Central Directory eines ZIP: Die Karte ist kaputt, nicht die Daten.

Deshalb funktioniert die Wiederherstellung: Leaf-Seiten tragen selbstbeschreibende Records, sodass die Engine die Datei Seite für Seite ablaufen, die gefundenen Zeilen dekodieren und die B-Trees von Grund auf um sie herum neu aufbauen kann. Zeilen, die die Zeiger nicht erreichen können, werden durch einen Raw-Sweep gefunden; Zeilen, die zu keiner bekannten Tabelle passen, gehen in einelost_and_found-Tabelle, statt weggeworfen zu werden.

Wenn du eine -wal-Datei hast, bring sie mit

Datenbanken im WAL-Modus stellen jüngste Änderungen in einer Geschwisterdatei <name>-wal bereit, bis per Checkpoint in die Hauptdatenbank geschrieben wird. Nach einem Absturz können deine neuesten committeten Daten nur dort leben. Leg zuerst die Haupt-.db ab, füge dann die -wal-Datei im optionalen Sidecar-Slot hinzu: Ihre committeten Frames werden vor dem Scan überlagert, sodass die wiederhergestellte Datenbank die letzte committete Transaktion widerspiegelt und nicht den letzten Checkpoint. Es ist optional — die Wiederherstellung läuft auch mit der Hauptdatei allein einwandfrei —, aber wenn du das Sidecar hast, liegen dort oft die frischesten Zeilen.

Warum „kein Upload“ bei Datenbanken zählt

Denk daran, was eine Datenbank tatsächlich enthält: Nutzerkonten, Nachrichten, Standortverlauf, den gesamten Zustand einer App. Es ist genau die eine Datei, die du am wenigsten „nur zum Reparieren“ auf dem Server eines anderen liegen haben willst. Upload-basierte Wiederherstellungstools kopieren sie von deinem Rechner und verarbeiten sie auf einer Infrastruktur, die du nicht einsehen kannst. Die Wiederherstellung im Browser entfernt diesen Schritt vollständig — die Datei wird von deiner Festplatte gelesen, in deinem Tab neu aufgebaut, und es existiert nirgendwo sonst eine Kopie. Für DFIR-Arbeit an Beweismitteln bleibt so auch die Chain of Custody intakt: Das Artefakt verlässt die Workstation nie. Du kannst esim Netzwerk-Tab überprüfen, während die Wiederherstellung läuft.

Was das wiederherstellen kann und was nicht

Der Wiederherstellungsbericht listet auf, was aus jeder Tabelle herauskam, kennzeichnet Zeilen, die per Raw-Scan gezogen oder als nicht dekodierbar verworfen wurden, und eine fehlgeschlagene Wiederherstellung wird nie berechnet.