Unix 服务器分区和文件系统布局

Question

互联网上有很多关于 Unix 服务器分区的相互矛盾的信息，所以我需要一些关于如何进行的建议。

到目前为止，在我们测试环境中的服务器上，我并不真正关心分区，我配置了单个整体/和交换分区。这种分区方案对于我们的生产服务器来说似乎不是一个好主意。我在这里找到了一个很好的起点，但在细节上似乎很模糊。

---

基本上，我有一台服务器，我将在该服务器上运行基本的 LAMP 堆栈（Apache、PHP 和 MySQL）。它将必须处理文件上传（最多 2GB）。该系统具有 2TB RAID 1 阵列。

我打算设置：

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

这听起来很理智，还是我把事情复杂化了？

Answer 1

布置分区时要记住的一件事是故障模式。通常这个问题的形式是：“当分区x填满时会发生什么？” 最亲爱的 voretaq7 提出了完全/导致任何难以诊断的问题的情况。让我们看一些更具体的情况。

如果存储日志的分区已满，会发生什么？ 您会丢失审计/报告数据，有时会被攻击者用来隐藏他们的活动。在某些情况下，如果您的系统无法记录他们的登录事件，则您的系统将不会对新用户进行身份验证。

当/var已满时，基于 RPM 的系统会发生什么？ 包管理器不会安装或更新包，并且根据您的配置，可能会静默失败。

填充分区很容易，尤其是当用户能够写入时。为了好玩，运行这个命令，看看你能多快地制作一个相当大的文件：cat /dev/zero > zerofile.

它不仅仅是填充分区，当您将位置放置在不同的挂载点时，您还可以自定义它们的挂载选项。

/dev/未安装时会发生什么noexec？ 由于/dev通常假设由操作系统维护并且只包含经常（有时仍然）用于隐藏恶意程序的设备。离开noexec允许您启动存储在那里的二进制文件。

出于所有这些以及更多原因，许多强化指南将讨论分区作为要执行的首要步骤之一。事实上，如果您正在构建一个新服务器，如何对磁盘进行分区几乎完全是您必须决定的第一件事，并且通常是最难在以后更改的。有一个名为Internet 安全中心的组织，该组织提供了大量易于阅读的配置指南。您可能会找到针对您的特定操作系统的指南，并查看他们可能说的任何细节。

如果我们看一下 RedHat Enterprise Linux 6，推荐的分区方案是这样的：

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

所有这些更改背后的原则是防止它们相互影响和/或限制可以在特定分区上执行的操作。以选项/tmp为例。这意味着不能在那里创建任何设备节点，不能从那里执行任何程序，并且不能在任何东西上设置 set-uid 位。就其本质而言，/tmp几乎总是世界可写的，并且通常是一种仅存在于内存中的特殊类型的文件系统。这意味着攻击者可以使用它作为一个简单的中转点来删除和执行恶意代码，然后崩溃（或简单地重新启动）系统将清除所有证据。由于 的功能/tmp不需要任何该功能，我们可以轻松禁用这些功能并防止出现这种情况。

日志存储位置，/var/log并被/var/log/audit切割以帮助缓冲它们免受资源耗尽的影响。此外，当它的日志存储开始填满时，auditd 可以执行一些特殊的事情（通常在更高安全性的环境中）。通过将其放置在其分区上，此资源检测性能更好。

更详细地说，引用mount(8)，这正是上面使用的选项：

noexec不允许在挂载的文件系统上直接执行任何二进制文件。（直到最近，仍然可以使用 /lib/ld*.so /mnt/binary 之类的命令运行二进制文件。自 Linux 2.4.25 / 2.6.0 以来，此技巧失败。）

nodev 不要解释文件系统上的字符或块特殊设备。

nosuid不允许 set-user-identifier 或 set-group-identifier 位生效。（这看起来很安全，但实际上如果您安装了 suidperl(1) 则相当不安全。）

从安全角度来看，这些是非常好的选择，因为它们允许您对文件系统本身进行保护。在高度安全的环境中，您甚至可以将noexec选项添加到/home. 这将使您的标准用户更难编写用于处理数据的 shell 脚本，例如分析日志文件，但它也会阻止他们执行将提升权限的二进制文件。

另外，请记住，root 用户的默认主目录是/root. 这意味着它将在/文件系统中，而不是在/home.

根据系统工作负载，您为每个分区提供的确切数量可能会有很大差异。我管理的典型服务器很少需要人工交互，因此/home分区根本不需要很大。这同样适用于/var因为它倾向于存储经常创建和删除的相当短暂的数据。但是，Web 服务器通常/var/www用作其游乐场，这意味着它也需要位于单独的分区上或/var/需要变大。

过去，我曾推荐以下内容作为基线。

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

这些需要根据系统的目的以及您的环境运行方式进行审查和调整。我还建议使用 LVM 并反对分配整个磁盘。如果需要，这将允许您轻松地增加或添加分区。

Answer 2

忽略底层 RAID 阵列（有关 RAID 阵列级别以及何时使用它们的更多详细信息，请参阅此问题），让我们专注于您要问的核心问题：
“我应该如何布置 Unix 服务器的文件系统？”

一个巨大的/分区有什么问题？

正如您在问题中所指出的，许多 Linux 发行版（尤其是像 Ubuntu 这样的“桌面”发行版）使用非常简单的文件系统布局：/和[swap].

这种方案具有简单的优点——它非常适合习惯将“硬盘驱动器”作为一个大型整体容器 ( C:\)的家用 PC 的 DOS/Windows 用户，您可以将东西倾倒到其中，而您不必担心关于文件系统空间不足的问题——只要确保您保持在磁盘容量以下，并且一切（至少在理论上）都很好。

不过，单文件系统方案有几个缺点——最常提到的缺点是，当根文件系统填满（到拒绝启动），并且如果一切都在写入/（根）时，Unix 系统往往会做出非常糟糕的反应一个任性的程序或用户可以关闭整个系统。
在系统崩溃和随后的文件系统损坏的情况下，单个大型文件系统也容易完全丢失。

上述问题，加上强烈的组织意识，就是 Unix 服务器通常具有多个文件系统的原因。

你如何分解 Unix 文件系统？

所以希望您确信拥有多个文件系统是有意义的。现在的问题是如何将系统分解为逻辑块，以及如何决定每个块获得多少空间？
答案是您知道并理解您的操作系统将放置什么。这种理解的起点是hier手册页。大多数Unix系统都带有（man hier从Linux系统，并man hier从BSD系统），并加了代码的本地知识，你安装会做会引导您创建一个健全的分区布局。

我将在这里描述一个通用的分区方案，但应该始终修改此方案以满足您的特定需求。

一个通用的 Unix 分区方案

/
    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.

特殊文件系统

/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.

Answer 3

像这样分割文件系统的做法是从没有软件突袭的时代开始的，而且磁盘驱动器很小，所以你必须使用其中的几个，因此，唯一的方法就是将文件系统分解并将不同的目录放在不同的驱动器上。另一个历史原因是这样您就可以轻松卸载分区并将dump其用于备份，而您无法使用根目录进行备份。这个工具现在已经基本上失宠了，甚至可以用于 LVM 快照，甚至是根目录。

几乎没有理由再这样做了。这样做的唯一原因是，例如，如果您想防止/tmp填满整个磁盘。

现在这个原因在很大程度上是无关紧要的，因为向用户提供一般的 shell 访问已经被搁置一旁，而现在服务器运行专用服务，例如 Web 或邮件服务器。由于您没有能够运行任意命令的随机用户，您通常不必担心他们试图填满您的文件系统（即使您这样做了，您也有磁盘配额来阻止它）。

至于使用什么raid级别，您需要记住raid的主要目的不是保护数据（这就是备份的目的），而是维持正常运行时间。如果您/tmp使用raid0，那么您的服务器仍然会出现故障，并且如果其中一个磁盘出现故障，您就必须去修复它。您可能还想使用 raid10 而不是 raid1，以便获得更好的性能。

不破坏文件系统的一个很好的理由是，如果分配错误，尽管其他地方有足够的可用空间，但最终可能会导致部分文件系统已满。纠正这一点可能很困难，除非您使用 LVM 并留下一些未分配的空间。