Hey Greg!
On Wed, March 30, 2016 8:13 am, Greg Troxel wrote:
>
> Dominic Raferd <[email protected]> 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
[email protected] www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
rdiff-backup-users mailing list at [email protected]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
