Data corruption check

[Tony Abernethy]

Fabian Cenedese wrote:
> At 15:15 18.09.2007 -0400, Matt McCutchen wrote:
> >On 9/18/07, Fabian Cenedese <Cenedese at indel.ch> wrote:
> >> I was wondering what happens if a file that is regularly 
> synched but
> >> seldom changes gets corrupted in the copy.
> >
> >Are you referring to rsync writing corrupted data to the destination
> >file or a problem with the destination filesystem or disk causing the
> >file to read as data different from what was written?
> 
> I was thinking of any problem, even a transport error.
> 
> >> There's also the -I, --ignore-times switch. If I use this 
> but without -c
> >> what method is used for checking then? Or does -I imply -c?
> >
> >-I rewrites the destination file no matter what, while -c 
> computes its
> >MD4 or MD5 checksum first and then rewrites it only if its checksum
> >differs from that of the source file.  Either option gives the same
> >end result for the destination file.  However, they may have 
> different
> >performance (-c uses more disk reading but potentially less disk
> >writing and slightly less network traffic), and -I logs more 
> transfers
> >than -c and interferes with --link-dest.
> 
> Thanks for the explanations. That means that -l and -c are not
> usable together as they contradict themselves, right?
> 
> I was asking because I'm responsible for our backups. The
> current solution with rsync works nicely. While the RAID storage
> also monitor the HD's SMART state I was still wondering
> about a way to detect otherwise unknown data corruption.
> 
> I guess if I first made a normal rsync and then a rsync --dry-run -c
> I could find file differences that shouldn't be (provided there
> wasn't any real change otherwise, like in the middle of the night).
> Of course that wouldn't tell me what side had changed, but still
> something worth considering doing once a month or so...
> 
> Thanks for your help
> 
> bye  Fabi
> 
Seems like an old sailors rule:
Have one chronograph or three, never two.
With two, you know something is wrong, but no idea what to do.

Disk is cheap.
Thanks for the idea of the rsync --dry-run -c
Methinks it will help a lot of Windows users. 
(even with only two comparands)