Hi: I just wanted to thank you for your help. I was able to get a comprehensive list using the checksum switch. To summarize I recovered my data with:
-acvzIi --no-o --no-g --no-p -Clint On Wed, Oct 28, 2015 at 10:22 AM, Kevin Korb <k...@sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > if you see >f it is doing something to the file. At least a > delta-xfer. If it was just a metadata change it would show cf. If > you see an >fc without a t then that is an example where rsync found a > file that didn't match even though the timestamps did. That isn't > supposed to happen very often. > > On 10/28/2015 01:19 PM, Clint Olsen wrote: > > Ok, thank you for this extra info. I have experienced exactly what > > you described. The rsync dry run is _still_ running after being > > started at 1:30am PST :) > > > > But it is finding the right files to update. Most of the entries > > are: > > > >> fc........ > > > > Which is what I want. > > > > So, just because I see: > > > >> f > > > > at the beginning... > > > > That doesn't necessarily mean that the file is going to get updated > > at the destination? In other words, you're saying that just doing > > the delta transfer is more time efficient and rsync won't touch the > > file unless _some_ relevant change is observed? It just concerned > > me because the file list was extensive, and I definitely don't want > > anything copied unless for example the checksums don't match. > > > > Thanks, > > > > -Clint > > > > > > On Wed, Oct 28, 2015 at 5:41 AM, Kevin Korb <k...@sanitarium.net > > <mailto:k...@sanitarium.net>> wrote: > > > > --checksum generally takes a lot longer than --size-only. A delta > > transfer generally goes quicker than a checksum. However, if you > > want to make a list of what is corrupt a checksumming utility that > > is less stupid than rsync can be useful. I say that because > > rsync's --checksum is entirely unintelligent. It will checksum > > every single file on both ends including files that only exist on > > one end and files that shouldn't match (the size is wrong). At the > > end of --checksum you will still have to do the delta xfers that > > you would do without it. > > > > OTOH, you are using --dry-run. If you are trying to generate a > > report about what files are corrupted then only --checksum an do > > that. It will just do it in the dumbest/slowest way possible. > > > > On 10/28/2015 02:08 AM, Clint Olsen wrote: > >> What about -c? It seems I'm getting a lot of spurious file > >> transfer candidates when using: > > > >> -avvznIi --no-o --no-g --no-p > > > >> It's showing transfers (receive) for many files I know haven't > >> been tampered with. > > > >> Thanks, > > > >> -Clint > > > >> On Tue, Oct 27, 2015 at 7:53 PM, Kevin Korb <k...@sanitarium.net > >> <mailto:k...@sanitarium.net> <mailto:k...@sanitarium.net > >> <mailto:k...@sanitarium.net>>> wrote: > > > >> That is correct. Rsync will re-copy (delta xfer unless > >> --wholefile) all the files. You can always --dry-run if you > >> aren't sure. > > > >> On 10/27/2015 10:07 PM, Clint Olsen wrote: > >>> Hi: > > > >>> I've been using rsync to create backups for a few years. A few > >>> months ago I started experiencing sector errors. I ended up > >>> replacing the drive and copying the drive data. It turns out > >>> that due to the default behavior of rsync "quick check", some > >>> of the files were modified without altering the modification > >>> time or size, so these files are still clean in the backup. I > >>> would like to recover these files, but I need to defeat the > >>> quick check in order to do this. It looks like using: > > > >>> -I, --ignore-times don't skip files that match size > >>> and time > > > >>> will work. I just want to confirm that this covers it. The > >>> long-form of the switch doesn't mention size, so I was > >>> concerned this was the right way to accomplish this. If there > >>> are any other switches that would be useful in the context of > >>> potentially corrupt files, please feel free to chime in... > > > >>> Thanks, > > > >>> -Clint > > > > > > > > > > > >> -- Please use reply-all for most replies to avoid omitting the > >> mailing list. To unsubscribe or change options: > >> https://lists.samba.org/mailman/listinfo/rsync Before posting, > >> read: http://www.catb.org/~esr/faqs/smart-questions.html > > > > > > > > > > > > > > -- Please use reply-all for most replies to avoid omitting the > > mailing list. To unsubscribe or change options: > > https://lists.samba.org/mailman/listinfo/rsync Before posting, > > read: http://www.catb.org/~esr/faqs/smart-questions.html > > > > > > > > > > - -- > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., > - -*~ > Kevin Korb Phone: (407) 252-6853 > Systems Administrator Internet: > FutureQuest, Inc. ke...@futurequest.net (work) > Orlando, Florida k...@sanitarium.net (personal) > Web page: http://www.sanitarium.net/ > PGP public key available on web site. > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., > - -*~ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlYxBG0ACgkQVKC1jlbQAQeUuwCeLWbozz3DbuAXn94/ZnBQaiW5 > l94AoNkjkk6QK4Pfjf6qHtOd1ml4xxi8 > =lIwU > -----END PGP SIGNATURE----- > > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html >
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html