服务器重启后，网站突然找不到上传文件，应用却还能向 /data 写入；用 df -h 查看，又少了一块原本存在的数据盘。这时，目录还在不代表数据盘已经挂载。应用可能正在把新文件写进系统盘上的同名目录。
处理这类故障，要先确认云盘是否仍连接、系统能否识别原文件系统，再检查挂载配置。不要对“看起来空了”的磁盘执行格式化，也不要直接把新旧目录合并。 挂载缺失、设备丢失和文件系统损坏，需要走不同的处理路径。
以下适用于使用 systemd 的常见 Linux 发行版，以及已有 ext4、XFS 等本地文件系统的数据盘。示例使用 /data 和 myapp.service，实际操作前须替换为自己的路径与服务。LVM、加密卷、RAID、网络文件系统还涉及各自的激活或网络依赖，不能只照抄一行 fstab。
先确认 /data 是目录，还是独立挂载点
先暂停向该路径写入的应用、队列任务和备份作业。停止服务可能影响业务，应在维护窗口执行，并检查是否还有其他进程持有文件。
# myapp.service 为示例，替换成实际服务
sudo systemctl stop myapp.service
findmnt --mountpoint /data -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt --target /data -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /data
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
两个 findmnt 命令回答的问题不同：--mountpoint 检查 /data 本身是否为挂载点；--target 查找包含该路径的文件系统。如果前者没有输出，后者显示根分区，说明 /data 当前只是系统盘上的目录。df -hT /data 同样可能显示根分区，不能凭它有输出就判断数据盘正常。[1]
部分旧版本 lsblk 没有 MOUNTPOINTS 列，可改用 MOUNTPOINT。如果数据盘已经正确挂载，只是应用读不到文件，应转查目录权限、应用路径、容器卷映射或 SELinux，不要继续重复挂载。
系统里找不到盘时，修改 fstab 没用
结合云平台控制台、lsblk 和内核日志，确认容量、分区、UUID 与原盘一致。设备名可能随启动顺序变化，/dev/sdb1 今天对应的设备未必与之前相同。
sudo blkid
sudo journalctl -b -k --no-pager
常见分支可以这样判断：
| 观察结果 | 接下来检查什么 |
|---|---|
| 控制台显示云盘未挂载到实例，系统中也没有设备 | 实例与云盘的连接关系、区域和平台操作记录 |
| 能看到磁盘，预期分区或逻辑卷未出现 | 分区结构、LVM 激活、加密卷解锁或 RAID 状态 |
| UUID 与配置不一致 | 是否接错盘、换盘、重建文件系统或从快照克隆 |
| 日志出现 I/O error、文件系统错误 | 停止继续写入，评估快照、备份及离线检查 |
| UUID 正确、设备存在，但没有挂载记录 | 检查 fstab、挂载单元及本次启动日志 |
blkid 没有输出不构成“空盘”的证据。不要用 mkfs 验证磁盘能否使用，也不要对已挂载文件系统运行修复命令。出现底层 I/O 故障时，反复挂载可能扩大影响，应优先保全数据并联系存储提供方。
核对 fstab：UUID、路径、类型都要对应
先备份配置，并保留一个可用 SSH 会话。修改启动相关配置前，还应确认可以进入云控制台或救援环境。
sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%Y%m%d-%H%M%S)
cat /etc/fstab
sudo findmnt --verify --verbose
findmnt --verify 用于检查 fstab 的可解析性和可用性，不会替你完成实际挂载，也不能保证重启后的存储设备必然就绪。
fstab 的六个字段依次为：设备来源、挂载点、文件系统类型、挂载选项、dump 标记、启动检查顺序。普通 ext4 数据分区可以参考下面的结构，但必须把占位符换成 blkid 查到的真实 UUID：[2]
UUID=REPLACE_WITH_REAL_UUID /data ext4 defaults 0 2
不要把 ext4 示例用到 XFS 上。XFS 应填写实际的 xfs 类型，最后一列通常使用 0；检查与修复方式也不同。fstab 中含空格的路径需要按手册转义，生产环境尽量采用简单、固定的挂载目录。
UUID 能避免多数设备名漂移问题，但克隆盘可能保留相同 UUID。若两块盘同时连接且标识重复，应先辨明来源，再决定设备标识和迁移方案。此时仅靠 UUID 也无法安全选盘。
nofail 是否应该加？
nofail 允许系统在该挂载失败时继续启动；它不会修好挂载，也不会阻止应用写入根盘上的同名目录。systemd 对配置了 nofail 的挂载，默认启动依赖和顺序处理也有所不同。[4]
可有可无的归档盘，与数据库或应用必须依赖的数据盘，处理策略应有区别。若希望操作系统在数据盘故障时仍可远程登录，可以保留 nofail，但依赖该盘的服务必须单独设置启动约束，并测试失败行为。不要把删掉错误项或添加 nofail 当成数据已经恢复。
挂载前，处理同名目录里新写入的文件
假设 /data 目前未挂载，应用已经写入新文件。将原数据盘直接挂到这里，会把这些新文件遮在挂载点下面：文件没有自动删除，但平常通过 /data 看不到，系统盘空间也仍被占用。
确认所有写入已经停止后，记录目录大小、文件时间和业务用途。对重要文件先做独立备份，并确认备份目标有足够空间。不要一边挂载、一边运行自动同步任务。
一种可选做法是：在确认 /data 确实不是挂载点、没有进程占用、也没有其他服务依赖旧目录之后，把整个目录改名留存，再重建空挂载点。该操作会改变路径，不能在业务仍运行时执行。
# 仅适用于已确认未挂载、无占用的普通目录
sudo mv /data /data.rootfs-hold-$(date +%Y%m%d-%H%M%S)
sudo mkdir /data
这一步只留存系统盘上的现有目录，没有完成异地备份。确认旧目录保存位置后，再验证配置并挂载单个目标，减少对其他挂载项的影响：
sudo systemctl daemon-reload
sudo findmnt --verify --verbose
sudo mount /data
findmnt --mountpoint /data -o TARGET,SOURCE,FSTYPE,OPTIONS
mount /data 会按 fstab 查找对应项。遇到错误时保留完整报错，结合本次启动日志定位。不要反复运行 mount -a 试运气，它可能同时触发其他条目。
挂载成功后，应对照真实设备、UUID、目录结构和备份记录确认这是预期数据盘，再按业务要求核对属主与权限。留存目录里的新文件要逐项比较版本、业务记录和冲突，安排受控合并；数据库文件不能用普通文件覆盖方式随意拼接。
给依赖数据盘的服务补上启动约束
数据盘恢复后，还要避免下一次启动时应用抢先写入空目录。对直接由 systemd 管理的应用，可使用 drop-in 配置：
sudo systemctl edit myapp.service
填入以下内容：
[Unit]
RequiresMountsFor=/data
ConditionPathIsMountPoint=/data
RequiresMountsFor= 会为访问该路径所需的挂载单元添加 Requires 和 After 依赖。[3] 但如果该路径根本没有配置独立挂载，它也可能只依赖根文件系统，因此这里额外使用 ConditionPathIsMountPoint= 检查 /data 本身。条件不满足时服务会跳过启动，需从状态和日志中识别，不能只看是否显示 failed。
ConditionPathIsMountPoint= 自 systemd 244 起提供，部署前用 systemd --version 确认版本，并检查日志是否存在未知配置项；旧版本需另行设计启动前校验，不能认为条件已生效。
该条件只判断“是不是挂载点”，不会核验“是不是正确的那块盘”。它也不是运行期间磁盘失效的完整防护方案。对数据库和重要应用，还应监控挂载来源、磁盘健康与业务读写状态。
sudo systemctl daemon-reload
sudo systemctl cat myapp.service
sudo systemctl start myapp.service
sudo systemctl status myapp.service --no-pager
sudo journalctl -b -u myapp.service --no-pager
Docker 自动重启的容器、计划任务、其他守护进程不会因为修改这个示例服务就自动受到保护。应查明实际启动入口，在相应单元或编排层设置依赖；给整个 Docker 服务添加约束会影响其他容器，需要单独评估。
恢复完成，要验收哪些结果
正式恢复流量前，至少检查：
/data是独立挂载点，来源 UUID、文件系统类型、容量与预期相符。- 应用可用自身账号完成必要的读取与受控写入，日志没有权限或只读错误。
- 系统盘上留存的新文件已清点，有明确的合并、保留和清理计划。
- fstab 检查通过，实际挂载成功，服务启动依赖已生效。
- 已确认备份及控制台救援入口可用，并安排维护窗口验证重启后的状态。
不要在高峰期用“重启试试”代替验收。重启测试应在配置检查、单目标挂载和业务验证通过后进行，并准备回退。回退时可从事先记录的备份路径恢复 fstab、撤销本次新增的 drop-in 配置，再执行 daemon-reload；不要删除原有的其他服务配置。卸载数据盘或切换回留存目录前，必须再次停止写入并检查占用。
如果正确挂载后仍没有预期数据，应保持应用停止写入，继续核验盘的身份、快照与备份。能正常挂载只能说明文件系统可访问，不能证明它就是原来的业务数据。
参考资料
资料核验日期：2026 年 10 月 22 日。命令为操作示例，本文未声称在读者的生产环境完成测试。