n8n meldet SQLITE_CORRUPT: Datenbank sicher eingrenzen

n8n startet nicht mehr oder Datenbankzugriffe enden mit SQLITE_CORRUPT. In dieser Situation sind spontane Aufräumaktionen besonders ungünstig: Eine zusätzliche Veränderung kann Hinweise zerstören und die Wiederherstellung erschweren. Sichere zuerst einen konsistenten Bestand und kläre, welcher letzte bekannte gute Stand verfügbar ist.

Historischer Fall, weiterhin relevante Abgrenzung

Ein Bericht von 2022 schildert eine beschädigte SQLite-Datenbank nach manuellen Eingriffen und dem Entfernen einer Journaldatei. Er ist kein Beleg für einen aktuellen allgemeinen n8n-Fehler. Q1 SQLite warnt ausdrücklich vor Eingriffen in aktive Journale und vor unpassenden Kopien laufender Datenbanken. Auch eine technische Datenrettung kann unvollständige oder widersprüchliche Ergebnisse liefern. Q2 Q3

Bei n8n gehört außerdem der verwendete Verschlüsselungsschlüssel zur Wiederherstellungsplanung, weil damit gespeicherte Zugangsdaten geschützt werden. Eine Datenbankdatei allein ersetzt diesen Schlüssel nicht. Q4

Die ersten sinnvollen Schritte

1. Weitere Schreibzugriffe geordnet stoppen. Stelle mit dem zuständigen Betreiber fest, welche n8n-Prozesse auf die Datenbank zugreifen. Erhalte Protokolle und stoppe automatische Neustartschleifen, bevor weitere Experimente beginnen.
2. Originalbestand erhalten. Sichere die Datenbank zusammen mit vorhandenen WAL-, SHM- oder Journaldateien, Konfiguration und Schlüsselmaterial als zusammengehörigen Bestand. Die konkrete konsistente Sicherungsmethode hängt vom Betriebszustand ab; kopiere eine aktive Datei nicht nach Belieben zwischen Prozessen.
3. Umgebungsfehler prüfen. Untersuche freien Speicher, Dateisystemfehler, Datenträgerzustand und die Zeitlinie der letzten Änderungen. Ein wiederholt fehlerhafter Datenträger würde auch eine zurückgespielte Datenbank gefährden.
4. Getrennte Arbeitskopie verwenden. Integritätsprüfung und mögliche Rettungsversuche gehören auf eine entbehrliche Kopie in einer isolierten Umgebung. Halte die gesicherte Ausgangsversion unverändert. Die Wiederherstellung eines geprüften Backups ist gegen eine teilweise Datenrettung abzuwägen.
5. Anwendungsergebnis abnehmen. Prüfe Workflows, Credential-Entschlüsselung und referenzielle Zusammenhänge. Reaktiviere externe Trigger erst, wenn deren Zustände und seit dem Sicherungszeitpunkt erfolgte Vorgänge abgeglichen sind.

Wann Hilfe besonders sinnvoll ist

Wenn kein geprüftes Backup existiert, der Schlüssel fehlt oder Geschäftsvorgänge seit dem letzten Stand bereits extern ausgeführt wurden, braucht es eine fallbezogene Wiederherstellungsentscheidung. Ein erfolgreich geöffnetes SQLite-File beweist noch keinen korrekten n8n-Anwendungszustand.

Häufige Fragen

Soll ich die Journaldatei löschen?

Nein, nicht als pauschalen Reparaturschritt. Sie kann für einen konsistenten Zustand erforderlich sein. Erhalte sie zusammen mit dem Originalbestand.

Garantiert .recover vollständige Daten?

Nein. SQLite beschreibt ausdrücklich mögliche Verluste, veränderte Werte und verletzte Beziehungen. Nutze solche Verfahren nur auf Kopien und prüfe das fachliche Ergebnis.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0175 mit KAN KAI WORKS besprechen.