Rsync 3.0.0 report and a performance question.
langelino at gmx.net
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?
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
>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