Re[4]: [rdiff-backup-users] Verify times increasing

[listserv . traffic]

[Now I'm bottom posting... :)]

>> ---
>> I'm not aware, so if I'm wrong perhaps someone could correct me, but
>> I'd like a command to, in essence, do a comprehensive
>> --verify-all-files-in-the-archive. [I'm pretty sure such a thing
>> doesn't exist, at least I never saw it in the docs.]
>>
>> This would apply all deltas to *all* files (back to the oldest copy)  
>> and compare the stored
>> hashes at the time of backup to the rebuilt file. [Note all the
>> files, not just those in a particular target date/delta.]
>>
>> This wouldn't verify that every file would be correct in every delta
>> version, but it would, I think, get as close as one might come to
>> that.

> I agree, something like this would be great. Although with the speed  
> issue's I'm having it may not be practical (i.e. time feasible) to  
> reconstruct every file this way before comparing it to a signature  
> hash. I would propose that rdiff-backup store some additional meta- 
> data which would consist of signature hashes of the delta files as  
> they exist on the disk after rdiff-backup is finished with a backup  
> (similar to what yafic does - http://www.saddi.com/software/yafic/).  
> This should make the verification process much faster (yafic takes  
> less than two hours to verify an rdiff-backup repo that takes over  
> eight hours to --verify-at-time on my setup). Note that it would not  
> replace the --verify-at-time functionality, which would still be  
> necessary to verify the integrity of files as they existed before the
> backup. But it would provide a fast way to verify the integrity of an
> rdiff-backup repository.

Let me address this. Simply checking the a hash of the delta isn't
nearly enough. If the meta-data on how to apply that delta is gone or
corrupt, you're screwed too.

So, if you're going to calc and store a hash, you should store a hash
of both the meta-data and the delta.

Small nit, but thought I should mention it.

[I should note that I have never examined the code, so I'm speaking
from a theoretical point of view - but I've asked about these things
pretty carefully, so I'm pretty sure I'm clear on how things are
handled... I'm welcome to be corrected if I'm wrong.]

-Greg