Разделение сервера Unix и расположение файловой системы

Depending on your architecture - you may not want to actually use /tmp as it's cleared out after every reboot. If your site deals with eventual processing of uploads, changing this to another location (via php.ini) may be an idea; in which you can make it any mount point.

As suggested earlier, it's highly recommended to use LVM and increment as needed.

I'd also highly recommend a dedicated partition for MySQL data (you can still mount it under /var/lib/mysql).

Ignoring the underlying RAID array (See this question for more details about RAID array levels and when you want to use them), let's concentrate on the core question you're asking:
"How should I lay out my Unix server's fileystems?"

What's wrong with one giant / partition?

As you noted in your question, a lot of Linux distributions (especially the "Desktop" distributions like Ubuntu) use a very simple filesystem layout: / and [swap].

This scheme has the advantage of simplicity -- it's great for DOS/Windows users who are used to their home PC with "the hard drive" as one big monolithic container (C:\) into which you dump stuff, and you don't have to worry about running out of space on filesystems -- just make sure you stay under the disk's capacity and everything is (at least theoretically) fine.

The single-filesystem scheme has several disadvantages though - the most often cited disadvantage is that Unix systems tend to react very badly when the root filesystem fills up (to the point of refusing to boot), and if everything is writing to / (the root) one wayward program or user can take down the whole system.
A single large filesystem is also prone to being a total loss in the event of a system crash and subsequent filesystem corruption.

The issues above, plus a strong sense of organization, is why Unix servers typically have multiple filesystems.

How do you break up the Unix filesystem?

So hopefully you're convinced that having multiple filesystems makes sense. The question now is how do you break the system up into logical chunks, and how do you decide how much space each gets?
The answer is you know and understand what your operating system is going to put where. The starting point for that understanding is the hier man page. Most Unix systems come with (man hier from a linux system, and man hier from a BSD system), and that plus your local knowledge of what the code you are installing is going to do will guide you in creating a sane partitioning layout.

I am going to describe a general partitioning scheme here, but this scheme should always be modified to meet your specific needs.

A General Unix Partitioning Scheme

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Special Filesystems

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

The practice of carving up the filesystem like that is from the days when there was no software raid, and disk drives were small, so you had to use several of them, and thus, the only way to do that was to break the filesystem up and put different directories on different drives. The other historical reason for it was so that you could easily unmount a partition and dump it for backup, which you could not do with the root. This tool has largely fallen out of favor these days and can instead be used on an LVM snapshot even on the root.

There is little to no reason to do this any more. About the only reason left to do this is if you want to, for instance, prevent /tmp from filling up the whole disk.

This reason is largely irrelevant these days because provding users with general shell access has gone by the wayside, and these days servers run dedicated services, such as web or mail servers. Since you don't have random users able to run arbitrary commands, you generally don't need to worry about them trying to fill up your filesystem ( and even when you did, you had disk quotas to stop that ).

As for what raid level to use, you need to remember that the main purpose of raid is not to protect data ( that's what backups are for ), but to maintain uptime. If you put /tmp on a raid0, then your server would still go down and you'd have to go repair it if one of the disks fail. You also might want to use raid10 instead of raid1 so you get better performance as well.

A very good reason NOT to break up the filesystem is that if you get the allocations wrong, you can end up with part of the filesystem being full despite there being plenty of free space elsewhere. Correcting this can be difficult, unless you use LVM and left some unassigned space.

Большая часть информации о разделах была создана, когда на диске не хватало места. В результате вы увидите относительно небольшие разделы для ряда случаев. Требуемые размеры разделов зависят от использования сервера. Наиболее изменчивыми являются / tmp , / var , home , / opt и / srv . . / usr обычно имеет разумный и стабильный размер. Пространство для / может включать в себя любые или все другие разделы и их требования к пространству. Размер действительно зависит от того, что вы делаете в системе.

Я бы увеличил swap и смонтировал / tmp на tmpfs . Затем вы / tmp будете использовать своп в качестве резервного хранилища, но использовать память по мере доступности. Размер вашего / tmp выглядит очень большим, но он будет обрабатывать прерванную загрузку, которая не очищена.

Я бы подумал о перемещении файлов MySQL в / srv . Это относительно новый уровень в иерархии дисков.

Если вы не знаете своих конечных требований, подумайте об использовании LVM и расширении разделов по мере заполнения.