Does the latest check verify that all chunks exist for the latest revisions, after pruning removes earlier revisions?

[beep-beep]

I’m using the web-ui. I’ve been running backups and exhaustive prunes about once per month. So that revisions 6, 14, 18, 19 exist, but the earlier revisions 1-5 have already been deleted.

If the latest check says “all chunks at revision X exist”, does that mean everything is fine?

I’ve been running checks before and after each prune. But I only looked at the logs to confirm the storage size. I didn’t pay attention to the “all chunks… exist”. Although the web-ui always displayed a green colored “checked” when completed.

The problem I’m envisioning is, theoretically if I’ve missed a log in the past that chunks were missing, but subsequently ran prunes and backups with newer revisions, Is it possible the latest check wouldn’t pickup that a chunk is missing from an earlier revision that has already been removed, but that the latest revision builds upon?

[saspus]

@beep-beep

exhaustive prunes about once per month

There is no reason to do this on a schedule. Exaustive prune is only useful if you manually deleted snapshot files behind duplicacy’s back, and now want to clear out orphaned chunks that no snapshot is referencing. Otherwise it’s a waste of time and api calls, depending on the endpoint.

@beep-beep

“all chunks at revision X exist”, does that mean everything is fine?

yes.

@beep-beep

Is it possible the latest check wouldn’t pickup that a chunk is missing from an earlier revision that has already been removed, but that the latest revision builds upon?

No, check checks that all revisions reference chinks that exist, unless you requested otherwise with a command line arguments.

What arguments are you passing to check? (they shall be in the check log, in the very beginning)

You can easily check that. Move few chunk files out of the storage location and run check.