Alternatively, given that it's ACID, you could just take a snapshot of the file system/volume in question, and do a recovery on restore.
Edit: SQLite also has WAL files, so presumably one could just use tar/rsync to create the backup, and only the last file would be 'corrupted', so you'd lose the last (few) transaction(s):
Ding! correct answer. In addition, the backups can run in the background, simultaneous to active use in other threads. When the backup is initiated, it is a transaction, so it maintains knowledge of what portion of the database is new since the backup began and does not include that data. Which is what you want for backup integrity.
https://www.sqlite.org/backup.html
There's a ".backup" command:
* https://sqlite.org/cli.html#special_commands_to_sqlite3_dot_...
Alternatively, given that it's ACID, you could just take a snapshot of the file system/volume in question, and do a recovery on restore.
Edit: SQLite also has WAL files, so presumably one could just use tar/rsync to create the backup, and only the last file would be 'corrupted', so you'd lose the last (few) transaction(s):
* https://www.sqlite.org/wal.html