A SQLite database may depend on a matching write-ahead log or rollback journal, especially after a crash. Preserve that file set before experimenting. After recovery, run structural checks on a working copy and verify known records in the owning application. A database that opens without error can still be incomplete or from the wrong transaction state.
Preserve a coherent database state
Identify the application and exact database path. Stop its writes through its supported shutdown or backup process. A copy of the main file made while transactions are changing it may be inconsistent. Do not assume that copy is safe to use. For live data, SQLite documents its backup API and other consistent-copy mechanisms.
Keep the main database and matching -wal, -shm and rollback-journal files when present. WAL may contain committed changes not yet transferred to the main file; SHM is associated coordination state, not an independent substitute for the WAL. Do not mix companions from different backups or delete a “temporary” WAL to make a file open. See SQLite’s WAL explanation and corruption-prevention guidance.
Find a usable source
Use the application’s own backup or export first. If files were deleted from readable storage, XRecovery can search the original disk and save candidates to another physical device. Preserve their original names and relationships where available, but do not pair different candidates based only on matching timestamps.
Use SQLite’s own checks and recovery procedures on preserved copies to assess records, relationships and transaction state. Application-specific encryption or extensions may also require the original software and credentials.
Inspect a copy with SQLite
Use a current official SQLite command-line build compatible with the database. On a working copy, start the shell in read-only mode, for example:
sqlite3 -readonly "working.db"
PRAGMA integrity_check;
PRAGMA foreign_key_check;
Keep the matching WAL companions beside that working copy if needed. Read-only access can fail when required WAL state or directory conditions are missing; do not remove the log as a shortcut. The SQLite shell manual documents read-only opening. The PRAGMA reference distinguishes integrity checking from foreign-key checking.
An ok integrity result addresses structural checks, not whether the latest business records exist. Compare expected tables, row counts, known identifiers, totals and recent committed transactions with independent records. Run the owning application’s supported read/open workflow too.
Treat corruption recovery as salvage
If structural errors remain and no complete backup exists, SQLite’s .recover facility can extract usable data into SQL for a new database. Use it on a disposable copy and create a separate output database. Review the output before importing it into any production system.
SQLite explicitly warns that corrupt-database recovery can omit or alter values, resurrect deleted content and violate constraints. Re-run structural and application checks after salvage. Preserve the original file set and document missing or suspect records; a newly created database is not evidence of complete restoration.
For the next step, see Document Recovery: Deleted, Unsaved, Overwritten or Damaged?.