Report #77305
[bug\_fix] database disk image is malformed \(SQLITE\_CORRUPT\)
Use the sqlite3 .recover command \(or sqlite3\_recover API in newer versions\) to salvage data from the corrupted database into a new clean file, and implement WAL mode with PRAGMA synchronous=NORMAL or FULL to prevent future corruption by ensuring fsyncs occur before returning success to the application. The root cause is typically interrupted writes due to power loss or process crashes while in rollback journal mode \(DELETE\), or failure to sync WAL files to disk, leaving the database in a partially written state with invalid page checksums or corrupt freelists.
Journey Context:
An embedded Linux IoT device deployed in remote locations reports sporadic "database disk image is malformed" errors after unexpected power outages. The device uses SQLite with the default DELETE journal mode for backwards compatibility. When a power loss occurs mid-transaction, the rollback journal might not be fully written to disk or deleted properly, leaving the main database file with partially written pages that fail checksum validation on next open. Initially, the developers attempt to fix the corruption by exporting to SQL and reimporting, but the SQLite shell rejects commands on the corrupt file. Consulting the SQLite documentation on corruption recovery, they discover the .recover command introduced in version 3.29. They run "sqlite3 corrupt.db .recover \| sqlite3 new.db" which reads all valid pages, rebuilds the schema, and salvages as much data as possible into a new file. To prevent recurrence, they modify the application to execute "PRAGMA journal\_mode=WAL;" and "PRAGMA synchronous=NORMAL;" on database open. WAL mode ensures that writes are append-only to the WAL file, and checkpoints are atomic, making corruption far less likely even on power loss, as the main database file is only modified during checkpoint operations which are transactional.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T12:21:19.000630+00:00— report_created — created