Untraceable long operation (query?) during backup

Lacking solid info by web search, best thing is to try. If file will allow it, try to get a copy of it, then try DB Browser for SQLite and see how it does. Alternatively use a hex viewer and Database File Format to at least see if 1.3.1. Magic Header String says “SQLite format 3”, if so, it might just be a database using a special name. The source code seems to have an open routine that either takes a name or invents one if a name is not given. In addition, 2.6. TEMP Databases and 2.1. Record Format hint at normal format. While looking at how page-oriented SQLite is, are the reads at even boundaries of the 4096 page size?

I’m not an SQLite expert, however it looks like in theory it is possible. I’m not spotting signs in Duplicati.

Add verbose logging to System.Data.SQLite

Again, this is not an area I’m expert in, but I think System.Data.SQLite provides a .NET interface to C. Regardless, a .NET Framework debugger should be able to breakpoint the run, but logs may be hard.

Someone proficient in .NET Framework profiling, perhaps with Visual Studio, might also be able to get some sense of what areas are active to what extent. I don’t have Visual Studio and so can’t guide you.

Even though you see the slow spot move around, it might be useful to get a higher-level view of it, e.g. using –log-file-log-level=Retry for a top-level, Verbose for a bit more. Just seeing the tiny snippet says

may have run, and it seems odd to see it there, because I think that’s near the end of backup, whereas FileEnumerationProcess is at the start of processing which you can read about here. Where’s the rest?

You can also try turning off –usn-policy which is a completely different implementation. Is it compatible? Possibly a glimpse of all your settings (with confidential info removed) would help, e.g. start with Export.