现场是这样的。一台 CentOS 7 数据盘异常掉电后跑了 fsck -y，修复完成挂在 /data 下，lost+found 里多了三万个 inode 编号命名的文件，业务目录里少了大量附件。
中间走过弯路，把「fsck 修复时重排了部分 inode，原始路径信息彻底不可得」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。目录项损坏后文件本身还在，fsck 只能把它们挂到 lost+found 保留内容；文件名随目录项一起丢失，只剩 inode 号，无法从文件系统直接还原原名；应用侧如果有数据库记录文件名与大小，可以作为匹配依据。
动手时先统计 lost+found 的规模与类型
ls /data/lost+found | wc -l && file /data/lost+found/* | awk -F: '{print $2}' | sort | uniq -c | sort -rn | head再往下按文件类型和大小筛出业务附件
find /data/lost+found -type f -size +100k -newermt '2026-09-01' | head -20随后用数据库里的文件名和大小做匹配
mysql -N -e 'select name,size from app.attach' > /tmp/attach.txt && find /data/lost+found -type f -printf '%s %p\n' | sort -n > /tmp/lf.txt剩下的就是核对后把文件拷回业务目录并修正属主
cp -a /data/lost+found/12345 /data/attach/2026/09/ && chown www:www /data/attach/2026/09/12345怎么算真的好了，看的是同一批现象。按大小和签名匹配后能还原的附件数量与业务清单基本对齐，抽查图片能正常打开，业务目录文件数与故障前备份记录一致。
这里还有个坑。lost+found 里的文件名一律不可信，只能靠内容特征匹配；越早停止写入越好，拖得越久 inode 被复用的比例越高。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。