> Don't do that. Opening SQLite files using anything but the SQLite API leads to unexpected locks and errors. Plus you don't know how to ensure that a SQLite database file and a WAL file are 'compatible'. > > If you're trying to capture the changes to a file, you might find this useful: https://www.sqlite.org/sessionintro.html No, it is not the intention to capture the changes only. The goal is to make a complete database backup using tar & compression. We would like to avoid making a local copy first... We of course would backup always both files, the main db file and `-wal` file. So we always would have a matching pair. > Don't do that. Opening SQLite files using anything but the SQLite API leads to unexpected locks and errors. What kind of problematic locks is a simple copy or tar creating? Does that mean that the method described in https://www.sqlite.org/backup.html is no longer safe to use? > Historically, backups (copies) of SQLite databases have been created using the following method: > > 1. Establish a shared lock on the database file using the SQLite API (i.e. the shell tool). > 2. Copy the database file using an external tool (for example the unix 'cp' utility or the DOS 'copy' command). > 3. Relinquish the shared lock on the database file obtained in step 1.