先给你梳理下目前的状况，然后一步步说可以尝试的修复方向——毕竟Btrfs的超级块和叶子节点损坏确实挺头疼，但你已经能通过btrfs restore的dry run看到预期文件，说明还有很大希望：

• 先检查Btrfs的超级块备份
  Btrfs默认会在三个不同偏移位置保存超级块备份，你可以逐个检查哪个是完好的：

  # 检查第一个备份（偏移64KB）
  btrfs inspect-internal dump-super -s 1 /dev/mapper/vg1-volume_1
  # 检查第二个备份（偏移4MB）
  btrfs inspect-internal dump-super -s 2 /dev/mapper/vg1-volume_1
  # 检查第三个备份（偏移64MB）
  btrfs inspect-internal dump-super -s 3 /dev/mapper/vg1-volume_1
  

  重点看输出里有没有“corrupt”之类的错误提示，找到那个输出正常的备份序号。

• 尝试用完好的超级块备份挂载
  如果找到了可用的超级块备份，直接用它来挂载文件系统：

  # 先创建挂载点
  mkdir -p /mnt/btrfs_recover
  # 替换<备份序号>为你找到的数字（1/2/3）
  mount -o usebackuproot=<备份序号> /dev/mapper/vg1-volume_1 /mnt/btrfs_recover
  

  挂载成功后赶紧把重要数据复制出来，不要继续在原文件系统上操作。

• 尝试修复文件系统（风险操作，先备份！）
  如果超级块备份都用不了，那可以试试btrfs check的修复模式，但一定要先给整个逻辑卷做镜像备份（比如用dd if=/dev/mapper/vg1-volume_1 of=/path/to/backup.img，或者用Clonezilla克隆），之后再执行：

  btrfs check --repair /dev/mapper/vg1-volume_1
  

  执行过程中会输出详细日志，重点关注你dmesg里提到的block=503087104这个损坏块的修复情况，修复完成后再尝试挂载。

• 直接用btrfs restore恢复数据
  要是上面的方法都不行，既然你已经确认dry run能看到预期文件，那就直接跳过挂载，用btrfs restore把数据提取出来：

  # 准备足够大的目标存储，创建恢复目录
  mkdir -p /mnt/recovery
  # 执行恢复，-v显示详细过程，-i忽略损坏的inode
  btrfs restore -v -i /dev/mapper/vg1-volume_1 /mnt/recovery
  

  恢复完成后，检查目标目录里的文件完整性，之后建议重新创建干净的Btrfs文件系统来存储数据，不要继续使用损坏的原文件系统。

额外提醒 #

• 整个过程中绝对不要往原逻辑卷里写入无关数据，避免损坏更多可恢复的内容
• Synology的Btrfs可能带有一些定制属性，恢复后如果遇到权限问题，可以尝试在Synology系统里挂载恢复后的存储来调整权限，或者用chown/chmod批量修改

备注：内容来源于stack exchange，提问作者L. Pinkston