Linux生产环境磁盘挂载点设计需按用途分离、遵循FHS规范，推荐使用语义化路径如/var/log、/mysql/data、/srv/www等，并通过UUID在/etc/fstab中稳定挂载，避免设备名漂移风险。
Linux 生产环境的磁盘挂载点设计，不是随便选个目录 mkdir /data 就完事的。它直接关系到系统可维护性、故障隔离能力、扩容灵活性，甚至数据安全。一个合理的挂载点结构，能让运维更省心，让应用更稳定，也能在磁盘故障或容量告警时快速定位和响应。
核心原则就一条：按用途分离，而非按设备堆砌。
别把所有业务数据都塞进 /data，也别因为有三块硬盘就硬凑出 /data1、/data2、/data3 —— 这种命名暴露的是硬件拓扑，不是业务逻辑，一旦换盘、扩容或迁移，配置就得重写。
挂载点应体现业务语义，而不是物理位置
生产环境推荐按服务角色划分挂载点，例如：
-
/var/log→ 专用于系统及应用日志 -
/var/lib/mysql或/mysql/data→ MySQL 数据文件（不建议挂整个/var/lib，而应细化到具体服务） -
/opt/app→ 第三方或自研应用的安装与运行目录 -
/srv/www→ Web 服务静态资源或站点根目录（符合 FHS 规范） -
/home→ 用户主目录（如需独立存储，避免与系统盘耦合） -
/backup→ 定期备份目标（独立挂载便于快照、归档或异地同步）
这些路径不是随意定的，它们对应 Linux 文件系统层次结构标准（FHS），多数发行版和服务默认遵循。用标准路径，等于降低团队认知成本，也减少因路径不一致导致的权限、SELinux 或容器挂载问题。
关键挂载点必须独立，避免根分区被撑爆
根分区（/）只放操作系统核心文件。以下目录一旦写满，极易引发系统级故障：
-
/var/log：日志滚动失控、审计日志未轮转 →systemd-journald卡死、rsyslog停摆 -
/var/lib：Docker 镜像层、PostgreSQL 数据、Prometheus TSDB → 磁盘满导致容器无法启动、数据库只读甚至崩溃 -
/tmp和/var/tmp：临时文件堆积（尤其 Java 应用生成大量 tmp）→ 影响编译、上传、解压等操作
✅ 正确做法：为上述目录单独挂载独立磁盘或 LVM 逻辑卷，并设置合理配额或监控告警。
❌ 错误做法：把 /var 整体挂到一块盘上，结果 PostgreSQL 日志和 Docker 共用空间，互相挤占。
挂载点命名要可读、可扩展、无歧义
- 避免模糊名称：
/disk1、/mnt/new、/data—— 它们不说明“存什么”，也不说明“给谁用” - 推荐命名方式：
- 按服务：
/mysql/data、/redis/dump、/kafka/logs - 按用途：
/app/config、/app/upload、/app/cache - 按生命周期：
/archive/year2024（归档专用）、/scratch（临时计算空间）
- 按服务：
命名中尽量不含版本号、环境标识（如 prod、dev），这些信息应通过配置管理（Ansible/Consul）或容器标签表达，而非挂载路径本身 —— 路径稳定，才利于脚本复用和监控统一。
配置自动挂载时，必须用 UUID，且验证再重启
/etc/fstab 中的每一行，都该是这样的格式：
UUID=12345678-90ab-cdef-1234-567890abcdef /mysql/data xfs defaults,noatime,nobarrier 0 2
- 第一列必须是
UUID=开头（不是/dev/sdb1） - 第二列是已创建好的空目录（
mkdir -p /mysql/data） - 第三列填实际文件系统类型（
xfs、ext4、btrfs），别猜 - 第四列挂载选项建议加
noatime（减少元数据写入）、nobarrier（SSD 可选，需确认硬件支持） - 最后两列：
0表示不参与dump备份；2表示非根分区，fsck顺序靠后（根为1）
配置完务必执行：
sudo mount -a # 测试 fstab 语法和挂载可行性 sudo lsblk -f # 确认 UUID 与挂载点匹配 df -h /mysql/data # 检查是否真实挂载且空间正常
别跳过这步 —— 很多线上事故，就发生在 mount -a 报错但没人检查，重启后直接进 emergency mode。
不复杂但容易忽略。
