It’s still not clear if the missing chunks in your case, are from historic revisions or is missing from the last backup. Your logs should say what revisions the missing chunk pertains to. So hopefully you only have to delete revisions that are affected.
Also, if it’s not missing from the last backup, you only need to delete the revisions they’re missing for. If it’s missing for the last backup, you need to ‘fix’ the missing chunk or delete enough revisions until you have an intact most-recent snapshot as your last revision.
I wouldn’t use prune to delete these revisions as it may abort when it discovers a chunk is missing, and cause more chunks to be renamed to fossils and not properly collected.
To delete the revisions, you simply delete the numbered files under the storage in the \snapshots\<repository_id> folder…
As far as fixing it upon the next upload, it’s not quite as simple as that. To enable incremental backup, Duplicacy assumes that all the chunks referenced in the last revision actually exist. It doesn’t check if they do, so will skip them regardless.
But you can often force these missing chunks to be re-uploaded (if it’s still part of you existing repository and not old data that’s long been deleted). One way to do this is to create a new temporary backup ID - pointing at the same repository location. Running such a backup will check which chunks exist on the storage and then rescan the whole repository and re-upload everything, skipping chunks that don’t need to be uploaded, uploading only the missing chunk(s). This should fix things but there’s a small chance the chunk doesn’t get recreated from the current state of the repository.
Oh and if you delete any revisions, keep a copy or put them in the recycle bin. If you’re able to restore the missing chunk(s), those revisions will be good again. Put them back and your storage should be good again.
