Database corruption prevents all queries and operations. Use PRAGMA integrity_check to diagnose the issue, then recover data using the .recover command or dump-and-rebuild method to restore functionality.
This error (SQLite error code 11) indicates that the physical structure of the SQLite database file has been corrupted. SQLite detected inconsistencies in the database file format, internal page structures, or table/index organization during file verification. This can occur due to hardware failures, improper shutdowns, concurrent write conflicts, or application bugs writing to closed file descriptors.
First, verify the corruption is real by running the integrity check command:
sqlite3 mydb.sqlite3 "PRAGMA integrity_check;"A healthy database returns "ok". A corrupt database lists specific errors like:
- corruption detected in the index "sqlite_autoindex_table_name"
- missing pages referenced by index
- malformed database record
If the database opens and returns "ok", the problem may be transient or application-specific.
Never attempt recovery without a backup. The original file may help diagnose the issue:
cp mydb.sqlite3 mydb.sqlite3.backupKeep this backup safe in case recovery goes wrong or you need to investigate further.
SQLite 3.38.0+ includes a dedicated .recover tool for damaged databases:
sqlite3 mydb.sqlite3 ".recover --ignore-freelist" | sqlite3 mydb_recovered.sqlite3Or for older SQLite versions, use .dump:
echo ".dump" | sqlite3 mydb.sqlite3 > dump.sqlThis exports all recoverable data to SQL statements. The .recover method is preferred as it skips unusable free space and doesn't try to restore invalid transaction states.
After the command completes, check the new database:
sqlite3 mydb_recovered.sqlite3 "PRAGMA integrity_check;"If "ok" is returned, your data is recovered. Replace the original:
mv mydb.sqlite3 mydb.sqlite3.corrupted
mv mydb_recovered.sqlite3 mydb.sqlite3If the .recover method produces an incomplete or unusable database:
# Export what can be salvaged
sqlite3 mydb.sqlite3 ".mode insert" ".dump" > dump.sql
# Manually edit dump.sql to remove transaction statements if needed:
# - Remove lines starting with "BEGIN TRANSACTION;" and "COMMIT;"
# - Some dumps include invalid data; comment out problematic INSERT statements
# Create fresh database from cleaned dump
sqlite3 mydb_rebuilt.sqlite3 < dump.sql
# Verify integrity
sqlite3 mydb_rebuilt.sqlite3 "PRAGMA integrity_check;"This method may lose some data but recovers what is structurally valid. Review the SQL dump before importing to catch issues.
Corruption does not happen randomly. Determine the cause to prevent recurrence:
Hardware Issues:
# Check disk health (Linux)
sudo smartctl -a /dev/sda | grep -i "health|fail|error"
# On macOS
diskutil verifyVolume /Volumes/YourDriveIf the disk is failing, replace it and restore from backup.
Concurrent Access Issues:
# Find processes accessing the database
lsof | grep mydb.sqlite3
# Verify only one application has the file open at a timeApplication Bugs:
- Review recent code changes that modify the database
- Check application logs for crashes during write operations
- Ensure proper error handling and transaction rollback
Backup/Restore Issues:
- Never backup a database file while it's open in the application
- Stop the application, backup, then restart
- Include the journal file in backups (if using WAL mode)
If you have a recent uncorrupted backup:
cp /path/to/backup/mydb.sqlite3 mydb.sqlite3
sqlite3 mydb.sqlite3 "PRAGMA integrity_check;"This is the most reliable recovery method. Regular backups are essential for SQLite.
Note that even after successful recovery, constraints (FOREIGN KEY, UNIQUE, CHECK) may be violated in the recovered database. Verify data integrity in your application and run PRAGMA foreign_key_check to find violations. If using write-ahead logging (WAL mode), corruption is less likely; standard rollback journal mode is more vulnerable to corruption during crashes. Some corruption cannot be recoveredโthe .recover command attempts to salvage what is structurally intact but may lose recent transactions or partial records. For mission-critical databases, implement regular automated backups and consider using a server-based database (PostgreSQL, MySQL) with built-in replication and recovery features.
SQLITE_IOERR_FSYNC: Error during fsync()
Error during fsync() system call
SQLITE_BUSY: The database file is locked
How to fix 'SQLITE_BUSY: The database file is locked' in SQLite
SQLITE_CORRUPT_VTAB: Content in virtual table is corrupt
Content in virtual table is corrupt
better-sqlite3: This statement has already been finalized
How to fix "better-sqlite3: This statement has already been finalized" in SQLite
SQLITE_AUTH: Authorization denied
SQLITE_AUTH: Authorization denied