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