jgaunt/duplicacy
1
0
Fork 0
mirror of https://github.com/gilbertchen/duplicacy synced 2026-01-06 18:43:40 +00:00
Code Issues Releases Wiki Activity

Updated Missing chunks (markdown)

gilbertchen
2018-01-24 22:36:43 -05:00
parent 673c32d869
commit ed25793673
1 changed files with 6 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Missing-chunks.md

@@ -25,7 +25,7 @@ Deleted chunk 297dcc3d83dc05b8e697535306a3af847435874cbe7d5a6b5e6918811d418649 (
Deleted cached snapshot test at revision 1
```
This log indicates that these chunks were removed when the [[prune]] command was invoked with the `-exclusive` option.
This log indicates that these chunks were removed when the [[prune]] command was invoked with the `-exclusive` option, because these chunks are only referenced by the snapshot to be deleted, and the `-exclusive` assumes there weren't any other ongoing backups.
This is an excerpt from the another prune log:
```
@@ -34,9 +34,12 @@ Marked fossil 0e92f9aa69cc98cd3228fcfaea480585fe1ab64b098b86438a02f7a3c78e797a
Marked fossil 3ab0be596614dd39bcacc2279d49b6fc1e0095c71b594c509a7b5d504d6d111e
Marked fossil a8a1377cab0dd7f25cac4ac3fb451b9948f129904588d9f9b67bead7c878b7d0
```
These chunks weren't immediately removed but rather marked as fossils. This is because another ongoing backup that was seen by the prune command may reference any of these chunks. To be safe, the prune command will turn them into fossils, which can be either permanently removed if no such backup exists, or turned back into normal chunks otherwise. Please refer to [this wiki page] for a detailed explanation of this technique.
If you can find the missing chunk in any of these prune logs, then it is clear that the [[prune]] command removed it in the exclusive mode or marked it as a fossil (which may be removed at a later time). If you think the [[prune]] command removed or marked the chunk due to a bug, then submit a github issue with relevant logs attached. However, more often the prune command was incorrectly invoked with the `-exclusive` option, while there was still a backup in progress from a different computer to the same storage. In this case, a [[check]] command after the backup finishes will immediately reveals the missing chunk.
If you can find the missing chunk in any of these prune logs, then it is clear that the [[prune]] command removed it in the exclusive mode or marked it as a fossil (which may be removed at a later time). If you think the [[prune]] command mistakenly removed or marked the chunk due to a bug, then submit a github issue with relevant logs attached. However, more often the prune command was incorrectly invoked with the `-exclusive` option, while there was still a backup in progress from a different computer to the same storage. In this case, a [[check]] command after the backup finishes will immediately reveals the missing chunk.
What if the missing chunk can't be found in any of these prune logs? We may not be able to track down who was the culprit. It could be an unknown bug in Duplicacy, or in the cloud storage service, or it could be a user error. To prevent this from happening again, you should always run a [[check]] command after every backup or before every prune.
What if the missing chunk can't be found in any of these prune logs? We may not be able to track down who the culprit was. It could be a bug in Duplicacy, or a bug in the cloud storage service, or it could be a user error. If you do not want to see this happen again, you may need to run a [[check]] command after every backup or before every prune.
Is it possible to recover a missing chunk? Maybe, only if the backup where the missing chunk comes from was done recently and the files in that backup haven't changed since the backup. In this case, you can modify the `.duplicacy/preferences` file to assign to the repository a new id that hasn't been used by any repositories connecting to the same storage, and then run a new backup. This backup will be an initial backup because of the new repository id and therefore attempt to upload all chunks that do not exist in the storage. If you are lucky, this procedure will be able to produce an identical copy of the missing chunk.
If you are uninterested in figuring out why the chunk went missing and just want to fix the issue, you can keep removing by hand the affected snapshot files under the `snapshots` folder in the storage, until the `check -a` command passes without reporting missing chunks. At this time, you should be able to run new backups. However, there will likely be many unreferenced chunks in the storage. To fix this, run `prune -exhaustive` and all unreferenced chunks will be identified and marked as fossils for removal by a subsequent prune command. Or if you're very sure that no other backups are running, `prune -exhaustive -exclusive` can remove these unreferenced chunks immediately.