> That is why I consider just backing up -wal as well (and restoring). It should still be consistent, correct? Yes. You will have to take and hold an "intent to write" (BEGIN IMMEDIATE) to prohibit any other connection from writing to the wal file. > Out of curiosity, what is the problem there? Can opening another file descriptor for the same file disturb SQLite in some ways? This is an Operating System issue. The Operating System tracks file locks by process (POSIX/Linux) rather than by handle (Windows). This means that on an Operating System which claims it is POSIX compliant, opening and then closing a file using the platform calls will cause all locks for that file held by the current process to be released without notification of this state of affairs. On Windows the "files" may remain "locked" even though the process is terminated or the file is closed, and the only way to fix that is to cold-start the Operating System (a reboot). This state of affairs comes to pass because of the way that locks are tracked on Windows. Some other Operating Systems do things differently by other methods and may have other varying behaviours and design features (and design flaws). This is documented (at least for the case of POSIX locking) and the SQLite3 library contains code that attempts to work-around the design flaw. It would be perscpicacious, knowing about the frailty and bad design decisions, to avoid the circumstance in which the issue might arise -- especially when it is so simple to do so. To ensure that the backup method will work properly and without causing the database to become corrupted, a process that is using the SQLite3 database exclusively via the SQLite3 API must be used to lock out other sqlite3 instances from the database while *a separate process* must be used to copy the files so as to not render the database locking fubar.