Sanity check: integrating -chunks

[87aa841a6fec03dd1ad6]

I’ve used Duplicacy for several months now for daily backups with no issues, everything’s working smoothly.

I just noticed the -chunks feature in check and figure I should integrate it into my schedule.

A few questions before I do:

(1) Would it be reasonable to run this weekly?

(2) I run all my check commands with -fossils -resurrect. Is there a reason not to run this weekly check with -fossils -resurrect -chunks?

(3) I backup to 2 separate storages on alternate days. (I don’t use copy.) Is it okay to run these chunk checks on the two storages in parallel? It seems so but I’d like to confirm.

Thanks.

[gchen]

@87aa841a6fec03dd1ad6

Would it be reasonable to run this weekly?

The latest CLI version saves verified chunks in a local verified_chunks file and only verified chunks not in this file. So yes, running it weekly shouldn’t be a problem.

@87aa841a6fec03dd1ad6

I run all my check commands with -fossils -resurrect . Is there a reason not to run this weekly check with -fossils -resurrect -chunks ?

I wouldn’t run check with -fossils -resurrect. Fossils should be handled by the prune job only.

@87aa841a6fec03dd1ad6

(3) I backup to 2 separate storages on alternate days. (I don’t use copy.) Is it okay to run these chunk checks on the two storages in parallel? It seems so but I’d like to confirm.

I don’t see a problem if you have enough network bandwidth.

[87aa841a6fec03dd1ad6]

The latest CLI version saves verified chunks in a local verified_chunks file and only verified chunks not in this file

I see. I assumed -chunks would detect file corruption over time but no, it simply verifies the initial upload of the chunk was correct. Got it.

I wouldn’t run check with -fossils -resurrect. Fossils should be handled by the prune job only.

You mean unless I first run prune? That makes sense. Okay here’s what my schedule looks like now. Any obvious mistakes? (Ignore the -keep options which I’ve changed since.)