btrfs, linux

如何恢复BTRFS分区

免责声明:对于因遵循本指南而导致的任何数据丢失,我不承担任何责任。试着随时了解自己在做什么,不要’t未经仔细阅读而复制粘贴命令。

BTRFS是用于保存数据的出色文件系统。这是现代的 写时复制 具有增强的数据完整性机制的文件系统可避免 静默数据损坏, 可以是快照 远程同步和transparent data compression.

与任何其他COW文件系统一样,要付出的代价来自写入性能。由于每次写操作还需要进行读取和复制操作,因此COW文件系统在执行频繁写操作的负载(例如某些数据库应用程序)中的性能较差。

防止驱动器故障的最专业方法是使用 袭击,这是BTRFS本身支持的。这显然要付出金钱的代价,并且对于许多不起眼的架构而言,对性能的影响很大。因此,在本文中,我们将重点介绍非RAID情况。

当驱动器发生故障时

我们的自助主机和数据and积迟早要面对这样的情况,即我们必须从发生故障的硬盘驱动器中恢复数据。所有驱动器迟早都会发生故障。

这可能是一个戏剧性的情况,绝对没有乐趣。 BTRFS很复杂,还原过程可能会令人困惑。重要的是要保持冷静,不要沮丧,并认为BTRFS会尽力避免丢失或破坏数据。如果BTRFS没有’让我们挂载该分区,或者如果系统成为只读是有充分理由的。

通常情况是由硬件故障引起的,因此我们的首要目标是在驱动器完全失效之前尽快取出数据。

根据损坏的范围,我们可能会处于不同的情况

  • 如果数据本身已损坏,则文件的某些部分将包含错误或不可访问的数据。如果是这种情况,我们将在日志中看到校验和错误。在某种程度上,BTRFS能够恢复某些信息,因为其固有的 冗余,我们可以通过 擦洗.
[ 1901.435050] BTRFS error (device sda1): bdev /dev/sda1 errs: wr 0, rd 0, flush 0, corrupt 11382, gen 0
[ 1901.435062] BTRFS error (device sda1): unable to fixup (regular) error at logical 13787648000 on dev /dev/sda1
  • 如果 日志 不一致,BTRFS将不允许我们以写许可权挂载驱动器。每当写操作被中断而日志日志没有中断时,就会发生这种情况。’没有足够的信息来保证数据完整性。根据我们要讨论的数据,这可能是好的,也可能是非常糟糕的。如果硬件没有故障,但是不幸的是断电,我们可以选择接受数据丢失。为了丢弃不完整的交易,我们使用 btrfs救援 zero-log.
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
  • In case that the superblock is affected, we will not be able to mount at all. The superblock is the root of the filesystem tree and contains the information that the operating system needs to mount the unit. This is normally easy to fix because BTRFS saves extra copies at different locations, so we might be able to mount using a copy of a superblock, 要么 even run btrfs救援 super-recover to try to fix it.
[11152.189762] BTRFS: failed to read chunk tree on sda
[11152.196224] BTRFS: open_ctree failed 
  • 同样,即使实际数据可能完好无损,文件系统元数据也可能受到损坏。这意味着BTRFS不会’t know about the existence of files 要么 parts of files so we have no way to access them. In this scenario, if we react quickly, we can scan the whole disk and try to rebuild the filesystem metadata tree with btrfs救援 chunk-recover. Needless to say this is both risky and very slow.
[19409.487603] BTRFS error (device sda1): bad tree block start 11106478115207782198 875249664
[19412.395884] BTRFS error (device sda1): bad tree block start 11106478115207782198 875249664

让我们看看什么是通用程序。

做好准备

规则零当然是为了 有备份。这将使我们在晚上睡个好觉,并用低得多的头部处理不良的驾驶情况。我可以’强调一下:在两个不同的位置至少有三份。当驱动器发生故障时,一切都会变得更加轻松,压力也将减轻。

然后,第一规则是 监控硬盘’s health。这也很重要,因为通常您会在完全失败之前至少24或48小时收到警告,因此您很有可能在太晚之前就将数据移出那里。硬盘不要’从一天到另一天完全失败,但我们需要注意它们。

下一页CloudPi中的SMART错误

如果您没有备份,或者要尝试恢复上次备份之后修改的数据,请继续阅读。

可安装驱动器的步骤

因此,您收到了警告,这是卸载驱动器并在其性能持续下降之前将其关闭的第一件事。然后,在开始以下步骤之前,请查找这篇文章并研究您的策略。您的驱动器可能只剩下几个小时了。

First, mount your drive in read only mode, and try to copy your data out normally. If it is the root filesystem, boot from a live CD and proceed to repair from there. Keep a terminal open with the 核心 logs dmesg -w, and watch out for errors like this

[386229.214384] BTRFS warning (device sda1): sda1 checksum verify failed on 568344576 wanted B77C6306 found D884C20D level 0
[386229.223445] BTRFS warning (device sda1): sda1 checksum verify failed on 568344576 wanted B77C6306 found BB7B11CF level 0

如果某些文件位于损坏的区域中,则某些文件可能无法复制,或者某些文件似乎可以正常复制,但会在内核日志中引发错误。一张一张地复制您的主文件夹。尝试首先复制最有价值的内容,并记下日志信息中可能损坏的内容。

接下来,让’s try to repair as much as we can. For this we will first try 擦洗 with btrfs擦洗. This is will check for data integrity using checksums and will try to recover the damaged data. 擦洗 被认为是安全的,通常是第一件事。

运行它

# btrfs擦洗 start /mnt

,并跟踪进度

# btrfs擦洗 status /mnt

这通常需要几个小时

这将尽其所能解决,但可能无法解决所有问题。再次尝试将以前有错误的内容复制到安全上。也许我们将修复许多文件,甚至可能修复所有文件。

If you get errors 通过 inode in the logs like this

[ 5488.731343] BTRFS warning (device sda1): csum failed root 5 ino 40913 off 28815360 csum 0xf4702fd5 expected csum 0xfe7c816f mirror 1
[ 5488.731830] BTRFS warning (device sda1): csum failed root 5 ino 40913 off 28815360 csum 0xf4702fd5 expected csum 0xfe7c816f mirror 1
[ 5488.732189] BTRFS warning (device sda1): csum failed root 5 ino 40913 off 28815360 csum 0xf4702fd5 expected csum 0xfe7c816f mirror 1

,如果元数据未损坏,则可以查看该文件对应的文件

# btrfs inspect-internal inode-resolve 40913 /mnt


如果没有挂载

如果 superblocks are damaged the partition will not mount. Try first to fix the partition as above with btrfs擦洗, then you might be able to mount it and proceed with the steps above.
在清理还不够的情况下,我们可以尝试以只读模式使用根树的备份,’更改数据是完全安全的。

# 挂载-o usebackuproot /dev/sdXY /mnt

尽量节省

这些步骤通常效果很好。如果上面没有’因此,就没有完全安全的方法来取回数据。我们必须设法获得尽可能多的收益,并记住,我们所恢复的东西很可能至少部分被破坏。

此时最好的方法是运行 btrfs 恢复

# btrfs 恢复 /dev/sdXY /mnt/

This is completely safe and will try its best to mount a read only version of the data in /mnt that is as sound as possible. For instance, a file could be mounted without integrity errors but be in an old version from an old snapshot. Still worth trying to get out this information before trying out potentially destructive tools.

If we are still not able to mount normally, we can now run btrfs救援 super-recover, which will try to 恢复 the superblock from a good copy. This is not completely safe.

As mentioned before, if your metadata was corrupt there is a chance that files 要么 part of files that are not damaged are not seen 通过 the filesystem. In this scenario, we can use btrfs救援 chunk-recover /dev/sdXY to scan the whole drive contents and try to rebuild the metadata trees. This will take very long specially for big drives, and could result in some of the data being wrongly 恢复d.

绝对不得已

We are used to doing fsck 要么 文件系统检查 一看到奇怪的东西 ext4。好吧,唐’t do this in BTRFS. btrfs检查 should be the last resort as it will try hard to 恢复 the filesystem and there is a 很有可能使事情变得更糟.

虽然上述命令很少会造成更多损坏,但有些命令例如 擦洗 要么 恢复 是完全安全的,这很可能会使事情搞砸。我们必须先了解这一点,然后再遵循我们的 ext4 本能。

# btrfs检查 --repair /dev/sdXY

验证您的副本

将所有数据移至安全位置后,我们可能需要将其与备份进行比较,以查看备份中缺少哪些信息。

通常,备份中的信息比我们尝试从发生故障的驱动器中保存的信息更值得信赖,因此理想情况下,我们只希望使用自上次复制以来添加或修改的新数据来更新备份。

为此,以下命令将非常方便。第一条命令只会比较文件名

$ rsync --dry-run -ri --delete --ignore-existing /copy/ /old-backup/

,这将比较两个文件夹中每个文件的校验和

$ rsync --dry-run -ri --delete --checksum /copy/ /old-backup/

Naturally the latter can take a while. Neither of those commands modify any actual data, if you want to proceed, remove the --dry-run parameter.

结论

我希望这篇文章能帮助您理解好的战略可能是什么样子,并能理解BTRFS必须提供的各种恢复工具和选项。

作者: 纳乔帕克

谦虚地分享我认为有用的东西 [ 的github 码头工人hub ]

11 评论s

  1. 感谢您的出色文章。不幸的是我发现这为时已晚。我已经从备份中恢复了损坏的btrfs。

    我看到你建议跑步“btrfs scrub” if you can’t安装fs。但是scrub仅在已安装的文件系统上运行。至少在我的Debian不稳定的内核4.19和btrfs-progs 4.20.2

    1. I have the same problem as you, the disk is not mountable so I cannot use btrfs擦洗.
      有什么想法吗?

      谢谢您的帮助

  2. 我在重新格式化磁盘之前的最后一刻找到了这篇文章。
    btrfs 恢复 / dev / sdXY / mnt /为我工作!大。
    现在,我对如何将/ mnt复制到原始硬盘存有疑问。
    你能帮助我吗?
    谢谢,您为我节省了两个多月的工作。

  3. 哇!这应该作为btrfs手册的一部分进行记录。我想问一个条件。在我目前的情况下,’擦洗或检查时没有错误–修理,我什至可以完美地平衡。但是,在每次安装时,损坏的值永远不会为0,而wr,rd,flush会执行(gen有时也不为0,但是’小于10的值)。这是一个实际问题的信号还是我可以忽略的东西?谢谢。

  4. 十分感谢。
    就我而言‘挂载-o usebackuproot’帮助解决了我无法安装文件系统的问题。
    我无法通过以下任何方式修复它‘btrfs check’ and ‘btrfs rescue’ options.
    btrfs-progs从4.15.1升级到5.1(Ubuntu 18.04 Bionic升级到19.10 Eoan)也无济于事。
    卸载之后,系统可以按常规方式安装,因此我重新插入了‘crashed’卷回到Synology DSM,后者又高兴地看到它再次变成绿色。

  5. 我现在在一组环路设备上试验btrfs两个小时。在少数带有-o的安装降级之后,擦洗显示数千个‘uncorrectable errors’. Guys –您绝对应该尝试使用ZFS。上周,我终于用两个磁盘上的一千多个已纠正错误替换了两路镜像安装的两个故障磁盘,完全没有数据丢失。

    对于海量存储,我将LizardFS与ZFS存储支持的块服务器一起使用,其中ec(4,2)用于个人数据,xor5用于其他(非关键)数据。

    请记住,Btrfs最初是Oracle文件系统,是为了与ZFS竞争而开发的。

    照顾自己,
    马辛。

  6. 在Windows上,我安装了btrfs支持,并且我使用了迷你工具分区管理器,它出现并说gpt分区在btrfs驱动器上不好,我说要修复它。但这导致btrfs驱动器不再可启动,并且出现错误
    上级过渡编号失败。….. wanted… found…
    忽略无效故障
    无法建立范围树
    错误无法打开ctree
    ———————————

    曾经发生过的事情不再是可挂载的奇怪事情,因为它以前运行良好。即时通讯不确定发生了什么变化,驱动器上没有物理错误。
    我已经尝试了所有可以找到的恢复方法。如果您想将btrfs连接到windos机器,并从Windows中的某些分区程序得到关于gpt的错误提示,请不要让它修复它。

  7. Thanks a lot! My system 坠毁 and one of the partitions got damaged. With ‘btrfs恢复/ dev / sdaX / MOUNTPOINT’我取回了数据ðŸ™,

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *