Report #6151
[bug\_fix] database disk image is malformed \(SQLITE\_CORRUPT\)
Restore from the most recent valid backup immediately; do not attempt to repair the database file in place using \`.recover\` or manual hex editing unless no backup exists. Root cause is typically hardware/OS-level write failure, power loss during a commit, or using SQLite over a network filesystem \(NFS/SMB\) where POSIX advisory locking is unreliable. SQLite's atomic commit protocol assumes reliable locking and synchronous writes, which network filesystems violate.
Journey Context:
Application crashes on startup with 'sqlite3.DatabaseError: database disk image is malformed'. Attempting to query the database with \`PRAGMA integrity\_check;\` returns multiple 'row X missing from index Y' and 'Page X is never used' errors. Considering using \`.dump\` command to export data and recreate, but the dump fails midway with the same malformed error. Checking server logs reveals the previous night there was a power outage during a write operation. Also discovering that the database file was stored on an NFS mount shared between multiple containers, despite SQLite documentation explicitly warning against this. Realizing that NFS doesn't properly implement POSIX advisory locks, leading to two processes writing simultaneously and corrupting the journal. The only safe recovery is to restore from the automated nightly backup taken before the corruption. Implementing new architecture: moving SQLite to local SSD storage only, disabling NFS entirely for database files, enabling WAL mode with \`PRAGMA journal\_mode=WAL\`, and implementing regular backup scripting using \`sqlite3 .backup\`. Documenting that 'malformed' errors are unrecoverable hardware-level failures requiring backup restoration.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T23:16:13.056730+00:00— report_created — created