If you mean before and after the Recreate, that’s not nearly as helpful as before and after DB error, but unpredictable errors are unpredictable… What I do is keep a series of databases via run-script-before:
rem Get --dbpath oathname value without the .sqlite suffix
set DB=%DUPLICATI__dbpath:~0,-7%
rem and use this to maintain history of numbered older DBs
IF EXIST %DB%.4.sqlite MOVE /Y %DB%.4.sqlite %DB%.5.sqlite
IF EXIST %DB%.3.sqlite MOVE /Y %DB%.3.sqlite %DB%.4.sqlite
IF EXIST %DB%.2.sqlite MOVE /Y %DB%.2.sqlite %DB%.3.sqlite
IF EXIST %DB%.1.sqlite MOVE /Y %DB%.1.sqlite %DB%.2.sqlite
IF EXIST %DB%.sqlite COPY /Y %DB%.sqlite %DB%.1.sqlite
EXIT 0
Creating a bug report only works on the current DB, but old ones can be slid in carefully (no backups!).
This goes well with a chunk of a profiling log that was left running (can grow huge) as described above.
There are less huge log levels that may also help, but the DB bug report is not a log, just a single point.
I’m not reading this very well. If this is just adding and deleting source files (totally normal), and if the error happens during backup regardless of when the changes got done, with no hard stops/reboots, that’s odd. There is a chance that an automatic compact ran and messed up unless you have no-auto-compact set, however fatal errors frequently don’t create the usual backup results log for you, so you need a debug log.
Backup job failed after days but won’t restart was a debug effort that didn’t get a chance to be run, but the only clue was a DB bug report after the fail. Timing was concerning. Did yours fail at backup start or end?