BackupPC-users

Re: [BackupPC-users] Using NFS to increase backup speed

2014-10-17 08:56:43
Subject: Re: [BackupPC-users] Using NFS to increase backup speed
From: Les Mikesell <lesmikesell AT gmail DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Fri, 17 Oct 2014 07:55:07 -0500
On Fri, Oct 17, 2014 at 5:38 AM, Sorin Srbu <Sorin.Srbu AT orgfarm.uu DOT se> 
wrote:
>>
>> That sounds pretty good.  But unless you have a lot of new files
>> created daily, the bottleneck is usually disk speed, especially
>> merging a lot of small changes into a big existing file.
>
> Not too many new files daily, the reading is done from a three- or four-disk 
> raid0-array, so should be fairly fast I guess.

Do you have a problem completing backups in the time available?   And
if so, with all incrementals or just fulls?   Without checksum
caching, the server side will have to read and uncompress everything
for the full comparison.   With it, after the second full that
includes a file, only the client side has to do the read.   But in
either case, the really slow operation is when a large existing file
has a lot of small random changes.  For that, the server has to
uncompress the old file and create a new copy, merging in the changes
from the remote so it may involve a lot of disk seeking.

> The 35-45 Mbps mentioned above is a pretty rought figure I think. I took it 
> from the netspeed Gnome applet. The numbers I posted just earlier are 
> probably more exact(ish).
>
> But you think this speed is what you'd expect from a setup with a gigabit 
> switch, gigabit-NICs on both ends and CPU:s (BPC: single-core Athlon64 3500+, 
> host: Intel core 2 Quad Q8200@2,33 GHx) a few years old then?

Backuppc rarely loads the network using rsync except on the initial
copy.  The point of rsync is to only copy changed data.  In fact I
usually add a --bwlimit to the rsync args to constrain it to be sure
it won't bother any other network traffic.

>> There is some overhead for encryption.  Back when cpus were slow
>> enough for it to matter I used to set blowfish as the preferred
>> cipher.  Now you probably want aes-128 where you have hardware
>> support.
>
> Would aes-128 be faster than arcfour, roughly speaking?
>
> I'll need to give aes-128 a go as well it seems.

I think this depends on the ssh version and the processor type
involved as to whether uses hardware support and how much it helps.

-- 
  Les Mikesell
     lesmikesell AT gmail DOT com

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/