[rdiff-backup-users] Vailidation of RDiff archive...

[listserv . traffic]

I have several questions, but I'll split them into separate posts so
they're better found and followed on the list for posterity purposes.

I don't think it really matters in this discussion, but in all the
cases I'm using RDiff-Backup currently, I'm using local resources -
either on the same machine, or the same local network - thus concerns
about slow bandwidth connections doesn't apply.

--
I've seen some discussion on the list about verifying the archive,
however none of the answers really seem to tackle the issue of
validating the soundness of the RDiff "repository."

So, if I were to want to verify that the repository and all reverse
slices *could* be applied without error, is there such a mechanism
available?

Note, I'm not asking that it actually apply those slices and check
the resulting files with anything - but is there a way to be sure
that the archives, transaction and rdiff slices all LOOK ok?

(Sure, lets assume perhaps there's a wrong set of bytes that will corrupt
the resulting file and it's not exactly as it was when it was
"archived" on the date it was backed-up, but the "instructions" for
restoring it and the slices needed to do so all exist and are
transactionally sound...) [In other-words, I'm not asking for a SHA
style check of the file after rolling it back, but that it would be
possible to roll it back given the transactional data, and such...]

---
Is there a discussion somewhere that expands on the man-page for
the --compare options and the --verify option. I think I understand
what it's doing, but am not sure. I don't want to waste someone's
time repeating a response already given, but I couldn't find one in
my searches on the list.

---
Where most of the thrust of these questions is going, is I'd like to
know the available ways to verify an archive is still sound, and
sane.

Also, to verify that a current backup matches exactly that of the
source.

TIA!
-Greg Sloop