On 2018/07/27 12:51 PM, Richard Hipp wrote:
Seem right. If a change happens to the database in the middle of a
backup, the backup automatically restarts, so that at the end of a
backup you are guaranteed to have a consistent copy from a single
point in time (something that you are not guaranteed to have if you
copy the file externally).
Unless of course you close all connections to the DB first, right?
I think the consideration comes to this:
Using BackUp API:
Advantages
-- No need to close all connections, can back-up a live DB.
-- Will re-start a backup if DB writes take place during.
-- Produces a consistent state file.
-- Can be done using only internal sqlite API (no manual file-handling).
Caveats
-- If updates happen very often on a large-ish DB, the backup may
constantly re-start and never complete.
Using file-system Copy:
Advantages
-- Quick to backup (OS/FS caching assist)
-- Consistent state single file (provided all DB connections are closed)
-- No restarting, but DB must remain closed (for writing at least) for
the duration of the Copy.
Caveats
-- Need to do your own file-system handling / error checking.
-- DB has to be closed to force the consistent state single file before
copying (commit journal files to main DB file).
-- No restarting, so no DB write transactions during copy process.
Conclusion: Unless you have the rare case of a constantly + frequently
updated large DB, use the API backup.
(If I've missed a point, or got it wrong, someone please amend it)
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
