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

[Derek Atkins]

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

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