You can therefore pre-seed your new storage with fresh backups from your primary data to dummy snapshot IDs. One of the advantages of a copy-compatible storage is that chunks are deterministic - the same chunk data (mostly) is produced again, from the same source data. (You could also copy the /chunks and /snapshots directories too but you don’t know their current state…) However, you can completely skip all this and just copy the config file (at the root of the storage) and, so long as it isn’t corrupted, bam you have an empty, copy- and bit-identical storage. So if you want to use Windows Explorer you’ll need the storages to be bit-identical and hence use the add command from the CLI, with -copy -bit-identical flags. You may not be able to recover all that’s possible to recover. While Duplicacy copy can help you repair bad/missing chunks between storages that are copy-compatible (but not -bit-identical), I don’t believe it has a -persist flag so it may stop when encountering errors. (Erasure coding adds parity to chunks and isn’t a 100% guarantee, but it has a chance of recovering data on single drives with occasional bad sectors - but this is for future prevention, not now) Personally, in your situation I’d leave the Erasure Coding til later and concentrate on recovering your data first.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |