Restore testing with weird results

Seems like incorrect status. I don’t know how the ending status passes to web UI, but message is:

Unable to restore file to program folder #2003 is an open issue with the bad status as one part of it.

Using the Command line tools from within the Graphical User Interface to run The AFFECTED command can tell you what those files mean in terms of damage to the backup. You’d set new Commandline arguments to duplicati-b1c7c8ecd19de49699a13ee8ddf45d4e5.dblock.zip.aes etc.

Inventory of files that are going to be corrupted shows the output from a lab demonstration that intentionally corrupts files. In your case, of course, files are not supposed to be corrupted, but it sometimes happens, especially before 2.0.5.1 and if you had used throttling to limit upload rate.

Are they all dblock files? Those are hard to replace. The dlist and dindex files can be recreated.
You can see what bad files look like, e.g. creation date. I’d feel worse if 2.0.5.1 made a bad one.
What storage type is backup on? Sometimes they fail. You could also download and try to open.

AES Crypt can decrypt, or if you prefer CLI without an install, use Duplicati SharpAESCrypt.exe.