Data corruption check
Tony Abernethy
tony at servacorp.com
Wed Sep 19 10:20:44 GMT 2007
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)
More information about the rsync
mailing list