OneDrive check fails after prune

[marcnijman]

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!

[fronesis]

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.

[saspus]

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.

[saspus]

@fronesis

is anyone out there using OneDrive as a backend consistently avoiding errors?

These *drive based backends cannot be expected to work well in the scenarios they were not designed to be used in. Prior discussion:

(Newbie) Backup entire machine?

Yes. As an example, directory enumeration with multiple files inside (think chunks subfolder) maybe be/is throttled, or otherwise rate limited, either on purpose to discourage bulk storage or simply by not being optimized for such usecase. Dropbox is the worst in this regard. Even without the neee to get into technical details you can just go by a general principle that it is always best when your goals and incentives are aligned with that of your service provider. Services like Dropbox, OneD…

[marcnijman]

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 input

[Droolio]

Looks 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.

[karateviktor]

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?

[saspus]

CLI version Web UI uses is determined by https://duplicacy.com/latest_cli_version

You can override it

Disable automatic duplicacy CLI update

You can set the CLI version in ~/.duplicacy-web/duplicacy.json: { ... "cli_version": "2.7.2", ... } Then the web GUI will stick to this version. By default this key has an empty value and the web GUI will visit https://duplicacy.com/latest_cli_version to retrieve the stable/latest version. You’ll need to restart the web GUI for the change to take effect.