Backing up onto 2 hard drives at the same time

Hi there, after my previous post Some missing chunks, unable to restore previous versions - #19 by Goldmaster

In the end, i simply added .bk to the end of the config file and recreated the storage volume on my working wd drive with erasure and copy compatible enabled. i ran a check and it shows as success.

So what I want to do is tackle the Toshiba drive that missing chunks and i know i won’t get those back. I want to run a backup that can back up to both hard drives at the same time. But for some reason, i am not seeing going from source to both hard drives. i should be seeing something like source, -> wd drive drive @toshiba drive. But for some reason I am not seeing that all.


Keeping things simple, is it best for me to start again on the Toshiba drive as a blank spare and simply run a copy in the schedule option to mirror the wd drive to the Toshiba drive? The wd drive has the most revisions and is working fine? Any simple solutions, as this is starting to get too complex.

Thank you for your help.

As I said before, you shouldn’t have done that. The existing chunks are now completely dereferenced and everything that was there before will get removed entirely when you do a prune -exclusive. Basically equivalent to an empty storage. You can’t merge storages like that, nor make a storage copy-compatible where it wasn’t from the begining.

If you prefer to start again with WD data drive - so long as it’s 100% free of missing/bad chunks - go for it. If it’s not, you may have to manually delete bad snapshots and chunks til it is.

Recreate the storage on the Toshiba as copy-compatible with the WD, optionally add Erasure Coding if you want, then you can copy snapshots over with Duplicacy.

Well i did a check on the WD drive after doing this and it did say success. I am able to see the revisions. are you saying that i may set myself for problems down the road? Unfortunately, i did not have much choice to sort the problem out.

If the storage is encrypted, you won’t be able to do anything with the revisions - unless the config file was copied directly from a storage that was already copy-compatible, or you created the copy-compatible storage with Duplicacy itself.

Those revisions will fail to be restored (go ahead, try it), coz the config that unlocks the encrypted snapshots and in turn the encrypted chunks, no longer exists. You could always rename the config.bk back, and manually switch between them, but then you’d have a horrible mess of two incompatible storages intertwined and as soon as you do a prune -exhaustive (which is occasionally good to run, and sometimes necessary after manually deleting snapshots after encountering corrupted backups), one of your storages will get nuked.

Crucially, there’s no de-duplication happening because the chunks aren’t copy-compatible and therefore not deterministic, so you’re not saving on disk space either. You’ve gained nothing by renaming the config except inherit a right mess. (Again, this is all assuming an encrypted, non-copy-compatible, storage.)

If you want to dis-entangle the storages, you have no choice but to create a new storage (by creating an empty directory) and letting Duplicacy create it as copy-compatible while having one of the config files in place. Then copy the snapshots (probably specifying the compatible IDs by hand, as your earlier IDs can only be unlocked by the other config) across - with Duplicacy - and ultimately delete the old snapshots and revert the remaining config.bk so you can cleanup.

At the end of the day, if the two storages aren’t properly copy-compatible, they should reside in completely separate directory structures. i.e. config/snapshots/chunks.

well, the storages are not encrypted.

Are you saying for me to create a whole new backup in say a different folder on the Toshiba drive. set as copy compatible with the wd drive and then do a copy operation from wd to toshiba in the schedule tab on the web gui?

I don’t know the precise situation with unencrypted storages but I still think you’ll have difficulty restoring snapshot and chunk data that is referenced by a different config. So if in doubt, try it - test all your snapshots new and old would be my advice. In any case, fiddling with renaming config files is a bad idea.

I dont know if I am. I did remove the storage from the web gui and restore the original config file i then recreated the storage it does say this storage has already been initised.

However, restore seams to be taking quite some time. Check is successful and i can browse all the files and revisions. But when tryingto restore a very small file it seams to take a while, like a hour or so. I don’t know if it because I have like 30 or so revisions.

this issue of backing up has been going on for like weeks or so. i cant believe that is not some simple way of enabling copy compatible so i can backup onto the Toshiba drive as well without having to nuke all your previous versions backup and start again.

Only thing I could think of is to restore the whole of each revision and bit by bit, backup onto the Toshiba drive. Then set the WD drive as copy compatible and then remove the old backups.

This seams to be my only option