On 9 Dec 2014, at 22:06, Simon Slavin wrote: > > On 9 Dec 2014, at 8:57pm, Nick <maill...@css-uk.net> wrote: > >> Environment is Linux with multiple (c. 4-6) processes accessing a single >> sqlite database named "test.db". >> >> Backup: >> - New process started using cronjob to initiate application checkpoint until >> completion. >> - rsync diff the file "test.db" to another drive/location (specifically >> ignoring the "-shm" and "-wal" file). >> - exit process >> >> Restore: >> - rsync the file "test.db" from another drive/location. > > Will not be trustworthy if the database is being written to during the rsync > operations. Recommend either of the following: > > A) Ensure all processes besides the backup process have the database closed > while it is being copied. Establish some kind of semaphore so they can tell > when it's safe to open the database again. > > B) Use the SQLite Backup API which was invented to do what you want. > > Simon.
That's interesting Simon I didn't expect the database not to be trustworthy. In WAL mode I thought the database file is only written to when checkpointing. Have I misunderstood this journaling mode? Again I may have misunderstood the docs around the Backup API, does it not start again from the beginning copying pages if another process writes to the database during the process? In practice could it successfully backup a 2GB database that is being written to once a second? Regards Nick _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
