与 VMFS 斗争（下）群晖 btrfs 文件系统的扫描

自从去年下半年以来就一直在和 VMFS 文件系统斗争。这个系列也是开篇以来拖了很久。本来还计划了个中篇 - VMFS on VSAN，但想想家用一般不会接触到。就先把下篇给填上。

群晖 ext4 请参考 与 VMFS 斗争（上）群晖 ext4 文件系统的扫描修复

背景

家里的服务器由于阵列卡缓存和缓存电池同时故障，在一次小区大面积停电后虚拟机全军覆没。其中windows做chkdsk就正常了；photonos开机直接进rescue mode做fsck就正常了。唯独群晖的brtfs，修正起来非常麻烦。

群晖存储池“已损毁”的修复

这台群晖同样挂载了两块虚拟磁盘作为存储。但其结构与之前的稍有不同：

其中md0存储了群晖操作系统文件，md1存储了群晖的配置文件。位于/volume1的应用程序、应用配置以及保存的文件都无法正常读写入。检查了系统分区和配置存储分区均正常，所以将问题锁定在sdb3和md2。

由于群晖自带的btrfs管理版本低且功能差，直接关机并将该虚拟硬盘挂载到Ubuntu下。

大部分btrfs的中文修复教程都指向一个命令：btrfs check。在Ubuntu下，首先需要安装支持工具：

apt-get update && apt-get install -y mdadm lvm2 btrfs-prog

然后查看分区内的block并根据读出的block修复：

btrfs-find-root /dev/md/3

btrfs check --repair --tree-root 950302949376 --super 2 /dev/md/3

然而并没有什么用，到最后因 Couldn't setup device tree 而失败。或尝试重置分区索引：

btrfs rescue super-recover /dev/md/3

然而也没有什么用，到最后提示 Disk I/O error

群晖 btrfs 损坏后的文件导出

经过一番科学的搜索，发现可以扫描并导出分区内的文件。首先查看分区文件夹入口：

btrfs restore -l /dev/md/3

该命令会返回一堆形如`tree key (257 ROOT_ITEM 0) 950302949376 level 2`的文件夹，但其中只有一个是根文件夹，其他的都是子文件夹。

经过一番尝试，最终确认入口 257 是根文件夹。给Ubuntu挂载了一个nas目录，然后将该文件夹恢复出来：

btrfs restore -vvvv -r 257 -i /dev/md/3 /mnt/nas/257

如果不好确定哪个是根文件夹且硬盘空间足够，也可将所有的ROOT_ITEM都给恢复出来。某个网站给出了一个很有效的批处理：

btrfs restore -l /dev/md/3 | grep ROOT_ITEM | awk 'substr($3,2) ~ /^[0-9]+$/ {print substr($3,2)}' | xargs -I % sh -c 'mkdir /mnt/nas/%; btrfs restore -vvvv -r % -i /dev/md/3 /mnt/nas/%'

后记

从易用性以及广泛性来看，ext4显然是比btrfs更好的文件系统。但就功能来说，btrfs更胜一筹。只不过一旦btrfs文件系统有损坏，修复不但很麻烦而且不一定成功。但btrfs在容错方面做得不错，至少还可以把文件给导出来……

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～