Sure. The rest involve command line tools such as Duplicati.CommandLine.RecoveryTool.exe or scripts, but since we’ve gotten this far with the GUI restore, might as well see if we can workaround current spot. This workaround may seem ridiculous, and in a way it is (but you’ve hit more trouble spots than usual…).
Previous idea was to try to read or copy the database out of the temporary file area, but the concern was whether that could cause an error and waste a bunch of time/work/wear. While I’d in a way be happier if Duplicati had fully given up, seeing it get quieter means maybe the database is inactive and can be taken.
Typically it lives in your user’s Windows temporary files (unless you set up otherwise), so looking at your C:\Users\<user>\AppData\Local\Temp might be useful. Copying out all the files starting with
dup- would collect any candidates, but before that it would be useful to install Sysinternals Process Explorer and use its
Find facility to see what files are open in your Temp by Duplicati. One might be your database. I’m not going to try to predict whether it’s open at this point. If no files are open, that’s even better for file safety…
Installing DB Browser for SQLite will maybe let you try out the copied candidates based, for example, on date being sometime between when restore began and now, and size not around 50 MB (default) dblock. Possibly this plan will get complicated by the default weak encryption on DB on Windows. Worth a try… Basically, try opening suspects (read-only is good), and see if it opens and has about 18 or more tables.
If you can find the database it was working on, my guess is it’s just in the wasted (due to bug) end dblock reading phase, and not really finding what it’s looking for. There might be an in-progress flag to edit away, then we can try manually putting the database into a somewhat meaningless new job just to do a restore.
If that’s too ridiculous, another approach is a do-over download and decrypt. You can probably download faster than Duplicati with a downloader that does concurrent downloads. I think Cyberduck can do them. Decrypt with AES Crypt via File Explorer multi-select, see if RecoveryTool will index it, and then try restore. RecoveryTool looks like it has a very different index method, so can’t hit the same recreate-database bug.
If RecoveryTool can’t handle it, then there are still two standalone scripts you can try on the decrypted files. The basic goal here is to get your files back while avoiding techniques that have so far not worked well…