“Repository has not been initialized”?

I’m not sure that I correctly understand what you explained in the scenario “Multiple cloud storages without a local storage”:

I started from scratch with only existing directories on the remote sftp-storages.
The option ‘-copy’ on second line of the code example ensures that the two storages are in the same configuration state and nothing else, right? Giving this command I got the message “Repository has not been initialized” ???
But it seems to make no sense to backup to storage"wasabi-direct" (5. line) and then make a copy from backblaze to wasabi.

Further explanations would be great
Thank you

This is because the local directory to be backed up (called the repository) has not been initialized. There was likely an error when you ran the first command (duplicacy init my-backups --storage-name backblaze b2://bucket)

If you run the copy command without backing up to wasabi-direct first, most chunks will need to be downloaded from backblaze and then uploaded to wasabi. By backing up to wasabi-direct first, you’ll save a lot of backblaze egress fee.

1 Like

I have edited the #how-to in order to try and explain things a bit better. Does this explanation look simpler to you, @ralf?

1 Like

Yes, this is more clear. In the last line of the example code you wrote " … -to wasabi_storage". Am I right that this should be “… -to wasabi_real_storage” ?

Thank you

1 Like

Thank for your quick reply.
I will start a new try, because I didn’t notice any errors while using the code.

" (in this case don’t forget about using --bit-identical as explained here)."

That link has no explanation about “–bit-identical”. Does --bit-identical have to be specified when adding a second storage or only when running the copy command? Or at both stages?

I think @TheBestPessimist wanted to point to the add command showing the -copy and -bit-identical options, this link.

Only when adding / creating a new storage with the add command. The -bit-identical option will make it compatible with the initial storage created.


Just to clarify -bit-identical isn’t required to make it compatible with the original storage. That’s what -copy does. -bit-identical was added primarily so you can use third-party tools like rsync to seed or maintain the copy; to force the chunk filenames and the hashes they’re encrypted with to be the same as the ones stored in the encrypted config file.

Without it, a copy compatible storage (made with -copy) will be created and corresponding chunks of the same size will be encrypted with a different set of hashes and end up with different filenames. You can’t use rsync but Duplicacy copy will work just fine.


You explained that splendidly! :ok_hand::+1:

Re. copying from the onsite storage:

duplicacy init repository_id onsite_storage_url

Does this also work if the onsite_storage has been previously initialized with encryption?

Yes: when you try to init or add a storage which is already initialised, then duplicacy fill figure that out and use the existing storage settings.

Hmmm, I must be doing something wrong then…

From my laptop I did

duplicacy init -e -storage-name local-server Downloads sftp://user@localserver:port//mnt/data/backup/laptop

I then did

duplicacy backup -stats

which ran succesfully

I logged in to the local server and did

mkdir -p /mnt/data/backup/dummy/laptop
cd /mnt/data/backup/dummy/laptop
duplicacy init LaptopDummy /mnt/data/backup/laptop/

This resulted in the following error

Failed to download the configuration file from the storage: The storage is likely to have been initialized with a password before

duplicacy init LaptopDummy //mnt/data/backup/laptop/
results in the same error.

I can’t figure out what I’m doing wrong. Any help is greatly appreciated.

On the server run init with encryption:

duplicacy init -e LaptopDummy /mnt/data/backup/laptop/