当我出于个人目的安装图形发行版时，我通常会将其/boot分开/home。
当我安装服务器时，我坚持只安装一个/boot，/并且根据项目的不同，我可能会考虑其他一些需求，正如我提到的这里与/var/log和/var/lib/docker。
基于我正在谈论的 Linux 服务器的前提，似乎存在一种将每个根目录不计后果地分成多个分区的趋势，我不明白为什么。
@Doug O'Neal 已在此声明有多个最佳实践文档（例如 CIS Benchmark）要求将 /var、/home、/usr 等分成不同的文件系统。
在我的研究过程中，我读过本文这为分离分区提供了很好的理由，但对于每个目录来说似乎并没有做得过分。
这其他文章和这里也提到每个目录分区，但没有给出任何理由，只是为了安全起见这样做，盲目地相信他们！
事实上，你可以在挂载时配置不同的标志，如nodev、nosuid 甚至 noexec，但对我来说这似乎并不那么重要，因为如果用户不是 sudoer，简单拒绝写访问就足够了，而如果是 sudoer，这些标志不会防止任何损坏。
事实上，您可以分别备份它们，而不会增加负担。事实上，您可以分别清除它们，您可以简单地删除目录。
事实上，其中一些文件可能有坏块，这让我感到很不放心，因为坏块是由扇区给出的，无论有没有分区，文件都会被损坏。
我能想到的唯一可能有点好处的情况是，如果分区位于分开的磁盘上，并且其中一个分区无法加载或分区表扇区已损坏，但根据情况，无论是否有多个分散的分区，您都无法启动系统。
考虑到最后一种可能性，为了恢复磁盘，无论有一个或多个分区都没有任何区别，您可以运行 testdisk 或 ddrescue 映像，无论如何都会得到相同的结果。
我想知道那些所谓的最佳实践为什么要进行多个分区分离而不考虑哪个适合项目？
答案1
我发现这实际上取决于您要使用的资源、它们现有的配置以及您打算在未来如何工作。如果您仍在使用裸机和本地存储，则进行分区是有意义的，因为您可能需要在物理层进行扩展。您可能没有多余的插槽来放置 RAID 控制器，或者没有足够的 RAM 来在软件中运行 RAID，因此您可以尽力利用您的资源。例如，如果 /home 已满，那么您可以向系统添加另一个磁盘，然后 rsync，然后进入单用户模式，重新同步并重置挂载点。“一体化”是可能的，而且影响可以忽略不计，但我发现这种方式更容易迁移。
出于性能原因，数据库总是倾向于将它们分开 - 将日志放在一个地方，将数据放在另一个地方，如果可能的话，将索引放在第三个位置 - 使用自己的磁盘和控制器！它只是保持数据交易通道畅通。
这主要与空间管理有关。我有一组生产服务器，它们在日志轮换开始之前会生成 100 GB 的日志文件，因为实际上需要这么多信息才能捕获一些扩展的事务数据。（单个“事务”可以触发 10,000 个唯一子任务，所有这些子任务都需要保持完整的事务状态。）如果开发扩展了此要求，我可以选择暂停/停止服务，重新安装新路径并启动 - 而不必移动 100 GB 的日志......
我不能冒险让操作系统因磁盘空间问题而陷入瘫痪，也不能让数据库等待写入操作才能提交，因此我们可以在将来将空间扩展到单独的磁盘（和控制器）。如果我有一个带有大量数据存储的盒子，并且我想将 SSD 用于操作系统和应用程序层，那么混合对我来说是一个可行的选择。同样，与整个磁盘驱动器相比，迁移数据分区最容易。（是的，我确实为此使用了老式的“dd”。）