You can use different passwords with -copy-compatible, but not with -bit-identical, as follows from the name of the parameters.
@saspus It seems that they can, even with -bit-identical
. I just found this in the docs here:
-bit-identical
The -bit-identical option is used along with the -copy option and will copy the IDKey, ChunkKey and FileKey to the new storage from the old one. In this case the names of the chunks generated by Duplicacy during backup will be identical in the source and new storage.This has the effect that you can rsync or rclone the chunks folder for example from local (source) to Google Drive (new storage), and then only do backups on Google Drive, and the existing chunks will be identical (same name, same size) as if the backup was run locally.
The -bit-identical option does not copy the encryption option. It is possible to have an encrypted source and an unencrypted new storage, or vice versa. The -e option determines whether or not the new storage will be encrypted.
This means of course, that the added storage can have a different password from the source.
Kind of. For the storage to be bit-identical the chunks need to be encrypted with the same keys, otherwise deduplication won’t work; and that would defeat the purpose.
When you create bit-identitcal storage, the encryption keys are copied from the source storage, instead of being generated anew. Then the contents of the config file is encrypted with the provided passphrase (via -e).
I was not aware that you could apparently provide different passphrase for the other storage, thank you for link. I’m not sure what’s the value in it – since the chunks are encrypted with the same key anyway.
What happens if I forget the password of the storage?
Do I loose any the posibility of recover the backup?
Without the storage password the data is unrecoverable. That’s the whole point of setting the password.
But you shall not try to remember it, use password manager.
Is there an environment variable for specifying the password for a SAMBA backend?
From the user guide: Managing Passwords · gilbertchen/duplicacy Wiki · GitHub
password type environment variable (default storage) environment variable (non-default storage in uppercase) key in preferences Samba password DUPLICACY_SAMBA_PASSPHRASE DUPLICACY_<STORAGENAME>_SMB_PASSWORD smb_password
@gchen – there seems to be inconsistency with naming here – SMB vs SAMBA
Oh nice! Didn’t occur to me to check the wiki @ github. Thanks!
I’ve fixed it. Thanks!
What about Storj keys?
What about it?
Thank you for the reply. I appreciate your time.
To clarify my original question: I was referring specifically to the use of Storj as a storage backend with Duplicacy. I’m currently setting up Storj as one of my storage targets, and I would like to follow best practices for securely managing access credentials — ideally using environment variables.
I reviewed the table provided in the documentation, which lists the environment variable names for various password and token types (e.g., SFTP, Dropbox, B2, S3, etc.), but I did not see Storj mentioned there.
Could you please let me know:
- What are the correct environment variable names used by Duplicacy to pass Storj-related access information (such as the access grant or API key)?
- Are there specific keys in the preferences file that correspond to Storj credentials?
- Does Duplicacy currently support retrieving Storj credentials from secret vaults (e.g., Keychain on macOS, gnome-keyring on Linux, or the Windows DPAPI)?
Thank you again for your help. I just want to make sure I’m configuring everything in a secure and recommended way.
It’s definitely there: search “Storj” on this page Managing Passwords · gilbertchen/duplicacy Wiki · GitHub
Ideally you would want to keep them in the keychain. Environment variables can be seen by a superuser.
I’m 99% sure that the confusion here is that @Moshnic is talking about THIS VERY forum thread, which is stickied in the “getting started” banner that automatically pops up on the forum. And the info at the top of this thread is way out of date. @saspus is rightly linking to updated info on GitHub.
I honestly think that the pop-up with the stickies is very confusing for new Duplicacy users. They are actively being directed to old info.
Good point. I edited the top post to include the link to the wiki
Thank you for your quick, polite and informative reply.