Data corruption check

[Fabian Cenedese]

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