Thanks for including this because I became a victim of the results - have applied it to all systems but I still have one that’s so far taken over a week to rebuild the files.
This “bug/feature” should be priority one.
I cheked with other machines and other backups, it takes ALWAYS this long. It’s not a bug just 10 people encounter, the people not encountering it either have no database losses or didn’t find their way over here…
I have two backups (one local, one remote) of the same data on my Linux server. Today I needed to recover a directory but both failed with a bunch of:
"2019-04-22 12:52:52 -07 - [Error-Duplicati.Library.Main.Operation.RestoreHandler-PatchingFailed]: Failed to patch with remote file: \"duplicati-b16b38ca56bea4548a3a7431e2140d3e9.dblock.zip.aes\", message: Failed to decrypt data (invalid passphrase?): Invalid password or corrupted data"
Zero files were restored.
These backups have been running without errors for a long time. I tried verifying both, and there was not issues reported.
I’m doing it from the web GUI; reading some of the GitHub and comments here, looks like I’m not the only that is having that kind of issue. Some people are reporting that it is working when using the command line. I’ll have to try.
As far as the password, that’s highly likely. It’s about 32 characters long and has just about every character imaginable in it. But as previously mentioned I had no problems manually decrypting the archive.
You are correct, running on a CentOS 7.6.1810 server.