· 群晖存储空间损毁；Btrfs文件系统损坏数据恢复；Btrfs Repair；Synology Repair
· 恢复数据操作系统 Ubuntu 16.04 LTS desktop（ 系统镜像下载地址： https://cloud.orcy.net.cn:5002/s/JcezFxzks4bXMPB 提取密码:2020 ）
使用的黑群晖系统，在偶尔一次断电重启后，有一个4x2T硬盘的存储空间出现了“已损毁”状态，而网络上搜索到的教程和案例都是使用 Ext4 作为文件系统，那么只需要用 UFS explorer 来修复就好了。偏偏群晖推荐用的是 Btrfs 文件系统，当前状态系统中无法读取文件，但 RAID 并没有异常，无需进行 RAID 清理。通过查看 S.M.A.R.T 状态，发现所有硬盘均处于健康状态，于是跳过这一步。接下来我们需要引导到 Ubuntu 系统并尝试挂载 RAID。
进入Ubuntu系统后第一件事是安装必要的工具包以及挂载 RAID，打开终端并以 root 身份（sudo -i）执行以下操作：
sudo -i
apt-get update
apt-get install mdadm lvm2 btrfs-tools
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 有效，运行结果末尾应当类似于以下图示：
如果最后回显不是以上格式，表明这一条 无效，需要继续尝试下一条。在确认看到以上提示后，我们尝试将数据导出。
此步骤较为重要，请认真阅读理解后操作
此时仍然使用上一步中的 block 值，将 /data5 改为导出目录，需要确保留有足够空间存储文件。如果文件名包含特殊符号可能导致导出中断，将目标分区格式化为 Ext3/4 即可。
btrfs restore /dev/vg1/colume1 /data5 -D -v -i -t <block>
#参数 -D 只测试不执行
#导出数据去掉 -D
如果导出正常进行，会看到类似上图6的提示，此处没有进度提示，可以自行前往导出目录查看。如果导出失败会给出其他提示，在确认导出分区是 Ext3/4 的情况下，则只能退回上一步尝试其他 block 值。
如下图，成功恢复5T左右的数据到/data5目录下:
到目前为止我们并没有对数据盘进行任何写入和修改操作，如果因为种种原因无法导出，或是导出过程异常中断，仍然可以通过修复原盘的方式来挽回数据。不过请注意，此步骤有可能会损坏数据，如果你不能接受任何风险，请停止执行并联系专业机构。
其他方法：
*以下修复步骤博主未亲自测试，请谨慎操作！
*群晖的btrfs一般情况下无法通过如下操作修复成功的，请尝试上边的方法
btrfs check --repair --tree-root <block> --super <sup>
#使用之前步骤中正常回显的 <block> 及 <sup> 值进行正式修复，确认操作完成后执行：
btrfs rescue super-recover /dev/vg1/volume-1提示确认目标分区是 Btrfs 文件系统，否则会损坏数据，输入 y 确认操作。等待数秒后再次回到提示符，如果一切顺利，此时已经可以通过磁盘管理工具挂载 Btrfs 分区了。不过群晖很大几率不会识别修复后的文件系统，还是建议将数据导出后再将硬盘还原。
评论(0)