rsync 1tb+ each day

[Eric Whiting]

Kenny Gorman wrote:
> 
> >>I am rsyncing 1tb of data each day.  I am finding in my testing that
> >>actually removing the target files each day then rsyncing is faster than
> >>doing a compare of the source->target files then rsyncing over the delta
> >>blocks.  This is because we have a fast link between the two boxes, and
> >>that are disk is fairly slow. I am finding that the creation of the temp
> >>file (the 'dot file') is actually the slowest part of the operation.
> >>This has to be done for each file because the timestamp and at least a
> >>couple blocks are guaranteed to have changed (oracle files).

I'm seeing similar behavior here.

I ran rsync tests on oracle database files. I have four online snapshots (daily)
from hot backups of a database. A given file will appear in all the snapshots as
the same size with just a handful of changed blocks. 

I tested with a small 256M datafile. rsync -av is showing me about 200kBytes of
changes in the datafile between each snapshot. (about 1/1000th of the file has
actually changed between the hot backups) Rsync reports the speedup as somewhere
between 800 and 1000 just as I would expect. This speedup is a number that
accounts only for bytes transferred (or not transferred) -- not real time. When
I time the rsync -av runs and compare to a rsync -W the real run times are
approximately the same. (similar results if I rm the file on the dest and rsync
-av). block checksum and rewrite overhead right? 

In other words -- the 'speedup is 963.22' message really only means that the
'network bytes transferred savings is 963x'.  Over a slow network this might be
proportional to a real run time savings, but on a fast network there might not
be any 'speedup' in the sense of real elapsed time. 

Similar speedup numbers for some 1G database files -- but the real time is 2x
when the destination is there and mostly correct. For this type of data it is
'faster' from a time standpoint to remove the destination file before running
rsync. Not what I would expect. 

eric