修复 xfs 文件系统没那么简单
发布作者：微思网络 发布时间：2023-07-11 浏览量：0次
不合理的恢复步骤
网络上有大量的文章告诉系统管理员当 XFS 文件系统挂载失败时，直接运行 xfs_repair 命令进行修复。修复文件系统确实是这个命令，但在操作流程上有明显的不妥：
系统管理员通常对文件系统的结构了解并不深入，日常工作也仅限于操作层面，例如扩容文件系统等...修复操作对于系统管理员来说完全是一个"黑箱操作"，你能做的只是运行这个命令然后默默祈祷它能够修复成功。
直接对已经损坏的文件系统执行修复，本身就是一个风险极大的行为，极大可能造成二次损坏让情况变得更糟。
评估恢复步骤
TL;DR: 将受损文件系统的元数据导出，转换成新的映像文件，再对新的映像文件执行修复操作。这样做的目的是能够在对文件系统执行强制修复之前，查看强制修复带来的后果。
重要的：使用这种方法，并不能恢复数据！！！只是用于评估是否能直接对原始文件系统进行修复。
xfs_repair 命令提供了-L 选项用于强制修复(强制修复会将文件系统日志清除)
-L Force Log Zeroing. Forces xfs_repair to zero the log even if it is dirty (contains metadata changes). When using this option the filesystem will likely appear to be corrupt, and can cause the loss of user files and/or data.
译: 强制日志清零，即使日志中的脏数据(包含元数据的修改)还未同步到持久化存储。使用此选项时，文件系统可能会出现损坏的情况，可能导致用户文件或数据丢失
在无计可施的情况下，-L 选项等同于"生死有命，富贵在天"
文件系统损坏并评估
▶ 1. 首先已经创建好一个正常的 XFS 文件系统
# df -hT /mnt
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb1 xfs 2.0G 47M 2.0G 3% /mnt
▶ 2. 在文件系统中写入一个测试文件，用于一会验证恢复
# echo "very important" >/mnt/file.txt
# cat /mnt/file.txt
very important
▶ 3. 卸载文件系统，准备模拟文件系统故障
# umount /mnt
▶ 4. 使用 xfs_db 命令模拟文件系统损坏
# xfs_db -x -c blockget -c "blocktrash -s 512109 -n 10" /dev/sdb1
blocktrash: 2/3 btino block 14 bits starting 2837:5 flipped
blocktrash: 3/5 btrefcnt block 411 bits starting 3714:0 flipped
blocktrash: 2/2 btcnt block 3 bits starting 2143:4 flipped
... output ommited ...
▶ 5. 重新挂载文件系统，此时会提示报错
# mount /dev/sdb1 /mnt
mount: /mnt: mount(2) system call failed: Structure needs cleaning.
▶ 6. 使用 xfs_metadump 命令将已损坏的文件系统元数据导出
# xfs_metadump -o /dev/sdb1 /tmp/sdb1.metadump
# file /tmp/sdb1.metadump
/tmp/sdb1.metadump: XFS filesystem metadump image
▶ 7. 使用 xfs_mdrestore 命令将元数据转换为映像文件
# xfs_mdrestore /tmp/sdb1.metadump /tmp/sdb1.img
# file /tmp/sdb1.img
/tmp/sdb1.img: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
▶ 8. 使用 xfs_repair 命令对映像进行修复(注意不是强制修复)
# xfs_repair /tmp/sdb1.img
Phase 1 - find and verify superblock...
bad primary superblock - inconsistent filesystem geometry in realtime filesystem component !!!
... output ommited ...
Phase 2 - using internal log
- zero log...
... output ommited ...
Phase 3 - for each AG...
... output ommited ...
Phase 4 - check for duplicate blocks...
... output ommited ...
Phase 5 - rebuild AG headers and trees...
... output ommited ...
Phase 6 - check inode connectivity...
... output ommited ...
Phase 7 - verify and correct link counts...
... output ommited ...
Format log to cycle 4.
done
#
▶ 9. 在系统上重新挂载刚刚修复的映像文件
# mount /tmp/sdb1.img /mnt # ls /mnt file.txt # cat /mnt/file.txt #
可以看到通过元数据导出的文件系统映像，经过 repair 后，可以看到目录中出现了原始文件，但是该文件的内容却消失了。
是的，因为 xfs_metadump 仅仅是元数据，并不包含文件的真实数据。
所以这只是一个评估是否能够恢复的过程。
真正重要的是第8步中的输出，在对元数据进行恢复的时候这些输出结果能够显示文件系统可能哪里损坏了，是否修复成功。我并不具备调试文件系统的能力，所以我省略了这些内容。
写这篇文章的目的只是为了解释"合理的评估流程"而非"恢复损坏的文件系统"。
在工作环境中，专业的事情应交由专业的人来完成。例如企业可以购买红帽订阅服务以获取技术支持。
通常，服务器突然断电、磁盘坏道是2个最容易导致文件系统损坏的原因。
▶ 10. 最后我尝试直接对文件系统进行修复，并尝试挂载
# xfs_repair /dev/sdb1 # cat /mnt/file.txt very important
恢复了，这是最好的结果。但这是我的实验环境，经过我的简单设计才能够恢复。
如果大家愿意跟着我的步骤一起感受这个实验，在第4步中，"-n 10" 可以尝试替换成 "-n 1000" 你会得到不一样的结果：文件系统彻底损坏了。
最后，一定要定期备份文件系统，备份重要的数据，企业不要为了节省成本而得不偿失。
