Hi I was wondering what happens if a file that is regularly synched but seldom changes gets corrupted in the copy. As it seldom (or never) changes the mod time will always be the same. But if the content changes (bit flip, bad HD...) will rsync get this and synch it again? Would I need the -c (crc) flag for this to work? That of course slows things down quite a bit. Is this the only way to ensure that the contents are the same on both sides? 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? Thanks bye Fabi
On 9/18/07, Fabian Cenedese <Cenedese@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?> As it seldom (or never) > changes the mod time will always be the same. But if the content > changes (bit flip, bad HD...) will rsync get this and synch it again?No...> Would I need the -c (crc) flag for this to work? That of course slows > things down quite a bit. Is this the only way to ensure that the > contents are the same on both sides?Yes, yes. The only way to check whether a bit of the file has flipped due to HD or filesystem flakiness is to read the entire file, which is what -c does.> 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. Matt
At 15:15 18.09.2007 -0400, Matt McCutchen wrote:>On 9/18/07, Fabian Cenedese <Cenedese@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