1. 首页
  2. 科技数码

与 VMFS 斗争(下)群晖 btrfs 文件系统的扫描

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

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

背景

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

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

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

与 VMFS 斗争(下)群晖 btrfs 文件系统的扫描

其中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在容错方面做得不错,至少还可以把文件给导出来……

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

原创文章,作者:夜风博客,如若转载,请注明出处:https://www.homedt.net/47159.html