cut-off time for rsync ?

[Dirk van Deun]

> >I used to rsync a /home with thousands of home directories every
> >night, although only a hundred or so would be used on a typical day,
> >and many of them have not been used for ages.  This became too large a
> >burden on the poor old destination server, so I switched to a script
> >that uses "find -ctime -7" on the source to select recently used homes
> >first, and then rsyncs only those.  (A week being a more than good
> >enough safety margin in case something goes wrong occasionally.)
> 
> Doing it this way you can't delete files that have disappeared or been
> renamed.
> 
> >Is there a smarter way to do this, using rsync only ?  I would like to
> >use rsync with a cut-off time, saying "if a file is older than this,
> >don't even bother checking it on the destination server (and the same
> >for directories -- but without ending a recursive traversal)".  Now
> >I am traversing some directories twice on the source server to lighten
> >the burden on the destination server (first find, then rsync).
> 
> I would split up the tree into several sub trees and snyc them
> normally, like /home/a* etc. You can then distribute the calls
> over several days. If that is still too much then maybe to the
> find call but then sync the whole user's home instead of just
> the found files.

As I did say in my original mail, but apparently did not emphasize
sufficiently, rsyncing complete homes if anything changed in them is
actually what I do; so files that have been deleted or renamed are
handled correctly.  Anyway, the first paragraph was just to provide
some context: my real question is: can you specify a cut-off time
using rsync only, meaning that files are ignored and directories are
considered up to date on the destination server if they have not
been touched for x days on the source ?

Dirk van Deun
-- 
Ceterum censeo Redmond delendum