非正常断电后的文件系统修复：fsck 注意事项

断电或异常重启之后机器能进系统，不代表文件系统毫发无伤——有些损伤要等到访问特定文件时才暴露。这篇讲修复的正确姿势和几个必须避开的坑。 先定位伤情再动手 修复前先翻日志：`dmesg | grep -iE 'error|ext4|xfs'` 里通常有文件系统报错的直接线索，确认受影响的是哪块盘哪个分区，别上来就全局修。断电对磁盘本身也是考验，物理机顺手跑 `smartctl -H /dev/盘符` 看健康结论，排除硬件层面的连带损伤；云盘可以跳过这一步。 修复前必须卸载吗 必须。对已挂载的文件系统跑 fsck，等于两个人同时改同一本账，可能把小伤修成重伤。数据盘先 `umount /dev/vdb1`，占用它的进程用 `lsof +D /挂载点` 找出来停掉。根分区没法卸载，就用救援盘或云平台的救援模式进系统再修。 ext4 与 xfs 用法不同 ext 系列用 `fsck -y /dev/vdb1`，-y 表示对所有询问自动答 yes。xfs 的工具是 xfs_repair：先跑 `xfs_repair -n /dev/vdb1` 只检查不修改，看完问题清单再去掉 -n 正式修复。特别提醒：xfs_repair 的 -L 选项会清空日志强行挂载，可能丢掉未落盘的数据，只在日志损坏导致正常修复走不通、且数据已有备份时才允许使用。 修复前后各做一件事 修复前，能备份先备份：还能挂载时先把重要数据 rsync 出去，已经挂不上的用只读方式尝试挂载抢救。要明白修复工具解决的是结构一致性，过程可能牺牲个别文件换取整体可用，找回的碎片会散落在各分区的 lost+found 目录里。修复后，先用只读方式挂载抽查关键目录，确认无异常再恢复正常挂载。 预防层面，生产环境配 UPS，或选择云平台提供的数据可靠性保障；文件系统用日志型的 ext4 或 xfs，异常重启后系统自动回放日志，多数小损伤根本轮不到手动修复。真正需要 fsck 出场的日子，本身就说明预防环节已经欠账了。