[Gllug] What are the best practices for Linux partitioning & Mount points for Production systems

Andrew Farnsworth farnsaw at stonedoor.com
Fri Mar 2 09:53:47 UTC 2012


I'll Second this with one caveat.  If you are running an active system that
is generating a lot of logs (read production public facing web/app server)
then you might want a separate partition for /var/log and/or any other log
directories that are in non-standard locations.  My experience is that
invariably you will end up wanting more space for the logs or to tightly
monitor disk space used by the logs and this makes both very simple.

Andy

On Fri, Mar 2, 2012 at 10:45 AM, Tethys <sta296 at astradyne.co.uk> wrote:

>
> nk oorda writes:
>
> >What are the best practices for Linux partitioning & Mount points for
> >Production systems
>
> I generally go for:
>
> - /boot (ext3, about 1GB)
> - /boot2 (ext3, about 1GB)
> - LVM for the rest of the "disk" (which is usually an array
>  rather than a single disk)
>
> The two /boot filesystems allow distribution upgrades with rollback.
> LVM gives you the flexibility to do what you want with the rest.
> It's less important than it used to be, and there's an argument for
> just sticking the rest of the OS on a single filesystem, but personally
> I still go for separate /usr, /tmp and /var. The latter two prevent the
> system falling over as badly when a rogue process spams the disk with
> crap, and I have a read only /usr (which I haven't managed to achieve
> at boot time with bind mounts, despite the claims accompanying the
> misguided removal of support for a separate /usr in recent Fedora
> releases).
>
> Tet
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20120302/837314bc/attachment.html>
-------------- next part --------------
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug


More information about the GLLUG mailing list