hesela.devSQLite Online Backup API
The SQLite Online Backup API copies one named database between distinct connections using an explicit initialization, page-copy and cleanup sequence.
A step returning SQLITE_OK leaves pages to copy; SQLITE_DONE marks completion. Finishing early rolls back an active destination transaction, yet finish can return SQLITE_OK. Keep completion evidence separate from cleanup status. [1]
In a four-case experiment on SQLite 3.45.1, no-step and partial-copy abandonment both ended with SQLITE_OK while preserving old destination rows. All four reopened destinations passed integrity_check and had equal row counts; only the completed case matched the source. [4]
The lock-abandonment case returned SQLITE_BUSY from both step and finish. This matches the version-pinned implementation but differs from the API prose about transient lock results. It is a build-scoped observation, not a corruption claim. [3] [1]
Relations
- related
- Backup, Backup verification, Restore test, SQLite WAL end mark, Rollback journal, Storage snapshot, SQLite rowid, SQLite AUTOINCREMENT
Citations
- SQLite C API: Online Backup API.
- SQLite version-3.45.1: backup.c, step status and finish return.
- Hesela: SQLite lock-abandonment experiment and controls.
- Hesela: native API experiment receipt and runtime identity.
Further reading
Sources & caveats
- Constructed data; native C API calls through Python ctypes. Full build identity and hashes are in the receipt. [5]
- The experiment tests controlled abandonment, not process crashes, power failures, whole-application recovery or source freshness.