ext4 数据盘怎么挂载：UUID、fstab 与重启前验证
数据盘从“系统能识别”到“应用可以长期使用”，还需要明确挂载位置和启动时行为。本文以 Ubuntu 24.04、一块已经确认含有正常 ext4 文件系统的数据盘为前提。操作前已核对磁盘身份并保留数据备份，本篇不创建分区、不格式化，也不用于来源不明或疑似损坏的磁盘恢复。
核对文件系统和唯一标识
在服务器使用 lsblk -f、sudo blkid 和 findmnt 对照实际设备，确认目标的类型确实为 ext4，并记录 UUID 与设备路径。不要把整盘 UUID、分区标识和文件系统 UUID 混用。
克隆磁盘可能带来重复 UUID，遇到重复值应先处理身份冲突，不能继续假设 UUID 一定唯一。设备名会随环境变化，使用核实的 UUID 有助于保持配置稳定，但仍需要变更记录支持。
挂载目录必须先检查内容
示例使用 /srv/data-demo。先确认该目录不是其他挂载点，也不包含现有业务文件；如果目录已有内容，挂载后这些内容会暂时被新文件系统遮住，并不等于已经迁移到新磁盘。不能为了让目录“变空”直接删除现有数据。
确认路径未使用后创建空目录，记录原有权限。应用要把数据放入新磁盘，应另行安排停写、复制、校验和切换流程。挂载只是连接文件系统到目录树，不会自动移动旧目录里的文件。
为 fstab 写入明确的一条记录
先备份 /etc/fstab，保留管理会话和控制台入口。使用编辑器增加一条记录，替换下面的占位 UUID：
UUID=实际文件系统UUID /srv/data-demo ext4 defaults 0 2
不要复制其他服务器的 UUID，也不要重复添加同一个挂载目标。各字段依次描述来源、目录、类型、选项以及相关检查设置；具体含义见fstab 手册。这里采用普通 ext4 数据盘示例，不代表加密、网络文件系统或集群存储也使用同样设置。
是否使用 nofail 要结合业务依赖判断。它允许某些挂载失败不阻断启动，但应用可能随后把数据写进底层空目录，造成“盘没挂上但业务仍在写”的隐患，不能作为消除启动报错的万能选项。
重启前先验证并只挂目标目录
在服务器逐条检查：
sudo findmnt --verify --verbose
sudo systemctl daemon-reload
sudo mount /srv/data-demo
findmnt -M /srv/data-demo
df -hT /srv/data-demo
findmnt --verify 校验 fstab 的可解析性与相关信息，不等于已经完成真实挂载测试。随后按目录执行 mount，会根据 fstab 选择该条记录；本篇不要求用一次全局挂载来改变其他文件系统。findmnt 手册说明了验证和挂载点查询方式。
核对实际来源 UUID、文件系统类型和容量，再以应用实际运行身份测试授权目录中的读写。不要直接在磁盘根目录递归修改所有文件的属主，已有数据的身份关系可能属于其他服务。
将业务依赖和回退安排写清楚
关键服务应在目标挂载可用后才启动。systemd 管理的应用可以根据实际结构使用挂载依赖设置，但需要结合服务定义验证，不能仅依赖“目录存在”。目录存在与数据盘已经挂上是不同条件。
需要重启验收时，在维护窗口完成，启动后再次核对 findmnt 与应用数据位置。若 fstab 修改错误，先恢复备份并重新加载配置；已经挂载且被程序使用的数据盘不能随意卸载，应先停用相关写入并确认占用。
挂载成功后产生的新数据，也要纳入备份和迁移计划。回退到旧路径时必须处理这些新增写入，不能只撤销一行 fstab 就认为业务数据自动回到了原处。把挂载、应用配置和数据切换作为三个可核对步骤，后续维护才不会相互混淆。