Lock free dedup with encryption

I read a bunch of the posts and github info, but still not entirely sure of the “simple answer”, so I thought I’d ask it here for everyone’s benefit…

If I use -e encrypt with my repository and supply a password. Do I need to use the same password on all repositories I am backing up to that storage in order to effectively de-duplicate across repositories and hosts?

I assume this is the case (and limitation) or one repository could not restore a chunk previously uploaded by a different repository’s backup.

Thanks,
AJ

What’s being encrypted (or initialized, since we’re talking about the init (or add) command here) is the storage, not the repository:

So whenever you “initialize” a storage that has already been initialized, duplicacy will just silently use the existing storage configuration.

So the short answer to your question is yes. Though I’m not sure what happens if you try to initialize an already initialized storage with different parameters (e.g. without encryption), but you can simply try it out. My guess is that it will notify you that it will ignore your parameters and use the existing ones.

you will get an error.

Though the manual says:

Which doesn’t sound like an error…

1 Like

Well, at least I remember that having the storage encrypted and not using -e flag throws error, not sure about all the other options.

Someone could test this, and then we’ll update the wiki with those details.

My suggestion would be: if there are any options that produce an error (which means the command execution fails, right?), they should be downgraded to warnings.

My point is consistency. So, alternatively, any divergent option could throw an error, but I think that would be a nuisance.

Obvious newbie to duplicacy, but been using a lot of utils on a lot of OS’s over the years…

I would think that if a user’s command ignores any of the provided parameters/options, the user should be at least warned that it was ignored for a reason.

Otherwise the user could continue on and not realize he/she is going to get different backup results until some unknown point in the future. Since backups can be long-running by nature, and we especially have a possibility that an encryption parameter could be ignored, I think at least a warning is prudent.

1 Like