n8n reports SQLITE_CORRUPT: preserve and assess the database

n8n will not start, or database operations fail with SQLITE_CORRUPT. Ad hoc cleanup is particularly unhelpful now: another modification can destroy evidence and make recovery harder. Preserve a consistent set of files first, then establish the last known good backup available.

A historical report with a relevant recovery boundary

A 2022 report describes SQLite corruption after manual changes and removal of a journal file. It is not evidence of a general defect in current n8n versions. Q1 SQLite explicitly warns about interfering with active journals and mismatched copies of live databases. Salvage can also yield incomplete or inconsistent results. Q2 Q3

The n8n encryption key belongs in the recovery plan because it protects stored credentials. Possessing the database file alone does not replace that key. Q4

Useful first steps

1. Stop further writes in a controlled way. Establish with the operator which n8n processes access the database. Retain logs and stop automatic restart loops before experimenting with repairs.
2. Preserve the original set. Keep the database together with any WAL, SHM or journal files, configuration and key material. The correct consistent backup method depends on whether the database is active. Do not casually copy a live file between running processes.
3. Investigate the environment. Examine free space, filesystem errors, storage health and the timeline of recent changes. A continuing storage fault would also threaten a restored database.
4. Use an isolated working copy. Integrity checks and salvage attempts belong on a disposable copy in a separate environment. Leave the preserved original unchanged. Compare restoration from a verified backup with the risks of partial data salvage.
5. Validate application behaviour. Check workflows, credential decryption and relationships between records. Re-enable external triggers only after reconciling their state and business operations performed since the backup was taken.

When recovery needs individual assessment

If no tested backup exists, the encryption key is missing, or external business actions occurred after the latest backup, recovery needs a case-specific decision. Opening a SQLite file successfully does not establish that the n8n application state is correct.

For a useful handover, record n8n version, storage type, first error time, recent manual changes and available backup dates. Share a file inventory and redacted logs first; database copies and secrets require an appropriate private transfer channel.

Frequently asked questions

Should I delete the journal file?

No, not as a generic repair. It may be required to establish consistency. Preserve it with the original database files.

Does .recover guarantee complete data?

No. SQLite documents possible missing records, altered values and broken constraints. Use salvage only on copies and verify the recovered business state.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0175 with KAN KAI WORKS.