Unless you have taken "special steps" to "snapshot" the filesystem or even specific files, the backup software states in its documentation that it does not do anything to "snapshot" a file or the filesystem and therefore not only may files be internally inconsistent, but that the filesystem is not consistent. This is in contrast to backup software which operates on a "snapshot" of the filesystem that is maintained consistent from the start of the backup of that filesystem to the end of the backup of that filesystem (this is called "Crash Consistent" in that the filesystem backup is fully consistent as if the machine were powered off suddenly (by flipping off the power switch) and then backing up the filesystem. Crash Consistent backups depend on the ability of the filesystem to "fix itself", and any running software to "fix its files" in the event of power failure. In practice this is usually done by at some point in time suspending all physical writes to a filesystem so that it may be "backed up" in a stable state. (Microsoft calls this VSS -- Virtual Snap Shot) Some scheme's will have a method of telling running software to checkpoint itself to a stable state before suspending writes to the physical media in order to ensure that the backup is the equivalent of "Checkpoint Consistent" or "Shutdown Consistent". If you have not taken any steps to ensure that the backup is "Crash Consistent", "Checkpoint Consistent", or "Shutdown Consistent" then you will need to periodically backup the database to a "dump file" and backup the dump file (since that will be internally consistent as of the time the dump ended). The SQLite3 library does not contain any code to interface with external consistency managers on any platform, so the best backup that one can hope for is a Crash Consistent backup, however, that is not something that is under the control of either SQLite3 or (apparently) the backup software (Borg).