Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Sep 2016 22:08:53 +0530
From:      Amitabh Kant <>
To:        Matthew Seaman <>
Cc:        "" <>
Subject:   Re: NFS or rsync for sharing files between FreeBSD servers?
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, Sep 7, 2016 at 9:58 PM, Matthew Seaman <> wrote:

> On 2016/09/07 17:09, Amitabh Kant wrote:
> > We need to share a number of directories between 3 servers running 9.3 .
> > Most of these directories contain php/html/js/images files which do not
> > change frequently.
> >
> > We need to keep the directories in sync on all three servers. Currently,
> we
> > run a rsync command every time there is a change in one of the
> > files/directories. Sometimes it does happen that we forget to run the
> rsync
> > script making one of the servers return old versions.
> >
> > That is where we are planning to introduce a nfs_server on one of the
> > servers, while the other two will be nfs_clients accessing the files
> > through a shared directory. I understand that it would present a single
> > point of failure, but in terms of disk access speed, will it make a huge
> > difference further impacting the web servers running on the nfs_client
> > servers ? The servers are connected to each other over gigabit lines, and
> > the files are themselves not greater than 20-30 kb on an average, with
> some
> > of  the larger image files somewhere around 4-5 MB.
> Alternative 1)
> Set up your web servers to proxy and cache the content from one machine
> which is assumed to have the definitive copy.  That will work well with
> plain html, js or images -- but you'll have to be a bit cunning about
> getting the PHP files as raw content and then using them asa PHP
> application.  You'll need to play with the cacheing parameters until you
> achieve a good compromise between discovering updates in a timely
> manner, not continually going back to the origin server and keeping
> locally cached copies considered 'fresh' even if the origin server has
> gone away.
> Alternative 2)
> Use ZFS to make regular snapshots and send any new content to the other
> servers.  This is effectively like using rsync, but even more efficient,
> as ZFS already knows exactly what changed, so you don't have to scan
> bother sender and receiver to work out what changed.
> Alternative 3)
> Simply run your rsync job out of cron regularly.
> Both options 2 and 3 assume you'll set up password-less SSH keys to
> authenticate unattended connections.  This is reasonably safe if a) you
> do it as non-root and ensure the userid you login to has just the
> minimal permissions it needs to be able to fulfil its function and b)
> you take advantage of the features in the authorized_keys file that
> allow you to prescribe where a key can be used to login from, and maybe
> even to use a forced command.
>         Cheers,
>         Matthew
Sounds like we should stick to rsync in a cron job, with a restricted user
and ip bindings in ssh keys.



Want to link to this message? Use this URL: <>