Is the time stamp of duplicati-bd2d9bf5f4fa54ee4a3d280718c7c8aed.dblock.zip.aes recent, meaning it didn’t exist for the previous search for files with long runs of NUL characters? Can you hexdump, and if there isn’t such a run, what does the start of the file look like in hexdump? Expected first 5 bytes above.
What are the lengths of the 4 files? Sometimes a length that’s too binary-even might be from filesystem. Alternatively, previous throttling might have done some damage, although the NUL runs look different…
Regardless, damaged dblock files mean some data is gone, and I’m glad it looks like there were only 4 files. Inventory of files that are going to be corrupted shows how to use the affected command linked earlier to figure out what source files those damaged dblock files would impact. The easiest way to run the command is probably in web UI Commandline, changing Command dropdown at top to affected, and replacing the Commandline arguments box with the simple filename (no path prefix) of the dblock. You can try one first, or put all four in at once on different lines. Then go to the bottom to run command. You can look over the results to see whether or not the files that used the damaged dblock were critical.
There are a lot of ways that things could go depending on what shows up, ranging from trying recovery methods to starting over again, which is often the easiest thing, but has some definite drawbacks to it…
Ideally we’d also work out what went wrong sometime to cause 4 possibly damaged files on destination.