Rsync 3.0.0 report and a performance question.

langelino langelino at
Sat Feb 10 06:30:11 GMT 2007

During more testing along your suggestions I realized that I had
included the rotation of my backup trees in my rsync timing. Turns out
the  rm  -r  command  to delete the oldest back tree was taking the most
time  (9 out of 12-14 min).  This begs the question if one cannot
recycle the oldest backup instead of removing it.

rsync -ax --del  --link-dest=/path/to/latest_backup remote::module

almost does this except that it may mess up attributes of
files/directories in other linked backups because it regards attributes
as malleable, as noted in the man pages.  While I may be able to  live
with this, I am wondering if  there is a way to tell rsync not to change
attributes but create new files in such circumstances?

... Matt

Wayne Davison wrote:

>On Fri, Feb 09, 2007 at 01:57:22PM -0800, Wayne Davison wrote:
>>If there are a large number of files to transfer, the win won't
>>really be that much, as the generator will be waiting around for new
>>file-list info a lot, and that data channel will be clogged up with
>>file data.
>In this context "files to transfer" was supposed to mean "files that
>need to be updated".  (I assume it was obvious that my earlier typo of
>"turning" was supposed to be "tuning", but I'll mention that too.)

More information about the rsync mailing list