Well, that certainly sounds like things are pointing to where they should be…
Normally a database repair tries to download the necessary dindex files (smaller than the dblock archive files) to fill in it’s missing gaps. A database recreate would need to download all the dindex files. If any dindex files are missing or broken then the larger dblock archive files are downloaded. If dindex files are broken so badly that Duplicati can’t figure out which dblock files to download, then dblocks five has to be downloaded until the missing index (and database) data can be recreated. In the case of recreate with no dindex file, then EVERY dblock file would need to be downloaded.
So the actual length of a repair, from a downloads point of view, can vary greatly depending on what actually went wrong. On top of the downloads, there is also a lot of database processing that has to happen - and some of that code is probably not as optimal as it could be.
At this point, you’ll have to try the Recreate (delete/repair) option again to get the local database working.
Note that you should still be able to do a “Direct restore from backup files …” even if there is no local database, so the already done backups are still usable.
In fact, that might be a good test to make sure everything is pointing to the right place. If you can do a test restore of a single file, then we know the job is pointing to the right place which means if the database repair still won’t work then there’s a failure point somewhere.
Note that for test restores you should either restore an older version of a file or make sure to enable the
--no-local-blocks parameter (which tells Duplicati to not use the local file to speed up the restore).
By the way, I edited your post by adding “~~~” before and after the error message to make it a bit easier to read.