Lock free dedup with encryption

[aweber]

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

[Christoph]

If I use -e encrypt with my repository

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

Init command details

If the storage has been already been initialized before, it will download the storage configuration (stored in the file named config ) and ignore the options provided in the command line. Otherwise, it will create the configuration file from the options and upload the file.

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.

[TheBestPessimist]

. Though I’m not sure what happens if you try to initialize an already initialized storage with different parameters (e.g. without encryption)

you will get an error.

[Christoph]

Though the manual says:

Init command details

ignore the options provided in the command line.

Which doesn’t sound like an error…

[TheBestPessimist]

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.

[Christoph]

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.

[aweber]

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.