How many and which partitions should I create for a linux server?

Planning a good partitioning structure is heavily dependent on actually knowing how you are going to use the 'server'. Any random advice that doesn't take the actual services that will be provided isn't going to be particularly useful.

For example if it is a debian-based box that will be used for mysql you might want a seperate partitions for /,/var, and /var/lib/mysql.

Is it going to be a file server with lots of shared storage? You might want a /, /home, and /srv partitions.

For a box running only squid, you might want on partition for /, and one partition on a fast disk for the squid spool.

As you are planning your partitions it is very helpful to have a good understanding of the Filesystem Hierarchy Standard and if/how your chose distro deviates from the standard.

Using LVM can make it much easier to change your mind in the future and adjust your partitions without having to reboot., and its ability to create snapshots can be very easy to create good backups.

I always create these partitions, and as of the last year, always on LVM:

/       - a few Gig
/usr    - 24 Gig and mostly empty
/var    - 4 Gig works for me, YMMV
/home   - depends on how many users you will have

One of the most important is /var -- if this is a separate partition, then when it fills up, you will not crash your root partition. Although I have never done this, some make a separate /usr so that they can mount it read-only.

and I sometimes create these partitions:

/boot   - even 1 Gig is way more than enough

The reasoning is that it's not always possible to boot from a RAID or LVM partition. Thus, /boot can be a simple ext3 partition, allowing / to be more advanced.

If I will have a large number of large files, I will sometimes create a specific partition for these large files so the filesystem can be tweaked to be efficient at storing large files. Some people, if they will be serving NFS from a server, will create a separate partition for their NFS shares or even a separate partition for each NFS share. This depends on your needs.

Why LVM? As I've mentioned in answers elsewhere but forgot to mention here, it makes it a LOT easier to change your mind later and expand a partition. This has saved my butt already.

These are general guidelines. Of course, I expect that if your server has special needs, you'll take that into account and make partition reflecting these needs.

Assuming that you're building a machine that's going to last a while, would be inconvenient to rebuild, and needs to be pretty flexible, you might like a scheme similar to the following:

1. Install a minimum of two physical drives, the same size; for the purposes of this example, I'm going to assume 500GB SATA drives, but the principles work just fine with other sizes of drive.

2. Partition each drive as follows:

   /dev/sda1   500MB
   /dev/sda2   100GB
   /dev/sda3   the rest
   

   The goal is to have a dinky 500MB partition up front, a sizeable partition in the middle for the OS and applications, and the bulk of the drive at the back for additional data.

3. Build a SW RAID 1 set, /dev/md0, from /dev/sda1 and /dev/sdb1; build additional SW RAID 1 sets /dev/md1 and /dev/md2 from the corresponding paritions.

4. Format /dev/md0 as ext3; this will be /boot.

5. Format /dev/md1 and /dev/md2 as LVM physical volumes.

6. Create a LVM volume group, vg_system, which contains /dev/md1.

7. Create appropriate LVM volumes inside vg_system for your various OS partitions; at the very least, you'll want swap, /var of a couple GB, and / of 10GB or so. NOTE: do not allocate all of vg_system! When you later decide that you want to increase the size of \var, or you want to add an /opt or whatnot, then you'll want that additional space.

8. Create a LVM volume group, vg_data, which contains /dev/md2.

9. Create LVM volumes inside vg_data as desired; at the very least you'll want a sizeable /home, and you may want additional volumes for, say, mail spools, or databases, or web roots, or any other data that isn't part of the OS. Again, don't allocate all of vg_data, for reasons similar to the ones listed above.

The advantages of this strategy include the following:

• It's tolerant of hardware failures; either drive can fail without causing a system failure, and if you invest in a hot-swap controller, you can recover without downtime.

• It's future-proof and expandable; when you buy 2TB drives a few years down the road, you can slap them into the machine, make them into another SW RAID set, format it as an LVM physical volume, add it to whichever volume group needs more space (probably lv_data), then use pvmove to migrate your data off the old drives and onto the new. In addition, major OS updates can be rendered significantly less painful; if you need to reinstall the OS for a major upgrade (ahem Red Hat :( ), you can do so while preserving home directories (and mail spools and whatever all else you put in vg_data).

The disadvantages of this strategy are few; I suppose it's a bit complex, and you do take a performance hit on writes because of the RAID 1. However, I've been building workstations and standalone servers according to these principles for some years now, and in my experience every time I don't build a machine along these lines, before long I wish I had.

-steve

P.S. I should add that if you have the infrastructure in place to quickly and painlessly provision a new machine, then a system like this is overkill; rather than tinkering with RAID sets and LVM, just rebuild the machine if you need something changed.

For years every computer I've used has been a dual boot system, and on the Linux side I pretty much stuck with this schema (I'm talking personal workstations here, no server stuff, so your mileage might vary)

/     - main thing
/boot - not that relevant, since cylinder being < 1024 and 
        exotic filesystems are no longer an issue
/home - handy if you upgrade your laptop with each new distro :-)

For my last upgrade I did an install from scratch, wiping out my / partition. That made me think a separate /opt or /usr/local partition would have been nice, sparing me the hassle of reinstalling all the stuff I put in there (java, eclipse... I usually don't care for the distro packaged ones).