平台：ESXI 7.0.1U3 黑群：DS918+ DSM6.2.3 btrfs分区 恢复系统：Ubuntu20.4 国庆期间因为频繁的几次断电导致ESXI上部署的黑群出现存储池损坏，最先尝试在win下使用NA Express恢复，然而不知道是不是因为是虚拟磁盘的关系反正是读不出任何数据。最终经过两天学习使用下面的方法将所有数据全部复制到另一个黑群系统下面，以下所有操作均在ESXI下完成。 一、准备系统：安装Ubuntu20.4，官网下载上传ESXI后安装。（请自行解决） 二、挂载故障磁盘及恢复目的磁盘 我是先在ESXI上另外创建了一个ext4分区的918+黑群，然后把数据盘挂载到ubuntu用于存储恢复的数据，为什么没有继续使用btrfs分区，一是不想再因为分区损坏搞这么复杂来恢复数据，二是btrfs分区可能会因特殊字符导致恢复数据写入失败。 /dev/md/FTP:2是挂载的输出目的盘,已经挂载到/media/root/1.42.25426下面。 /dev/md/2是故障盘，虽然有挂载按钮但是一点报错，试了我另外一个正常黑群如果使用btrfs分区也是无法挂载的，此处不知为何。 三、恢复数据 1、 Ubuntu安装支持。 命令1：apt-get update 命令2：apt-get install mdadm lvm2 btrfs-prog（安装所需工具，如果报错请自行百度） 命令3：mdadm -Asf && vgchange -ay（装载 DiskStation 的所有硬盘） 2、 扫描btrfs分区 命令：btrfs-find-root /dev/md/2 &> /tmp/root.txt 注释：/dev/md/2是群晖btrfs分区，/tmp/root.txt是在tmp文件夹下新建root.txt文件存储扫描结果。（也可以存到其他地方，tmp文件夹的文件重启后会丢失） 运行过程可能需要10-30分钟，期间是没有任何提示。等待运行完成后终端会返回命令提示符，这时我们打开 root.txt 文件，可以看到如下内容： 需要用到的数据是 Well block 后面的这一串数字，其后的 gen 数字越高，恢复的可能性越大。下一步使用找到的 tree root 来模拟修复。有时候可能会扫描出几万条记录但是通常前面几行就可以成功。 3、 尝试恢复 命令：btrfs check --repair --tree-root <block> --super <sup> 示例：btrfs check --repair --tree-root 394631839744 --super 0 /dev/md/2 其中 <block> 是Well block 后面的一串数字，按 gen 数字从高到低依次尝试，<sup> 可以尝试0/1/2其中一个数字，我直接用的0。 特别注意：这里我加了--repair参数有可能会损坏数据，如果你不能接受风险，就此打住吧找专业的人帮你。执行后返回结果一定要是no error found才行。不知道为什么在我的ESXI环境下不加--repair一直返回error(s) found。 4、 复制数据到目的盘 命令：btrfs restore /dev/md/2 /media/root/1.42.6-25426/photo 注释：/media/root/1.42.6-25426/photo是恢复文件输出的目的地目录。 5、 恢复过程中可能会遇到的问题 情况一，中间可能会多次遇到某些文件恢复报错询问是否需要继续，有y/n/a三个选择，如果需要该文件输入y或者a回车即可继续恢复，不需要则输入n跳过即可。 复制文件期间要经常查看是否出现we seem to be looping a lot on/xxxx的提示否则会一直卡在这里耽误恢复的时间。 情况二，直接报错退出，遇到这种情况可能是因为文件已经损坏无法恢复导致的，这个时候只需要重新运行恢复命令即可继续恢复剩下的数据。 遇到以上报错的情况我怀疑是因为使用了--repair参数导致的，我后来测试就算挂载没有损坏btrfs分区进行扫描如果不加--repair参数也会出现error(s) found报错，希望有linux高手可以解答一下这个疑问。 我所有文件接近7.5T恢复花费3天时间，当中因为报错的时候没有及时处理耽搁的大部分时间，特别是晚上，下面这些就是我恢复出来的文件了。 最后说一下如果大家在ESXI上搞黑群可能真的要慎用btrfs分区，恢复起来比EXT4分区麻烦太多了，如果有朋友遇到类似问题先不要惊慌只要不乱操作数据一般是能够恢复出来的，如果我上面的这堆命令使用的时候遇到问题也可以百度或者谷歌其他帖子尝试不同的命令或者参数。还有ESXI上面的快照功能也可以经常去拍一拍，当我真的有需要的时候才体会到了快照是多么的重要。
