Tried getting the backup running again, without succes so far:
20250506_2110_CheckPersist
20250506_2116_PruneExhaustiveExclusive
After these I cleared the cache:
20250507_0921_PostClearCache_CheckPersist
20250507_0924_PostClearCache_PruneExhaustiveExclusive
20250507_0927_PostClearCache_CheckPersist
Any suggestions on how to get the backup running again are highly appreciated!
I’m sorry I can’t help. But your struggles lead me to wonder aloud: is anyone out there using OneDrive as a backend consistently avoiding errors?
I tried an initial setup to OneDrive Business and it was a total mess. Throttling, rate-limiting, and other errors nonstop. I gave up quickly and switched to GCS, which after one mis-step that I’m pretty sure was my fault, has been working great.
I would manually delete bad snapshot revisions (add -persist and -resurrect to check to find all of them in one go) – they were supposed to be pruned away anyway), then ensure no other duplicacy is touching the store and run prune -a -exhaustive -exclusive to delete any remanning orphans.
These *drive based backends cannot be expected to work well in the scenarios they were not designed to be used in. Prior discussion:
Doesn’t seem to do much (different):
Running check command from /cache/localhost/all
Options: [-log check -storage OneDrive -a -tabular -persist -resurrect -a -tabular]
2025-05-08 08:15:17.228 INFO STORAGE_SET Storage set to one://Duplicacy
2025-05-08 08:15:26.204 INFO SNAPSHOT_CHECK Listing all chunks
2025-05-08 08:17:08.211 INFO SNAPSHOT_CHECK 1 snapshots and 27 revisions
2025-05-08 08:17:08.211 INFO SNAPSHOT_CHECK Total chunk size is 1,219M in 275 chunks
2025-05-08 08:17:08.677 WARN DOWNLOAD_CHUNK Chunk 6454ff8a44637668a8138a75e57be2a2f194d01b43e24958f22c8c140e380877 can't be found
2025-05-08 08:17:08.678 ERROR SNAPSHOT_CHUNK Failed to load chunks for snapshot UnraidAppdata at revision 1: unexpected end of JSON input
Failed to load chunks for snapshot UnraidAppdata at revision 1: unexpected end of JSON inputLooks like you have a missing metadata chunk in revision 1. IMO the only way to fix this is to delete all revisions for the snapshot ID, clear your local cache, then run a fresh backup. It’ll take longer but it won’t spend time re-uploading chunks.
However, DO NOT run a prune to clean-up yet, as you want most of the chunks to stay until they’re properly referenced. You should only clean up after you’ve got a good revision.
Hello, I ran into the same issue with the web version.
I tried both:
hotio/duplicacy:latest
https://hub.docker.com/r/saspus/duplicacy-web latest
and both use an older cli version =>
/config/bin/duplicacy_linux_x64_3.2.3
Do you know if that is an issue with the dockercontainers or the web version?
CLI version Web UI uses is determined by https://duplicacy.com/latest_cli_version
You can override it
Another update, I took the advice of @Droolio, although I didn’t delete all revisions. I had revision 1 till 31 in onedrive and removed 1 to 10: check failed, removed 11 to 20: check successful.
log
Ran a successfull prune as well.
log
Decided to run the entire schedule (backup, check & prune), backup completed, both check & prune failed.
I realized only afterwards that the prune after the successful check didn’t have the debug parameter, however still wanted to share the results.
Although this prune states in the log it removed revision 21 till 24, these are still present in one-drive.