> -----Original Message----- > From: Les Mikesell [mailto:[email protected]] > Sent: den 16 oktober 2014 18:09 > To: General list for user discussion, questions and support > Subject: Re: [BackupPC-users] Using NFS to increase backup speed > > > I'm seeing network speeds at about 35-45 Mbps when using BackupPC and rsync > > over ssh. > > > > 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. 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? > > Running iperf below I notice the network should theoretically be capable of > > a bit more than that. I understand that ssh adds quite a bit of bottleneck. > > 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. > > After reading one of the answers at > <<http://serverfault.com/questions/377598/why-is-my-rsync-so-slow>>, I > kinda' wonder if the NFS-angle would work for use with BackupPC and how I > would go about it. Is the tar transfer method the only one supported by BPC > if using NFS for example? > > Rsyncing a NFS-mounted remote host supposedly is a lot faster than doing > rsync over ssh. > > > > Any thoughts on this? > > I'd guess there are too many variables to predict but I'd stick to ssh > because of the forced validation (--ignore-times) on full runs. In > the case that will ultimately matter the most (the third and > subsequent full runs) you can avoid most of the server-side reads if > you used checksum caching but you still have to perform a full read of > the content on the client side. With ssh, that's a local disk access. > with nfs you'll copy every file across the network just so rsync can > compute its block checksum even where everything already matches. Some of the articles mentioned this, but didn't go too much into depth. Your clarification cleared that up. Thanks! -- //Sorin ------------------------------------------------------------------------------ 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 [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
