There is no clear answer that I know of as to why it happens, but you’ve possibly seen that it seems to be related to rapidly changing files, and that this might be your backup job’s own SQLite database journal file (check Local database path) which is temporary and even less worth backing up than a moving database.
Try –snapshot-policy=on if it fits. It’s most likely to fit if on Windows and not running as a “Standard User”.
This will help in other situations where source files that are then in use would be inaccessible for backup.
If that still has problems, then you could go to screen 3 to add an exclude filter, which might look like this: /home/tom/.config/Duplicati/CZYBFCCRPU.sqlite* (you can see on its three-dot menu what it did) Filters gets into the syntax that the Edit as text uses, or you could view the –exclude in Commandline.
I am running Ubuntu 18.10 and do not have LVM disk volumes, so -snapshot won’t help.
I will exclude the database file as you suggest.
If I have a catastrophic failure that db can be recreated
I also typically let it run with my system mostly idle, but I do leave thunderbird open.
I also just noticed that I do backup my imap files. I will also close thunderbird next time too
Because Recreate can be painfully slow for large backups, some people backup databases, but in a different job, maybe right after the primary backup is finished, making a nice stable pair of destination files + database. My own practice is to just occasionally move the DB temporarily then run a Recreate. Mine’s pretty fast so far.