[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] rdiff-backup performance -- slow operation on i

From: Derek Atkins
Subject: Re: [rdiff-backup-users] rdiff-backup performance -- slow operation on initial backup?
Date: Wed, 30 Mar 2016 12:15:36 -0400
User-agent: SquirrelMail/1.4.22-14.fc20

Hey Greg!

On Wed, March 30, 2016 8:13 am, Greg Troxel wrote:
> Dominic Raferd <address@hidden> writes:
>> It doesn't sound like rdiff-backup is the culprit here. You could try
>> hpn-ssh https://sourceforge.net/projects/hpnssh/ ?
> I would be very surprised if normal people have networks available that
> really need hpn-ssh, and 2 MB/s is not that fast.  urely rsync and
> rdiff-backup are running over ssh, so that should have the same
> transport properties.

Indeed.  Like I said using scp I see 5+ MB/s with the same data set.  Just
using dd over ssh I get 7.   But yes, rsync and rdiff-backup are giving me
the same transport properties.  The fact that it's taking 36-40 hours to
backup a system does not give me confidence in the ability (or timeliness)
to restore!

> I would up the send/receive socket buffers (because it's easy, not
> because I think that's the problem), and watch disk/cpu on both sides,
> and also run netstat to see if data is piling up in the transmit socket
> buffer.

Do you mean within rdiff-backup, or at some other level?

I've already tried increasing the blocksize and conn_blocksize numbers in
Globals.py but didn't see any performance difference.

> FWIW, I used to use rdiff-backup but found it to be nonrobust on
> machines with limited (only a few GB) RAM and hundreds of GB of backup.
> I have switched to bup.

Unfortunately bup is not available on all my target platforms.

Maybe I should consider amanda or bacula?


       Derek Atkins                 617-623-3745
       address@hidden             www.ihtfp.com
       Computer and Internet Security Consultant

reply via email to

[Prev in Thread] Current Thread [Next in Thread]