【Linux】文件系统与 fsck.ext4 修复 - 我踩过的坑与总结

承接上一回，这期依然是 Linux 的总结。但这次我想聊聊文件系统和 fsck，这个我踩过千百遍的坑。

一、首先什么是 fsck？

在我早期使用 Linux 的时候，对磁盘问题的理解非常肤浅：

"系统起不来了？那就 fsck 一下试试。"

直到我遇到 ext4 分区无法挂载、系统进入 emergency mode、fsck 直接报错 ，我才意识到：
fsck 不是"万能修复键"，而是"最后的外科手术刀"。

理解下面三件事，对我来说是分水岭：

什么时候能用 fsck，什么时候绝对不能用
fsck 到底在"修什么"
哪些参数会救命，哪些参数会毁数据

二、fsck 在 Linux 中的定位

从本质上讲：

fsck（File System Consistency Check）是用来"校验并修复文件系统结构一致性"的工具，而不是数据恢复工具。

它主要检查和修复的是：

superblock（超级块）
inode 表
block bitmap
inode bitmap
目录结构与引用关系

值得注意的是 fsck 关心的是"结构是否一致"，它是不保证你的文件内容"正确或完整"的。

三、在 fsck 之前必做的三件事（重点）

1.确认分区没有被挂载

fsck 对"已挂载分区"执行是极其危险的行为。

我通常用：

bash 复制代码

mount | grep sda
lsblk

如果是根分区：

必须进入单用户模式
或使用 Live CD / 救援系统

2.能备份就先备份（哪怕是 dd）

如果磁盘还能读，我至少会做一份原始镜像：

bash 复制代码

dd if=/dev/sda of=/backup/sda.img bs=4M status=progress

我宁愿慢，总比事后后悔强。

3.搞清楚文件系统类型

bash 复制代码

blkid
lsblk -f

确认是 ext4，而不是 xfs / btrfs

四、fsck.ext4 的核心用法

1.基础检查（只读，不修改）

bash 复制代码

fsck.ext4 -n /dev/sda1

一般我会采用 -n（不做任何修改）参数先做一次评估，先看损坏程度。

2.自动修复（踩坑最多）

bash 复制代码

fsck.ext4 -y /dev/sda1

这可以算是我踩坑最多的参数，-y（对所有修复询问自动回答 yes）。以前常用，现在的话只在我已经有备份，或别无选择时使用。

3.指定备用 superblock 修复

这是我最常"救活"分区的一招。先查看备用 superblock：

bash 复制代码

dumpe2fs /dev/sda1 | grep -i superblock

然后指定一个：

bash 复制代码

fsck.ext4 -b 32768 /dev/sda1

五、lost+found？

fsck 修复后，经常会看到：

bash 复制代码

/lost+found

里面是：

找不到原目录结构的 inode
文件名通常是数字

我的过往经验是若是小文件，那一般内容还算是完整的，如果是大文件（譬如，数据库、镜像等）那么可用性就不高了，那如果是目录结构的话，那基本就不可能完全恢复的。那么我的做法是：

逐个 file + less 判断
能确认用途的，手动归位
其余长期留档，不轻易删除

六、我踩过的坑（血的教训）

1.在已挂载的根分区上跑 fsck

结果可想而知，文件系统状态直接混乱，最后只能进救援系统重修。这也让我意识到 "fsck ≠ 在线修复工具" 这个道理。

2.对 XFS 分区使用 fsck.ext4

fsck 根本就"看不懂"，并且造成二次损坏。后面我知道了 XFS 用 xfs_repair，只有 ext4 才用 fsck.ext4。

七、我现在的做法

说实话，我并不想经常用 fsck。现在我更倾向于：

RAID + 定期 SMART 检测
UPS 防断电
日志与业务数据分盘
关键数据快照 + 备份
新系统优先考虑 btrfs / zfs

fsck 对我来说，已经变成了"最后的止血手段"，而不是常规维护方式。