Jetzt reparieren
- Datei ablegen
- Reparatur läuft lokal
- Ergebnis herunterladen
places.sqlite ist die einzige SQLite-Datenbank, in der Firefox deine gesamte Browser-Chronik, jedes Lesezeichen sowie Schlagwörter, Schlüsselwörter und Seiten-Anmerkungen speichert. Wenn sie beschädigt wird, siehst du entweder, wie Firefox sich stillschweigend zurücksetzt — die Lesezeichen tauchen wieder auf, aber die Chronik ist weg — oder ein Programm meldet "database disk image is malformed" ("Datenbank-Datenträgerabbild ist fehlerhaft"). Das ist SQLites SQLITE_CORRUPT (Ergebniscode 11): eine Seite oder ein Zeiger ist kaputtgegangen und die Engine verweigert die ganze Datei, obwohl deine Zeilen meist unberührt in ihren Blattseiten liegen. Zieh places.sqlite (oder die places.sqlite.corrupt-Datei, die Firefox zurückgelassen hat) oben hinein, und die Wiederherstellung geht die Seiten in deinem Browser durch, baut das Schema neu auf und schreibt eine frische, öffenbare Datenbank, ohne etwas hochzuladen.
Was places.sqlite enthält und was wirklich kaputtgegangen ist
Das gesamte Lesezeichen-und-Chronik-System von Firefox steckt in einer einzigen Datei. moz_places enthält eine Zeile pro URL, die du je besucht oder als Lesezeichen gespeichert hast — mit url, title, rev_host (dem umgekehrten Host, für schnelles Gruppieren nach Domain), visit_count, last_visit_date, einer guid, einem url_hash und frecency, einer Firefox-eigenen Bewertung, die frequency (Häufigkeit) und recency (Aktualität) kombiniert und die Vorschläge in der Adressleiste sortiert. Jeder einzelne Besuch ist eine Zeile in moz_historyvisits, deren place_id auf moz_places.id zurückverweist. Dein Lesezeichen-Baum ist moz_bookmarks: Jede Zeile trägt ein parent, eine position, einen title, eine guid und einen Fremdschlüssel fk auf moz_places. Der Baum hängt an festen Wurzelordnern mit dauerhaften, 12 Zeichen langen guids — root________, menu________ (Lesezeichen-Menü), toolbar_____ (Lesezeichen-Symbolleiste), unfiled_____ (Weitere Lesezeichen), mobile______ und tags________. Darum herum liegen moz_origins, moz_keywords, die Anmerkungstabellen moz_anno_attributes/moz_annos/moz_items_annos, moz_inputhistory und moz_meta. Favicons sind nicht hier — seit Firefox 55 liegen sie in einer separaten favicons.sqlite im selben Profil.
Physisch ist die Datei ein flaches Array aus Seiten fester Größe. Firefox erstellt places.sqlite mit einer Seitengröße von 32 KiB (PRAGMA page_size = 32768, einkompiliert als SQLITE_DEFAULT_PAGE_SIZE) — dem Achtfachen von SQLites Standard von 4 KiB — und betreibt sie im WAL-Modus, sodass du zwei Begleitdateien daneben findest: places.sqlite-wal (das Write-Ahead-Log) und places.sqlite-shm (einen Shared-Memory-Index). Seite 1 enthält den Header und das Schema; jede Tabelle und jeder Index ist ein B-Baum, dessen innere Seiten nach unten auf die Blattseiten zeigen, die deine Zeilen enthalten.
Diese Zeiger sind die Schwachstelle. Ein unterbrochener Schreibvorgang, ein Absturz mitten in einem Checkpoint, eine volle Festplatte, ein defekter Sektor oder ein gekipptes Byte in einer einzigen inneren 32-KiB-Seite reichen aus: SQLite folgt dem Zeiger, findet etwas, das keine gültige Seite ist, und erklärt das gesamte Abbild für fehlerhaft — während deine Zeilen unversehrt in den Blattseiten liegen, die es nie erreicht hat. Kaputt ist die Karte, nicht die Daten.
Was Firefox tut, wenn es die Beschädigung entdeckt — und warum die Chronik verschwindet
Firefox prüft places.sqlite beim Start. Wenn das Öffnen auf SQLITE_CORRUPT stößt oder eine Integritätsprüfung fehlschlägt, behandelt der Places-Dienst die Datei als unbrauchbar und tut etwas Drastisches, ohne zu fragen: Er benennt places.sqlite im Profilordner in places.sqlite.corrupt um, erstellt eine brandneue leere places.sqlite und stellt anschließend deine Lesezeichen aus der neuesten datierten Datei im Ordner bookmarkbackups wieder her — bookmarks-YYYY-MM-DD_<count>_<hash>.jsonlz4, komprimiert mit Mozillas mozLz4 (eine 8 Byte lange Magic mozLz40\0, dann eine 4 Byte lange dekomprimierte Größe in Little-Endian und danach ein LZ4-Block; kein reines LZ4, sodass gewöhnliche Werkzeuge es nicht öffnen können).
Hier ist der Haken, der die Leute nach einer Lösung suchen lässt: Nur die Lesezeichen werden auf diese Weise gesichert. Chronik, frecency-Bewertungen, Schlüsselwörter und Eingabe-Chronik werden nie in diese .jsonlz4-Dateien geschrieben, sodass ein Zurücksetzen stillschweigend deinen Lesezeichen-Baum neu aufbaut und alles andere verwirft. Deine Lesezeichen kommen tadellos zurück; Monate oder Jahre an Chronik sind einfach aus der aktiven Datenbank verschwunden.
Die Fehlermeldungen, die du tatsächlich siehst, und was sie bedeuten: database disk image is malformed ("Datenbank-Datenträgerabbild ist fehlerhaft") ist SQLITE_CORRUPT (Ergebniscode 11): eine beschädigte Seite, ein falscher Zell-Offset oder eine Seitenzahl, die nicht mit der Dateigröße übereinstimmt. file is not a database ("Datei ist keine Datenbank") ist SQLITE_NOTADB (Code 26): Die 16 Byte lange Header-Magic SQLite format 3\000 ist beschädigt, obwohl die Seiten dahinter oft intakt sind. Und The bookmarks and history system will not be functional because one of Firefox's files is in use by another application ("Das Lesezeichen- und Chronik-System ist nicht funktionsfähig, weil eine der Firefox-Dateien von einer anderen Anwendung verwendet wird") ist etwas ganz anderes — das ist eine Sperre (SQLITE_BUSY), meist ein zweiter Firefox-Prozess oder ein Antivirenprogramm, das die Datei hält, keine Beschädigung. Weil das Umbenennen automatisch geschieht, liegen die guten Daten schon in places.sqlite.corrupt und die aktive places.sqlite ist leer, sobald du die leere Symbolleiste bemerkst.
Wie die Wiederherstellung sie lokal neu aufbaut
Statt die kaputte Datei an Ort und Stelle zu flicken, liest das Werkzeug ihre 32-KiB-Seiten direkt aus, rekonstruiert das Schema aus Seite 1, geht den B-Baum jeder Tabelle durch und greift für die Zeilen, die die kaputten Zeiger nicht mehr erreichen, auf einen zeigerfreien Rohseiten-Scan zurück — dieselbe Strategie wie SQLites eigener Befehl .recover. Datensätze, die sich keiner bekannten Tabelle zuordnen lassen, werden in eine Tabelle lost_and_found gelegt, statt verworfen zu werden, sodass eine verstümmelte Zeile aus moz_places oder moz_bookmarks erhalten bleibt, statt wegzufallen. Wenn du die Begleitdatei places.sqlite-wal noch hast, füge sie im optionalen Feld hinzu: Im WAL-Modus können die neuesten Besuche und Lesezeichen nur in diesem Log liegen, bis ein Checkpoint erfolgt, und seine bestätigten Frames werden vor dem Scan überlagert. Das Ergebnis ist eine frische, öffenbare places.sqlite, die du herunterlädst: kopiere sie bei geschlossenem Firefox zurück ins Profil oder öffne sie schreibgeschützt, um Lesezeichen und Chronik zu exportieren.
Verwende die Datei places.sqlite.corrupt, wenn Firefox dein Profil bereits zurückgesetzt hat: dort ist deine Chronik noch. Um sie zu finden, öffne about:profiles und klicke beim verwendeten Profil auf "Open Directory" ("Verzeichnis öffnen", Root-Verzeichnis) oder gehe direkt zu %APPDATA%\Mozilla\Firefox\Profiles\<name> unter Windows, ~/Library/Application Support/Firefox/Profiles/<name> unter macOS oder ~/.mozilla/firefox/<name> unter Linux. Kopiere die Datei heraus, während Firefox vollständig geschlossen ist, damit nichts sie sperrt.
Warum das nicht hochgeladen werden darf: places.sqlite ist, ganz wörtlich, ein vollständiges Protokoll jeder Seite, die du je besucht hast. Es ist die eine Datei, die du am wenigsten auf den Server einer Reparaturfirma kopiert sehen möchtest, "nur um sie zu reparieren", unter Aufbewahrungsbedingungen, die du nie gelesen hast. Hier wird sie von deiner Festplatte gelesen und im Browser-Tab neu aufgebaut — du kannst das Netzwerk-Panel (Network) öffnen und bestätigen, dass 0 Byte der Datenbank je deinen Rechner verlassen.
Was sich reparieren lässt und was nicht
Kann repariert werden
- "database disk image is malformed" durch eine beschädigte 32-KiB-Seite oder einen kaputten B-Baum-Zeiger, wenn die Blattseiten mit deinen Zeilen überleben
- Die Chronik, die Firefox beim Zurücksetzen verwirft: moz_places- und moz_historyvisits-Zeilen, die direkt aus der Datei geholt werden, auch nach einer reinen Lesezeichen-Wiederherstellung
- Die places.sqlite.corrupt-Datei, die Firefox beim Zurücksetzen deines Profils umbenannt hat
- Ein beschädigter Header ("file is not a database"), wenn die Seiten hinter der 16 Byte langen SQLite-Magic intakt sind
- Besuche und Lesezeichen ohne Checkpoint aus einer bereitgestellten places.sqlite-wal-Begleitdatei
Kann nicht repariert werden
- Zeilen, die physisch überschrieben oder am Dateiende abgeschnitten wurden: diese Bytes existieren nicht mehr
- Eine places.sqlite, die Firefox bereits durch eine frische, leere Datenbank ersetzt hat (stelle stattdessen die umbenannte .corrupt-Datei wieder her)
- Favicons neu aufbauen: die liegen in einer separaten favicons.sqlite; stelle diese Datei einzeln wieder her
- Eine .jsonlz4-Lesezeichensicherung entpacken: das ist ein mozLz4-Archiv, keine SQLite-Datenbank (importiere sie stattdessen aus Firefox' eigener Bibliothek)
- Eine 0-Byte-Datei oder eine, die von Anfang bis Ende hochentropisches Rauschen ist (dann kommt zuerst eine Datenrettung des Speichergeräts)
Wenn eine Reparatur fehlschlägt, sagen wir dir warum (fehlende Daten gegenüber beschädigter Struktur), und für eine fehlgeschlagene Reparatur wird dir nie etwas berechnet.