Yes if rsync could keep a 'last state file' that'd be great, which would
require the target be unchanged by any other process/usage - this is however
the case with many of our uses here - as a backup only target.

Then it could just load the target statefile, and only scan the source
for changes vs the last-state file. 

Cant think of any way around this issue with rsync alone without some external
parsing of previous logs, etc. 

This is unfortunately why I never use 5400/5900 rpm disks on my backup targets,
and use raid 10 not 5, for speed. Little more $ in the end, but necessary
to scan 50-80M inodes per night in my ~6hr backup window.


On Thu, Jul 02, 2015 at 11:43:37AM +0200, Dirk van Deun said:
  >> What is taking time, scanning inodes on the destination, or recopying the 
  >> backup because of either source read speed, target write speed or a slow 
  >> between them?
  >It takes hours to traverse all these directories with loads of small
  >files on the backup server.  That is the limiting factor.  Not
  >even copying: just checking the timestamp and size of the old copies.
  >The source server is the actual live system, which has fast disks,
  >so I can afford to move the burden to the source side, using the find
  >utility to select homes that have been touched recently and using
  >rsync only on these.
  >But it would be nice if a clever invocation of rsync could remove the
  >extra burden entirely.
  >Dirk van Deun
  >Ceterum censeo Redmond delendum

Ken Chase - skype:kenchase23 +1 416 897 6284 Toronto 
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front 
St. W.
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options:
Before posting, read:

Reply via email to