Note the second of the two Duplicacy storages (local or cloud) would need to have been initialised with the add command to make them copy-compatible. If you haven’t done this, you’d need to reupload to (or download from) the cloud. If you did do this, copy recognises and avoids uploading existing chunks.
Overall, I’d say it’s better to go:
Repository > Local > Cloud
…than:
Repository > Local
Repository > Cloud
That’s what I was afraid of.
Maybe in the future I’ll spend the week re-uploading everything the “better” way, but for now I think I have to continue with two jobs even though it is less efficient.
I think this is an example of a very basic and essential advice that new users should find very easily without looking for it. Well, we already have it in the Duplicacy quick-start (CLI) but I don’t think it’s included in the GUI guide. I guess the web-ui will solve this as ot can (I suppose) easily alert users to these things.
Well, unless I misunderstand you again, you wont have to re-upload anything to the cloud but can instead download everything from the cloud if you create a new local storage using add and the copy everything from the cloud.
Once that is done, it’s probably better to switch things around as was mentioned earlier:
(where the first > is a backup and the second a copy job.)
Yes, the lack of documentation on the limitations and function of the GUI has definitely hindered me.
Can you re-initialize a storage location? If I download everything from the could backup to local (initialized with the add), how could I switch that around to make local primary and add the “add” to the cloud? When I tried to init something existing it exited because the .duplicacy folder and config file already existed.
Or, would I have to init a new repository/stoarge pair and then manually copy/move the chunks into those locations?
It depends what you mean by that. What I meant was that you delete your local storage (duplicacy storage, that is, of course) and initialize a new storage using the add command. You can csll that “re-initialize” if you wish.
I’m sorry, I can’t help you with the gui version as I have never used it.
Ignore the GUI, CLI is fine if the only way.
I’m trying to understand how the suggestion to copy from the cloud to the local backup gets me closer to
Repository > Local > Cloud
You imply that once the copy from Cloud>local is done that I can switch things around to go the other way, but wouldn’t that require the cloud storage to be init with the “add” flag, which it isn’t currently?
How would I switch it around as you suggest?
This is what I would do…
1) Create a new local repository using the add -copy command (from your cloud storage).
This effectively copies the storage parameters such as chunk size and encryption keys, making it copy-compatible. (You can use a different master password when using -encrypt if you want.)
2) Adjust your backup schedules to backup only to the local storage.
3) Run all your backup jobs to this new storage, using the same repository IDs.
This quickly populates the local storage with chunks that should be mostly identical to the ones in the cloud (minus historic revisions and some minor differences due to chunk boundaries while rehashing).
4) Copy (with -all) the cloud storage to the local storage.
This fills in the rest of the missing chunks from previous revisions, and brings all those old snapshots back to your local storage. This should also overwrite the snapshot revision #1 of all the backups made in step 2, with the original ones you did to the cloud time ago, unless these were pruned*.
5) Make a new job to copy -all from local storage to cloud storage.
Perhaps add this after the backup jobs, or you can do it once a day or whenever.
6) [Optional] Run a prune -exclusive -exhaustive on the local storage to tidy things up.
There’ll probably be unreferenced chunks from step 2.
Step 3 is basically a time saving procedure, and should hopefully save a lot of downloading.
You can do this with the web GUI but you’d need to use CLI for the add command.
*IF the revision 1s in the cloud were pruned, the local, temporary, ones you made in step 2 won’t be overwritten in step 4, so you might want to manually delete all the 1 files in the local storage under snapshots/ just to be consistent - I don’t know if there’ll be any adverse affects if you didn’t, though.
Thanks. That helps a lot.
I think I was misunderstanding how the add command functioned, but it makes more sense now. I missed that you can have the two different locations copy to each other on demand, I thought it was a one way process.
For anyone: Feel free to use the 
button on the posts that you found useful.
For the OP of any #support topic: you can mark the post that solved your issue by ticking the 
box under the post. That of course may include your own post 
My bad. I confused this with something else.