Re[2]: [rdiff-backup-users] what exactly does "--verify-at-time xyz" do...

[listserv . traffic]

> Yes, it looks like that is correct, based on my reading of the source,
> and some quick experimentation.

> Does that match with your experiments?

Andrew, et al.

It certainly appears to, though it's difficult to tell what it's
doing under the hood.

I can't tell if it is, for sure, taking the current file applying all
the applicable reverse diffs and then sha-1 check-summing the
resultant file and comparing that hash with the stored hash it
calculated from the file on the date of the original backup.

But if it is, and your verification and the docs seem to indicate
that's what it's SUPPOSED to be doing, it's working fine here.

I get a report that shows the files match, but I don't know exactly
what's going on, since even at --verbosity 9 it doesn't tell me much.

It says it verified the SHA1 digest, but the high verbosity doesn't
tell me what it did to verify it...

...
Mon Mar 23 20:53:21 2009  Verified SHA1 digest of TW/TruckWins/GTI.mdb
Mon Mar 23 20:53:21 2009  Verified SHA1 digest of TW/TruckWins/NewDB97.mdb
Mon Mar 23 20:53:26 2009  Verified SHA1 digest of TW/TruckWins/SetupADO2003.EXE
Mon Mar 23 20:53:26 2009  Verified SHA1 digest of TW/TruckWins/Training.MDB
Mon Mar 23 20:53:26 2009  Verified SHA1 digest of TW/TruckWins/fb.exe
Mon Mar 23 20:53:26 2009  Verified SHA1 digest of TW/TruckWins/master.mdb
Mon Mar 23 20:53:27 2009  Verified SHA1 digest of TW/TruckWins/temp.mdb
Mon Mar 23 20:53:27 2009  Every file verified successfully.
Mon Mar 23 20:53:27 2009  Cleaning up

---
*Minor complaint*
It doesn't tell me either at the head or the tail what it's doing. I
asked it to compare --verify-at-time 365D, but the only way you can
tell it actually did it, is to grep the output of a high verbosity
run for "Applying" and manually verify that it's applying rdiffs back
to the oldest date in the archive, or the date you put in (in this
case 365D).

A summary stats output would be nice - either at the head or tail of
the output.
---

So, I guess given I understand this option properly, (which my tests
and your verification seem to agree I do) this method is BY FAR the
most superior way of verifying the entire archive integrity.

1) It verifies that all the rdiff parts and the meta-data exist and are
valid.

2)It applies those rdiffs, and checks the resulting file with
the SHA-1 hash with the stored hash of the file when it was
originally backed up.

3) If any of the rdiffs are not available, or the resulting sha-1 calc
on a "rebuilt" file don't match the original, the --verify-at-time
will fail, and that will let you figure out why the repository isn't
working properly.

I'll probably do weekly tests of the system and forward any failures
via email for scrutiny.

That seems pretty damn bullet-proof to me.

Rather than testing the integrity of the GZ files, doing a dry,
complete restore or anything else, this seems to kill all the birds
with one stone.

(I guess the one thing it won't do, is protect you from malicious
data tampering from someone who has access to the destination
repository, but that's far outside the scope of what I'm attempting
to verify.)

Any further thoughts?

Thanks again so very much for your help and thoughts!

-Greg