[CentOS] evaluating backup systems: rsync
webmaster at ew3d.com
Sat Jan 19 19:21:38 UTC 2013
On 1/19/2013 1:28 PM, Nicolas Thierry-Mieg wrote:
> Reindl Harald wrote:
>> Am 19.01.2013 15:46, schrieb Nicolas Thierry-Mieg:
>>> M. Fioretti wrote:
>>>> On Fri, Jan 18, 2013 08:07:40 AM -0500, SilverTip257 wrote:
>>>>> if you really want to eliminate that data being transferred, I
>>>>> suppose you could do the extra work and rename the directory at the
>>>>> same time on the source and destination. Not ideal in the least.
>>>> Not ideal indeed, but I'll probably do it that way next time that some
>>>> renaming like this happens on very large folders. I assume that after
>>>> that, I'd also have to launch rsync with the options that says to not
>>>> consider modification time.
>>> no I don't think you will, since the file modification times won't have
>> and even if the did - who cares?
>> * rsync does not transfer unchanged data ever
>> * rsync will sync the times to them from the sources
>> * so have nearly zero network traffic
> Not true: if you change the modification time on a file, by default
> rsync will copy the whole file again.
> See man rsync:
> Rsync finds files that need to be transferred using a “quick check”
> algorithm (by default) that looks for files that have changed in size or
> in last-modified time.
> and yes I've tested this before posting ;-)
> to avoid this you need to use --size-only .
Yet size only is not reliable. If for instance you have a simple text
file with the word hellO and someone catches the typo and changes it to
hello, the filesize doesn't change as near as I can see. Both show as 6
using ls -al. Unless rsync uses a more granular check of filesize that I
am not aware of? If this is the case, then someone could potentially
edit a large document fixing numerous simple typos and wind up with the
877-777-1407 ext 502
Comprehensive Online Solutions
More information about the CentOS