群晖存储空间损毁/Btrfs文件系统损坏数据恢复教程

目录 原创

· 感谢 https://roov.org/2017/11/btrfs-repair/ 的教程提供指导,本文在原教程出现报错的地方进行了修改和完善,部分图片因恢复数据时未截图转载自原教程。已成功恢复5.4T的数据。

· 恢复数据操作系统 Ubuntu 16.04 LTS desktop( 系统镜像下载地址: https://download.orcy.net:8027/Ubuntu/16.04/

使用的黑群晖系统,在偶尔一次断电重启后,有一个4x2T硬盘的存储空间出现了“已损毁”状态,而网络上搜索到的教程和案例都是使用 Ext4 作为文件系统,那么只需要用 UFS explorer 来修复就好了。偏偏群晖推荐用的是 Btrfs 文件系统,当前状态系统中无法读取文件,但 RAID 并没有异常,无需进行 RAID 清理。通过查看 S.M.A.R.T 状态,发现所有硬盘均处于健康状态,于是跳过这一步。接下来我们需要引导到 Ubuntu 系统并尝试挂载 RAID。

进入Ubuntu系统后第一件事是安装必要的工具包以及挂载 RAID,打开终端并以 root 身份(sudo -i)执行以下操作:


apt-get update
apt-get install mdadm lvm2 btrfs-prog
mdadm -Asf && vgchange -ay

正常完成后可以在磁盘管理中看到 RAID 阵列,但是由于文件系统损坏,此时是无法挂载的。

切换回终端,运行以下命令:

btrfs-find-root /dev/vg1/volume-1 &> /home/3.txt

注意:/dev/vg1/volume-1 此位置为系统内的位置,系统不同可能默认路径不一致,以你自己的位置为准,如果使用挂载位置可能会出现报错无法扫描。

运行过程可能需要10-30分钟,期间是没有任何回显的。等待运行完成后终端会返回命令提示符,这时我们打开 /home/3.txt 文件,可以看到如下内容:

我们需要用到的数据是 Well block 后面的这一串数字,其后的 gen 数字越高,恢复的可能性越大。下一步使用找到的 tree root 来模拟修复,到目前为止的所有操作都不会对硬盘进行写入和修改,也不会破坏任何数据。

btrfs check --tree-root <block> --super <sup> /dev/vg1/volume1
#<block>为上一步中的数值,按 gen 数字从高到低依次尝试使用
#<sup> 可以尝试0,1或2。

如果 block 有效,运行结果末尾应当类似于以下图示:

如果最后回显不是以上格式,表明这一条 无效,需要继续尝试下一条。在确认看到以上提示后,我们尝试将数据导出。

btrfs restore /dev/vg1/colume1 /data5 -D -v -F -i -t <block>

此时仍然使用上一步中的 block 值,将 /data5 改为导出目录,需要确保留有足够空间存储文件。如果文件名包含特殊符号可能导致导出中断,将目标分区格式化为 Ext3/4 即可。

如果导出正常进行,会看到类似上图的提示,此处没有进度提示,可以自行前往导出目录查看。如果导出失败会给出其他提示,在确认导出分区是 Ext3/4 的情况下,则只能退回上一步尝试其他 block 值。

如下图,成功恢复5.4T左右的数据到/data5目录下:

到目前为止我们并没有对数据盘进行任何写入和修改操作,如果因为种种原因无法导出,或是导出过程异常中断,仍然可以通过修复原盘的方式来挽回数据。不过请注意,此步骤有可能会损坏数据,如果你不能接受任何风险,请停止执行并联系专业机构。

以下修复步骤博主未亲自测试,请谨慎操作!

btrfs check --repair --tree-root <block> --super <sup>
#使用之前步骤中正常回显的 <block> 及 <sup> 值进行正式修复,确认操作完成后执行:
btrfs rescue super-recover /dev/vg1/volume-1

提示确认目标分区是 Btrfs 文件系统,否则会损坏数据,输入 y 确认操作。等待数秒后再次回到提示符,如果一切顺利,此时已经可以通过磁盘管理工具挂载 Btrfs 分区了。不过群晖很大几率不会识别修复后的文件系统,还是建议将数据导出后再将硬盘还原。

暂无评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注