Missing chunk in a storage: can I fix it using a second storage?

[budz]

I’ve read Fix missing chunks

I use Duplicacy to back up my documents to two storages: a local hard disk drive (no encryption) and Backblaze (with encryption). Backblaze is copy compatible with the HDD storage.

Because of a material failure, I have lost a chunk in the local HDD. The chunk is no longer in cache. Is there a way to recover the missing chunk using Backblaze storage? More generally, do I have a way to salvage the broken snapshots?

I use Duplicacy Web UI and I am not very familiar with the CLI.

Thank you in advance

[Droolio]

Did you use the -bit-identical flag when creating the copy-compatible storage? If you did, you could just copy the chunk file of the same name.

However, if not…

I would temporarily rename the snapshot directory on the HDD storage out of the way - e.g. snapshots.old, then do a reverse copy from your Backblaze to local. That should only fill in any missing chunks, without downloading anything unnecessary.

At this point, you could switch the snapshots.* folders back to original and run a check, or if your revisions are pretty much the same anyway, keep the new snaphots dir and maybe run a prune with -exhaustive on both storage to cleanup.

[87aa841a6fec03dd1ad6]

I wouldn’t think you could have bit-identical between encrypted and un-encrypted.
Or am I misunderstanding its meaning?

[Droolio]

Oh right, missed that bit. Then indeed, they’d be non-bit-identical, but if they’re copy-compatible, you should still be able to copy them both ways…

The only way you can get Duplicacy to fill in missing chunks, is to pretend the revisions which reference those chunks, aren’t on the destination. So temporarily moving the `‘snapshots’ folder out of the way, would make Duplicacy index the chunks and copy all the revisions back, but skip downloading chunks which already exist.

It would take a little longer but you should see little bandwidth usage with your Backblaze.

Alternatively, if there’s only one or a few missing chunks, and you know which revisions these pertain to, you could always delete the revisions until check runs fine.

[87aa841a6fec03dd1ad6]

Thanks and is it correct that if they were both encrypted they could be bit-identical, or do different storages use different keys?

The relevance to the OP is, assuming they could be, encrypting local storage would allow recovery with a simple copy or rsync of the missing/corrupted chunks. I ran into the same problem with a similar setup (with neither storage encrypted) and that’s how I solved it.

[budz]

Many thanks for your help. As you correctly guessed, the HDD and Backblaze storages were not bit-identical, so it was not possible to manually copy the missing chunk.

Droolio’s solution worked flawlessly: I removed the snapshots directory from HDD storage, and ran a copy command from Backblaze to HDD storage. As a result, only the missing chunk was recreated in HDD storage, so the bandwidth usage was minimal.

Many thanks