Linux服务器重启后分区挂载失效，如何检查并修复fstab配置？

重启后发现 /data、/backup 等目录仍然存在，但目录内没有预期文件，或者 df -hT 中看不到对应分区，通常不是目录被删除，而是 /etc/fstab 中的设备标识、文件系统类型、挂载点或挂载参数没有正确生效。常见原因包括 UUID 已变化、fstab 行格式错误、挂载点不存在、同一挂载点存在多条冲突配置，以及 systemd 在启动阶段生成的挂载单元报错。

排查时应先确认分区是否被系统识别，再核对 /etc/fstab，随后用低风险命令验证语法和设备映射，最后才进行单独挂载或文件系统检查。修复配置后，不要直接重启验证，应先执行 findmnt、mount -a 和日志检查，确认手动挂载成功，再安排重启复测。

一、先确认是“未挂载”还是“设备未识别”

先查看当前挂载状态、分区文件系统类型以及 UUID：

sudo lsblk -o NAME,PATH,FSTYPE,LABEL,UUID,PARTUUID,SIZE,MOUNTPOINTS
sudo findmnt -t ext4,xfs,btrfs
df -hT

这些命令的作用不同：

• lsblk 用于确认块设备是否存在，以及文件系统 UUID、类型和当前挂载点。
• findmnt 用于确认某个文件系统当前是否已经挂载。
• df -hT 用于确认已挂载文件系统的容量和类型。

例如，正常情况下可能看到类似结果：

NAME   FSTYPE LABEL UUID                                 MOUNTPOINTS
sda
├─sda1 ext4         11111111-2222-3333-4444-555555555555 /
└─sda2 ext4         aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data

如果 lsblk 中能看到 /dev/sda2 和 UUID，但 MOUNTPOINTS 为空，说明设备已经被内核识别，问题更可能位于 fstab 或挂载过程。如果连 /dev/sda2 都不存在，应先检查设备是否实际连接、虚拟磁盘是否附加，以及存储设备是否在系统启动时出现；此时单纯修改 fstab 不能解决问题。

如果 lsblk 显示分区已经挂载到 /data，但 df -hT 中也有对应记录，则它可能只是挂载成功后目录内容与预期不同。此时应重点确认访问的是正确挂载点，而不是继续重复执行挂载命令：

findmnt /data
mountpoint /data
sudo du -sh /data

mountpoint 返回成功，且 findmnt /data 显示了设备来源，通常可以判定 /data 已挂载。若目录中没有文件，可能是进入了未挂载时的空目录，也可能是挂载了错误的分区，需要继续核对设备和 UUID。

二、备份并检查 /etc/fstab

/etc/fstab 是系统启动时生成挂载配置的主要来源。修改前先保存一份原文件，便于发现错误后恢复：

sudo cp -a /etc/fstab "/etc/fstab.bak.$(date +%F-%H%M%S)"
sudo sed -n '1,200p' /etc/fstab

fstab 每条有效配置通常由六个字段组成：

设备或标识    挂载点    文件系统类型    挂载选项    dump字段    fsck顺序

一个使用 UUID 的本地分区配置示例：

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults 0 2

各字段含义如下：

先检查是否存在明显的格式问题：

sudo grep -vE '^[[:space:]]*(#|$)' /etc/fstab

重点查看以下情况：

1. 非注释行是否确实有六个字段。
2. 字段之间是否使用空格或制表符分隔，而不是把整行写成一段无法解析的文本。
3. 挂载点是否与实际目录完全一致，例如 /data 和 /data/ 通常等价，但大小写不同则不是同一个路径。
4. 文件系统类型是否与 lsblk -f 或 blkid 显示一致。
5. 同一挂载点是否出现多条有效配置。
6. 同一个 UUID 是否被误写到多个挂载点。
7. 路径中是否包含空格。fstab 中空格不能直接写入，通常需要使用 \040 表示。

典型冲突：同一挂载点存在两条配置

例如，文件中同时存在：

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults 0 2
/dev/sdb1 /data ext4 defaults 0 2

这两条配置都试图挂载到 /data，但来源设备不同。启动时可能出现重复挂载、其中一条失败，或者在手动执行 mount -a 时提示挂载点已被占用。不要通过不断重启来观察哪一条生效，应根据 lsblk -f 确认真正需要使用的设备，只保留一条配置，并将另一条删除或注释：

# /dev/sdb1 /data ext4 defaults 0 2
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults 0 2

如果同一个 UUID 被写到了多个挂载点，也应保留正确的一处。配置冲突时，不能仅根据“目录存在”判断成功，必须使用 findmnt 确认最终挂载来源。

三、核对 UUID、PARTUUID 与实际设备

最常见的配置不生效原因是 fstab 中保存的 UUID 与当前分区 UUID 不一致。可以同时使用 lsblk 和 blkid 检查：

sudo blkid
sudo lsblk -f

以 /data 为例，先取得实际 UUID：

sudo blkid /dev/sda2

可能得到：

/dev/sda2: UUID="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" TYPE="ext4"

然后检查 fstab 中是否使用了完全相同的值：

grep -nE '(/data|aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)' /etc/fstab

常见错误包括：

• UUID 少写、错写一个字符；
• 把另一个分区的 UUID 复制到了当前配置；
• 把 PARTUUID 当成文件系统 UUID 使用；
• 分区重新格式化后，文件系统 UUID 已经变化；
• fstab 仍引用旧磁盘路径，例如 /dev/sdb1，但启动后设备名称变成了 /dev/sdc1。

对于普通文件系统，优先使用 UUID= 作为设备标识，因为 /dev/sdX 设备名可能随设备枚举顺序变化。若系统实际使用的是 PARTUUID，则应确认 blkid 或 lsblk 中对应字段确实为分区 UUID，并保持写法一致：

PARTUUID=12345678-01 /data ext4 defaults 0 2

不要看到 UUID 不匹配就直接格式化分区。格式化会破坏原有数据，只有在已经确认无需保留数据、完成备份并明确要重新建立文件系统时才考虑。对于挂载故障，通常只需要修正 fstab 中的标识，不需要重新创建文件系统。

如果 lsblk 显示设备位于 /dev/mapper/ 下，说明可能使用了逻辑卷。此时应核对逻辑卷和其上文件系统的 UUID：

sudo lsblk -f
sudo blkid /dev/mapper/逻辑卷名称

不要将卷组、逻辑卷名称和文件系统 UUID 混为一谈。fstab 中可以使用正确的逻辑卷路径，也可以使用该文件系统实际的 UUID，但必须与当前设备信息对应。

四、确认挂载点和文件系统类型

设备和 UUID 正确后，检查挂载目录是否存在：

sudo test -d /data && echo "挂载点存在" || echo "挂载点不存在"

如果目录不存在，可以创建目录：

sudo install -d -m 0755 /data

install -d 只创建目录，不会创建文件系统，也不会删除目录中的内容。如果 /data 原本已有业务文件，应先确认这些文件是否只是未挂载状态下写入的本地目录内容。直接挂载后，这些文件会被挂载文件系统遮挡，但通常不会被删除；卸载文件系统后仍可能看到它们。操作前要确认目录用途，避免误把临时文件当作业务数据。

再将 fstab 中的文件系统类型与实际类型进行对照：

sudo blkid /dev/sda2

例如实际结果为：

TYPE="xfs"

而 fstab 却写成：

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults 0 2

这会导致挂载失败。应将类型改为实际类型：

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data xfs defaults 0 2

如果设备没有显示 FSTYPE 或 TYPE，不要直接猜测文件系统类型。无文件系统、分区损坏、读取设备失败和加密设备尚未解锁，都可能造成类似现象。

五、用工具验证 fstab 语法

修改后，先使用 findmnt 检查 fstab 内容：

sudo findmnt --verify --verbose

正常时通常会显示检查通过。若提示设备不存在、挂载点不存在、选项无效或解析失败，应根据具体行号回到 /etc/fstab 修正。

也可以查看 fstab 中某个挂载点的解析结果：

sudo findmnt --fstab --target /data

若能返回设备、文件系统类型和挂载选项，说明该行至少能被解析。若无输出，通常表示：

• fstab 中没有 /data 配置；
• 挂载点拼写不一致；
• 该行被 # 注释；
• 行格式无法被正确识别。

语法验证通过不代表磁盘一定能挂载成功。它主要检查配置可解析性，无法完全证明设备存在、文件系统健康或权限条件满足。因此下一步要进行实际挂载测试。

六、先单独测试，再测试全部配置

如果当前 /data 没有挂载，可以只测试这一项：

sudo mount /data

该命令会根据 /etc/fstab 中 /data 对应的配置进行挂载。成功后立即验证来源：

findmnt /data
df -hT /data

预期结果应类似：

TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sda2 ext4   rw,relatime

如果 mount /data 报错，应根据错误信息分支处理：

确认单个挂载点正常后，再检查所有 fstab 条目：

sudo mount -av

mount -a 会尝试挂载 fstab 中未使用 noauto 的所有条目，因此可能影响其他文件系统。生产服务器上执行前，应先阅读 fstab 并确认其他挂载项不会触发业务风险。输出中的每一行都要关注，不能只看命令最后是否返回成功。

如果某个挂载点已经存在并且需要重新读取配置，可以先确认没有业务进程使用它：

findmnt /data
sudo fuser -vm /data

确认可以卸载后再执行：

sudo umount /data
sudo mount /data

不要对正在被数据库、日志服务或应用程序使用的目录直接执行卸载。无法确认占用进程时，应安排维护窗口，或者只修改配置并在后续重启窗口验证。

七、检查 systemd 生成的挂载单元和启动日志

多数使用 systemd 的发行版会根据 /etc/fstab 自动生成挂载单元。修改 fstab 后，重新加载 systemd 配置：

sudo systemctl daemon-reload

这不会自动修复错误的 UUID，也不会替代实际挂载测试，只是让 systemd 重新读取生成配置。可以列出当前挂载单元：

systemctl list-units --type=mount --all

对于 /data，对应的挂载单元通常是 data.mount。如果挂载点路径较复杂，可以让 systemd 自动转换名称：

systemd-escape --path --suffix=mount /data

然后查看对应状态和本次启动日志：

sudo systemctl status data.mount --no-pager
sudo journalctl -b -u data.mount --no-pager

如果系统提示找不到 data.mount，不一定表示 fstab 没有生效，也可能是该挂载尚未被触发生成。此时仍应以 findmnt --verify、mount /data 和完整日志为准。

查看本次启动与存储设备相关的日志：

sudo journalctl -b -p warning..err --no-pager
sudo dmesg -T | grep -Ei 'mount|filesystem|ext4|xfs|I/O error|UUID'

结果判断可以分为三类：

• 日志显示 UUID 不存在：优先修正设备标识或确认设备启动时是否出现。
• 日志显示文件系统类型、超级块或元数据错误：不要继续反复修改 fstab，应转入文件系统检查。
• 日志显示设备等待超时：可能是设备没有及时出现，也可能是 fstab 指向了不存在的设备。

对于非关键的数据盘，可以在确认业务允许的前提下使用：

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

nofail 可以让非关键分区挂载失败时不阻塞系统启动，x-systemd.device-timeout=10s 可以缩短等待不存在设备的时间。它们不能修复 UUID 错误，也不适用于必须存在的根分区、系统目录或关键业务数据盘。使用前应明确接受“系统启动成功但数据盘未挂载”的风险，否则应用可能把数据写入普通目录，造成数据位置混乱。

八、区分配置错误与文件系统损坏

如果 UUID、挂载点、文件系统类型和 fstab 语法都正确，但仍然出现 wrong fs type、bad superblock、元数据错误或 I/O error，应怀疑文件系统或底层存储状态。

先确认目标文件系统没有挂载：

findmnt /data
sudo fuser -vm /data

对未挂载的文件系统，可以先进行非修改式检查。具体工具应根据文件系统类型选择：

# ext4 示例：只读检查，不进行修复
sudo fsck -n /dev/sda2

fsck -n 的作用是尽量以只读方式报告问题，但不同文件系统的检查工具行为可能不同。不要对已挂载的生产文件系统直接运行修复操作。真正修复前应完成数据备份或快照，并在维护窗口、救援环境或单用户维护状态下执行。

如果是 XFS 等文件系统，应使用与其匹配的维护工具，而不是盲目指定 ext4 的检查工具。文件系统检查只能解决文件系统元数据问题，不能修复 fstab 中写错的 UUID、挂载点或选项。两类问题应分别处理。

九、服务器已经无法正常启动时怎么处理

如果错误 fstab 导致服务器进入紧急模式、长时间等待设备或启动失败，应通过云平台控制台、远程管理控制台或救援环境进入系统，不要反复强制重启。

进入维护环境后，先确认根分区和 /etc/fstab 所在位置已经挂载。若根文件系统以只读方式挂载，只能在确认当前确实处于维护环境、且目标是正确根分区后，再按发行版环境执行重新挂载：

mount | grep ' on / '

必要时：

sudo mount -o remount,rw /

然后备份并编辑配置：

sudo cp -a /etc/fstab "/etc/fstab.bak.$(date +%F-%H%M%S)"
sudo editor /etc/fstab

修复方式通常是：

• 将错误 UUID 改成 blkid 查到的实际 UUID；
• 注释掉重复或确认无效的挂载行；
• 补齐缺失的挂载目录；
• 修正文件系统类型和明显错误的挂载选项；
• 对不影响启动的可选数据盘，按实际需求增加 nofail，但不要用它掩盖关键数据盘故障。

修改后先验证：

sudo findmnt --verify --verbose

如果环境允许，再单独挂载目标设备：

sudo mount /data
findmnt /data

确认配置能解析、设备能挂载后，再退出救援环境并启动系统。若仍然失败，应保留启动日志和具体错误信息，不要继续随机修改多个字段，否则容易使故障范围扩大。

十、修复后的验证顺序

修复完成后，按照以下顺序验证，能够避免“手动挂载成功但重启仍失败”的情况：

1. 确认 fstab 备份存在，并检查当前配置：

   ls -l /etc/fstab*
   sudo sed -n '1,200p' /etc/fstab

1. 验证配置语法：

   sudo findmnt --verify --verbose

1. 重新加载 systemd 生成配置：

   sudo systemctl daemon-reload

1. 单独挂载目标目录：

   sudo mount /data

1. 验证真实设备、文件系统类型和挂载选项：

   findmnt /data
   df -hT /data

1. 测试其他 fstab 项：

   sudo mount -av

1. 检查本次操作是否产生错误：

   sudo journalctl -b -p warning..err --no-pager

如果 findmnt /data 显示的 SOURCE、FSTYPE 与预期一致，df -hT 能显示容量，且 mount -av 没有报错，说明当前运行状态已经基本正常。随后仍应在维护窗口重启一次，验证启动阶段是否能够自动挂载：

sudo reboot

重启完成后再次执行：

sudo lsblk -f
findmnt /data
df -hT /data

同时检查业务实际访问的目录是否仍是同一个挂载点。对于重要数据盘，可以将验证结果纳入日常巡检，例如检查 findmnt --target /data 的返回状态、挂载来源和可用空间。当设备更换、分区重新格式化或系统模板变更后，也应重新核对 UUID，避免旧 fstab 配置在下一次重启时再次失效。

复测与持续观察

Linux服务器分区及挂载问题，修复重点不在于反复执行 mount，而在于建立“实际设备信息—fstab配置—systemd启动结果—最终挂载状态”之间的对应关系。先确认设备存在，再核对 UUID 和文件系统类型；先验证单个挂载点，再测试全部配置；遇到文件系统错误时停止修改配置，转入离线检查。这样既能处理重启后分区未挂载，也能避免把错误的设备、空目录或未验证的容错参数带入下一次启动。