Duplicacy add copy + bit-identical vs just copy the config file?

#1

Hi,

I am in the middle of an effort to move my duplicacy storage from google drive to backblaze b2. I read the duplicacy add command instructions carefully and did a duplicacy add -e -copy default --bit-identical ... to add the b2 storage. As per the documentation, this option tells duplicacy to copy the IDKey , ChunkKey and FileKey to the new storage from the old one to the effect that the names of the chunks generated during backup will be identical in the new storage.

When I ran the add command, with an empty b2 bucket, it just created an emtpy fossils, chunks, snapshots folder along with a new config file which was 330 bytes. The old config file (in gdrive) was 402 bytes.

I then rclone’ed the duplicacy storage files (snapshots, fossils, chunks, etc.) from google drive to b2 using rclone. I backed up the new config file because rclone sync would copy the old config file over to the B2. I believe it is the config file which contains the IDKey, ChunkKey, and FileKey, and also the encryption password/salt in some shape/form for an encrypted storage.

To my surprise, the new storage works perfectly with the old config copied to it - I am able to do duplicacy list -a, duplicacy list -a -files as well as duplicacy check -a -stats and everything is giving me the same result for both the storages.

Should I copy back the correct newly generated config file to the b2 storage or is the old config file ok to use? If so, why is there a size difference between the two with the same settings and password? If not, then how does it work perfectly with the old config file? What was the purpose of the bit-identical and copy in add storage if all i had to do was copy the config file over?

The notes section does mention not copying the config file from an unencrypted storage to an encrypted one, but in my case both storages are encrypted (using the same password as well), have the same chunk size and all other settings.

#2

I suppose one way to find out what the difference might be is to copy both storages to a temporary unencrypted local storage and then examine the config file.

You don’t have to (and I recommend you shouldn’t) use --bit-identical unless you’re using rsync or otherwise manually copying the chunks folder across storages on a continual basis.

But if you are using that flag, you can simply reuse the config file, too. (Obviously, it will have the same password but you can always re-encrypt it later.)

Though if you’re not using that flag, then definitely don’t copy the config file.

#3

If you simple copy the original config file over to the new storage, yes, it is going to work but the new storage will have the same storage password as the old storage.

The --bit-identical option will give you a chance to use a different storage password for the new storage.

Remember, the storage password is only used to encrypt/decrypt the config file. Copy-compatible storages shared the identical unencrypted config file.

1 Like
How to backup from a backup
Retrieving storage encryption password?
#4

Thanks @gchen and @Droolio for the prompt replies! Really appreciate the work you have done in creating both duplicacy and this vibrant community. It only works because you are participating in this forum so actively.

@Droolio I see no other effect of using that flag other than creating a config file in the new storage. There is no special configuration in the .duplicacy/preferences file created by using that flag. So if one is copying the config file I’m assuming (going by @gchen’s reply also), that copying the config file should be exactly the same as using add -copy -bit-identical with the only diffference being that you don’t get to choose a new encryption password for the new storage.

How would that copy the config files? Creating new storages always creates new config files right?
The only doubt remaining is why the config files are of different size. Is there anyway I can decrypt them?

#5

When I say copy the storages to an unencrypted local one, I just mean to set up a temporary unencrypted storage with e.g.:

duplicacy add -copy default -bit-identical tempstore dummyrepo "D:\tempstore"

That will copy the config across but decrypt it. Do it on both your storages and you can then explain - for curiosity’s sake - the file size difference. I suspect you’ll end up with identical config files, or maybe the fixed-nesting parameter is different or lacking, or the encryption algo used as the time to encrypt the config was different?

But as gchen says, copy-compatible storages (made with the -bit-identical flag), should have identical keys.

1 Like
#6

Thanks a lot @Droolio. This was very helpful. I found out that I had added the new storage without any encryption password (without the -e option in the add command) and therefore the config file generated was without a password. The copied config is with a password so is bigger.