Hi, Some of my files recently became corrupted due to disk I/O errors (bad SCSI terminator). I've fixed my I/O errors, run fsck, and am now wanting to restore from my rsync backup. However, some time has passed, and users have continued working, creating new files, in some cases with the same filename as existed before the disk I/O problems started. E.g. editing a .c file to fix a bug. Some of the files are corrupt, even though they have the same file sizes and timestamps (often years ago) as the backup files. I've spot-checked and confirmed that the backup files are not corrupt. Ok, this should be easy, right? Let's see what would happen: rsync -auIn backup:/archive/home /home The "-I" tells rsync to ignore the timestamps (the corrupt files still have old timestamps) and the file sizes (the corrupt files are the same size as the backup non-corrupt files) and do the checksums to determine which files need to be transferred. The "-u" tell rsync not to overwrite newer files. I've over-written old files, and I don't want the backup files to clobber these. However, it appears from the lines of output that rsync spews out, that it would clobber newer files. Does turning on "-I" mess up the time-comparison needed by "-u"? Also, if I do a manual "diff" between the files that rsync -auIn prints to std out, most of them show no difference. Am I correct in assuming that rsync does not perform the checksum to detect if each file needs to be transferred when using "-n"? Is there some way to force it to do the checksum and tell me which files it would _actually_ transfer? Thanks, Bart --- Bart Brashers, Ph.D. Air Quality Meteorologist Geomatrix Consultants, Inc. 19203 36th Ave W Suite 101 Lynnwood WA 98036-5772 425-921-4000 (main) 425-921-4020 (direct) 425-921-4040 (fax)
Eberhard Moenkeberg
2005-Feb-04 23:06 UTC
rsync -auIn not doing what I expect (rsync 2.6.3)
Hi, On Fri, 4 Feb 2005, Bart Brashers wrote:> Some of my files recently became corrupted due to disk I/O errors (bad > SCSI terminator). I've fixed my I/O errors, run fsck, and am now > wanting to restore from my rsync backup. > > However, some time has passed, and users have continued working, > creating new files, in some cases with the same filename as existed > before the disk I/O problems started. E.g. editing a .c file to fix a > bug. > > Some of the files are corrupt, even though they have the same file sizes > and timestamps (often years ago) as the backup files. I've spot-checked > and confirmed that the backup files are not corrupt. > > Ok, this should be easy, right? Let's see what would happen: > > rsync -auIn backup:/archive/home /home > > The "-I" tells rsync to ignore the timestamps (the corrupt files still > have old timestamps) and the file sizes (the corrupt files are the same > size as the backup non-corrupt files) and do the checksums to determine > which files need to be transferred.Why do you want to say "ignore timestamps" if just the "corrected" files have newer than the corrupt ones? Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On Fri, Feb 04, 2005 at 11:41:28AM -0800, Bart Brashers wrote:> The "-I" tells rsync to ignore the timestamps (the corrupt files still > have old timestamps) and the file sizes (the corrupt files are the same > size as the backup non-corrupt files) and do the checksums to determine > which files need to be transferred.This really tells rsync to skip the quick-check of the time/size and transfer everything (barring other restrictions). Identical files will be quickly updated because of all the matching data in the basis file (if -n weren't specified). If you don't want to see the identical files listed, you'll need to use the -c option, which turns on a checksum pre-check (making -I redundant).> However, it appears from the lines of output that rsync spews out, that > it would clobber newer files. Does turning on "-I" mess up the > time-comparison needed by "-u"?I tested 2.6.3, and -u prevents rsync from updating an older file, even with -I (with or without -c). Oh, I see, your command is wrong:> rsync -auIn backup:/archive/home /homeYou should either leave off the trailing "home" in the destination, or use a trailing slash on the source: rsync -auIn backup:/archive/home / Without that, rsync is copying all files into /home/home. ..wayne..