What does "losing transactions" mean? Some transactions will have committed before your backup and some will have committed after and therefore won't be included. I don't see the problem you are trying to solve?
Whether a transaction had started and gets transparently rolled back, or you had prevented from starting, what is the difference to you? Either way, you have a point-in-time snapshot, that time is the latest commit before the LVM snapshot.
You're discussing this in terms of "safety" and that doesn't seem right to me.
This isn't really a personal or controversial take on the issue. There are easier ways to back up a sqlite database, but if you want to use LVM snapshots you need to understand how to do it correctly if you want to have useful backups.
Here's a scenario for a note-taking app backed by sqlite:
1. User A is editing a note and the app writes the changes to the database.
2. SQLite is in WAL mode, meaning changes go to a -wal file first.
3. You take the LVM snapshot while SQLite is:
4. The snapshot includes: Result: The backup is inconsistent. Restoring this snapshot later might: In order to get a consistent, point-in-time recovery where your database is left in state A and your backup from the LVM snapshot is in state B with _no_ intermediate states (like rolled back transactions or partial writes to the db file), you have to first either: Then take the LVM snapshot.