How to back up a SQLite Docker container (2026)
Want a SQLite backup that actually restores? Dump it with `sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"` from inside the container instead of copying /data/app.db. the SQLite online backup API (sqlite3 ".backup" or VACUUM INTO) reads a consistent copy that respects WAL and in-flight transactions, which a raw file copy cannot. Dockstash then restics the dump for encrypted, deduplicated, off-site snapshots.
What Dockstash detects
| Env keys detected | DATABASE_PATH, DATABASE_URL, DB_PATH |
|---|---|
| Default port | — |
| Live data paths (never copied live) | /data/app.db, /data/app.db-wal, /data/app.db-shm |
| Example images | embedded (no dedicated image), alpine + sqlite, app images bundling sqlite |
The dump command
sqlite3 /data/app.db ".backup '/tmp/app-backup.db'"The restore command
copy the .backup file into place while the app is stopped, or use .restorethe SQLite online backup API (sqlite3 ".backup" or VACUUM INTO) reads a consistent copy that respects WAL and in-flight transactions, which a raw file copy cannot.
Gotchas to avoid
- Never copy a live .db file while the app is running under WAL mode — you will miss the -wal/-shm sidecar files and capture a torn, unrestorable database.
- Use sqlite3 ".backup" or "VACUUM INTO", both of which use the online backup API and handle WAL correctly.
- A checkpoint (PRAGMA wal_checkpoint(TRUNCATE)) before a raw copy is not a substitute for the backup API under concurrent writes.
Do it in one click with Dockstash
Dockstash runs the exact dump above, restics it off-site, and drill-tests the restore automatically — no script to maintain.
Last updated: July 2026
Frequently asked questions
Can I just copy the .db file?
Not safely while the app is writing. In WAL mode the newest data lives in the -wal sidecar; a plain cp of only the .db captures a stale, torn state. Use sqlite3 ".backup" or "VACUUM INTO" which read a consistent copy through the online backup API.
What is VACUUM INTO?
VACUUM INTO 'file.db' writes a fresh, defragmented, transactionally consistent copy of the database to a new file. It is a clean way to snapshot a live SQLite database without stopping the app.
Do I need to back up the -wal and -shm files?
If you use the backup API you do not — it consolidates the WAL into the copy. If you insist on a raw file copy (not recommended live), you must include -wal and -shm, but that is still race-prone.
How do I restore a SQLite backup?
Stop the app, replace the database file with the .backup output, and start the app. Because the backup is a single consistent file, there are no sidecars to reconcile.