Sorry to hear the errors are back - but it’s good that you have the logs!
So at 19:34:08Z we can see the first of 5 downloads of a dblock (archive volume) file. Each attempt results a different temp file name (as expected) as well as the same error of the same download file hash not matching the same database expected file hash.
2018-01-14 19:34:08Z - Warning: Operation Get with file duplicati-b610f7bfd35c24b98883dc14a751c223b.dblock.zip.aes attempt 1 of 5 failed with message: Hash mismatch on file "C:\Users\server\AppData\Local\Temp\dup-e32ca024-c0d7-4791-8f0d-d44044d1da01", recorded hash: RgzZaMU3n4QmMLZfFeEq/82tYaBCbuqwJghP/a9o5II=, actual hash KYfqN3xHnHDKb/pPGvBfD6ripcYAoXkDaln9AN1uMxA=
As I think I mentioned before, the file SIZE is correct in all 5 downloads, otherwise we would have seen a file size error instead of a hash error. So we’re still stuck with the question of is the database correct or the actual file.
I’d have poke around but I believe there is a parameter that tells Duplicati to not do the hash test (or to ignore the results) which would allow you to do a restore regardless of the error at which point you could manually verify the resulting files.
Unfortunately, I still have no idea what is causing this issue in the first place. I think @kenkendk is the expert on the database (and hashing) stuff so hopefully he’ll get a chance to see this and have some ideas.