discredits the idea that a retry happened, which causes Duplicati to try to upload again with new name.
Further experiments are unclear. Maybe it’s time to ask for a link to a database bug report to get a look.
Going along with that would be some sample names of the 181 files to study the history and relevance.
If wish to do more yourself, one safe method is to use Commandline to run The AFFECTED command.
Returns a report explaining what backup sets and files are affected by a remote file. You can use this option to see what source files are affected if one or more remote files are damaged or deleted.
This can be given names of dblock files, using lines in its Commandline arguments box. You can check activity by giving some files from intended folder (source files should be affected), then test mystery files.
If you’re willing to look in a copy of the database using a browser, that can get better info, with more work.
Another way to test if 181 files are relevant is to manually rename the database (because we might need database bug report later, depending on this test), move 181 files elsewhere, and see if database Repair button can recreate the database without warning and without going past 70% on its status bar progress.
The above test is good anyway. If disaster recovery is ever needed, database recreation needs to work…
Restoring files if your Duplicati installation is lost makes a partial temporary database, if that’s preferable.
Or one can add the job back and use the Repair button to rebuild a complete database, as this test does.
One drawback of just verifying files are not useful is that it leaves all the other open questions about them.
Great. I wasn’t certain how well that cleans up, but if you’re back to 6994 files, then interrupt did as desired.