NFS will always be slower(seek times) than a locally attached disk, even if
all other interfaces are faster. the locally attached disk will have native
disk seek times while the NFS will have native + network interface + network
card + remote bus. this will take an average seek time from 9ms and
probably double it. for big files this wont be a big deal as the difference
in time will be negledgible but for small files it will be devistating to
performance.
every IP error, every packet collision, every foot of wire will effect
backup times.
Though I am still fairly new to BackupPC, I am extensively experienced with
networking. I suggest you measure transfer times on your local system to a
ramdisk rsyncing your /etc directory over a about 100 times and then do the
same thing rsyncing something to a ramdisk on a remote server mount via
nfs. you will see that on the local system, you can sync that directory to
ram 100 times in around 1 second or maybe even less than that while on the
remote ramdisk it takes up to 3 seconds. this is taking average disk
latency of something like 8ms and reducing it to nanoseconds and still
resulting in a 3 fold increase. imaging the effects of NFS adding full
milliseconds to each file.
as far as putting a monitoring solution on a production server. what is the
point? the monitoring solution likely has a primary goal of instructing you
when a server or disk goes down but if the machine it sits on goes down it
cant tell you. considering that cacti or nagios both use very little
resources and need very little CPU horsepower, i suggest you re-use some
other PC for the task. I put my monitoring solution in another building on
an older dell desktop machine and i have replaced the hard disk with 2 1GB
CF cards in a mirror to make the thing reliable.
On Jan 28, 2008 7:34 AM, <[EMAIL PROTECTED]> wrote:
>
> Yes, in my case it's a Netapp.
>
> Thank you very much.
>
> Romain
>
>
>
> *Les Mikesell <[EMAIL PROTECTED]>*
> Envoyé par : [EMAIL PROTECTED]
>
> 28/01/2008 15:19
> A
> Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
> cc
> backuppc-users@lists.sourceforge.net
> Objet
> Re: [BackupPC-users] Ressources Server (BackupPC + Nagios + Cacti)
>
>
>
>
> Carl Wilhelm Soderstrom wrote:
> > On 01/28 09:15 , [EMAIL PROTECTED] wrote:
> >> Carl, can you explain this idea with more details. Please.
> >> I don't see exactly why it will be worth with this solution.
> >
> > My concern is that sending the data over the wire to a NAS will be much
> > slower than using local disk. There's a lot more operations involved in
> NFS
> > requests and responses; and like I said, BackupPC tends to be disk-speed
> > limited in my experience.
>
> The speed issue is mostly disk-seek related, though, and actual
> operation will depend on the NAS itself. Something like a NetApp can be
> faster than local disks. NFS can be configured for synchronous writes
> where each operation is not considered complete until the server has
> first done a sync to disk. That mode will be much slower than using
> local disks which normally are buffered, but async mode should be
> reasonably fast.
>
>
> --
> Les Mikesell
> [EMAIL PROTECTED]
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>
>
>
> SC2N -S.A Siège Social : 2, Rue Andre Boulle - 94000 Créteil - 327 153
> 722 RCS Créteil
>
>
>
> "This e-mail message is intended only for the use of the intended
> recipient(s). The information contained therein may be confidential or
> privileged, and its disclosure or reproduction is strictly prohibited. If
> you are not the intended recipient, please return it immediately to its
> sender at the above address and destroy it."
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
