Simple backup/restore logs error but succeeds


I have installed Duplicati on Ubuntu 18.04, and created a simple test backup job which backs up 68 audio files from my NAS (via an SMB mount) to a “file://” target in my home directory on my local disk. I gave it my user/pass for the target. AES encryption password “password”. Smart retention policy. All other settings default I think.

Backup failed to read one file and one timestamp (which I don’t understand as I can read them fine, but that’s not my question.)

I have tried restoring three times: 1 file, 2 files, 2 files, to a different location. The files were restored perfectly (tested with sha256sum vs the original).

However, it reports the following error, or a variant thereof (different dblock file):

2020-08-18 21:39:56 +01 - [Error-Duplicati.Library.Main.Operation.RestoreHandler-PatchingFailed]: Failed to patch with remote file: "duplicati-", message: Failed to decrypt data (invalid passphrase?): Invalid password or corrupted data

Clearly it did decrypt the data – the restored files are perfect.

What is this telling me please? Am I doing something wrong, or is it a bug?

Happy to share my backup configuration and/or get further logs. I’m new to Duplicati so assume very little knowledge :slight_smile:

Many thanks!

Welcome to the forum!

I don’t know how this would happen… the error you are getting should have resulted in a failed restore, I would think.

One comment I have is that your usage of Duplicati is a bit backwards. It usually works best when Duplicati is run on the device that holds the data you are trying to protect, and the resulting backup data should be stored remotely. Reason for this is because it doesn’t really allow credentials to be entered for the source data. That being said, I don’t know that it’s related to the issue you are currently seeing.

Thanks. Yes, I’m not planning on using it like that – it was just an easy thing to set up to play with it.

How closely did you check? Duplicati reassembles files block by block in an unpredictable order, so it’s possible to get files that are the right length but are missing some bits in the middle. More likely, though:

no-local-blocks should be set and checked in Options if the goal is to guarantee block get from backup.
Possibly setting that option will result in less success. Next usual step is to turn off browser password autofill, which tends to put the wrong password in, especially if another password (e.g. web UI) is used.

As per the original post, I did a sha256sum of them. They were perfect.

Thanks. I just tried again, to see if that helped, and the restore worked correctly this time, which is good I suppose, although it also leaves me not undertanding why it didn’t work before or what changed to make it work now…

Thanks for the reply!