In the case of a job-with-database restore this isn’t an issue as Duplicati can look at the database to know what blocks are stored where.
When restoring directly from the backup destination Duplicati has no reference for what’s where so uses the dlist files to populate the list of what files are backed up in what versions.
Once files to be restored have been selected, I believe the dindex files are then downloaded to build the temporary database that is used to figure out which dblock files need to be downloaded and processed to do the actual restore.
It’s possible an apparently unrelated dblock file (say one older than the file you’re trying to restore) actually contains a matching block for the “newer” file. Because of deduplication, Duplicati would have just referenced that block (in the “old” dblock) rather than uploading it again. Similarly, compacting could cause archives to be merged in a way that could make wildly differing versions share dblocks files.
However, I think it’s more likely that the “Direct from backup files” restore process is using a generic piece of code that assumes we always want to verify things, when in this case we may not really want to.
Can you try your Direct restore again but this time on step 2 (Encryption) include the following in the “Advanced Options” field (the 2nd line just says to ONLY use the destination data rather than trying to use local file parts if available and unchanged since the version being restored)?
--no-backend-verification=true
--no-local-blocks=true
Another possibility I’ve tested on direct restore with a missing dblock file is that main menu “About” → “Show log” → “Live” option gives me the following error:
Feb 6, 2018 11:51 AM: Missing file: duplicati-b3e516a51e3104b92b5353962ff339c3d.dblock.zip
If I steal an idea from @Mat and create an empty file with that name at the destination, then my “Direct restore…” backup runs without the missing file error. Of course if the file I’m trying to restore happened to be in that file it would be only partially restored, but at least it’s a start.
Granted neither of these are a fix or solution as they can expose other failure points (see error blow), but at least they allow people to move beyond an error at which they might previously have been getting stuck.
Errors: [ Failed to patch with remote file: “duplicati-b3e516a51e3104b92b5353962ff339c3d.dblock.zip”, message: The file duplicati-b3e516a51e3104b92b5353962ff339c3d.dblock.zip was downloaded and had size 0 but the size was expected to be 16735997 => The file duplicati-b3e516a51e3104b92b5353962ff339c3d.dblock.zip was downloaded and had size 0 but the size was expected to be 16735997 ]