BTRFS 文件系统又挂了？别慌，这几招急救指南请收好

最近看到不少朋友在折腾服务器或者 NAS 时，对 BTRFS 又爱又恨。爱它的快照、压缩和子卷管理，恨它一旦有点“脾气”，直接给你个只读模式或者压根挂载不上。

其实 BTRFS 并没有传说中那么脆弱，很多时候它只是需要一点点“急救处理”。今天我就结合常见的坑，给大家整理一份保姆级的修复指南。手里有数据的，建议先收藏再看。

为什么会“炸”？常见原因分析

在动手修之前，咱们得先知道它为什么会挂。最常见的几种情况无非是以下几类：

图示：系统报错或文件系统崩溃时的常见警示界面

1. 非正常关机/断电：这是最致命的。如果写入数据时突然断电，导致元数据（Metadata）写入不完整，下次开机大概率进不去。
2. 磁盘空间耗尽：BTRFS 对空间的分配机制比较特殊，有时候你还有几十 GB 空闲，但因为“元数据空间”满了，也会导致无法写入，甚至变成只读。
3. 硬件故障：内存条不稳、硬盘坏道，这些都可能导致 BTRFS 校验和失败，进而引发崩溃。
4. 内核版本 Bug：虽然现在的内核已经很稳了，但如果你还在用很旧的 LTS 内核或者追求太新的实验性内核，偶尔也会踩雷。

急救第一步：不要急着写数据！

当你发现系统进不去，或者查看 /var/log/syslog（或 dmesg）看到一堆 BTRFS critical 或 error 时，请遵守第一条铁律：

尽可能挂载为只读模式，不要进行任何写入操作！

任何额外的写入操作都可能把原本能抢救的数据彻底覆盖。

方案一：基础修复（大概率能解决 80% 的小问题）

如果你的问题是开机报错，或者无法读写，先尝试重启进入 Live CD（如果是物理机）或 VPS 的救援模式（Rescue Mode）。

1. 强制只读挂载查看情况

首先，尝试以只读方式挂载，看看能不能看到数据：

mount -o ro /dev/sdXn /mnt/btrfs_rescue

注意：/dev/sdXn 请替换为你实际的分区号。

如果这里能挂载上，恭喜你，数据基本还在。此时赶紧把重要数据通过 rsync 或 scp 拷贝到另一块硬盘上。

图示：数据急救过程中的备份与恢复操作示意

2. 使用 btrfs check 扫描（不要随便加 --repair）

在未挂载的状态下，可以使用 btrfs check 检查文件系统一致性。

btrfs check /dev/sdXn

警告：千万不要直接运行 btrfs check --repair！除非你已经做好了数据全部丢失的心理准备，或者是备份已经确保安全。--repair 是一把双刃剑，它可能会为了修复一致性而删除受损文件。

方案二：进阶修复（针对只读模式或挂载失败）

如果基础挂载失败，或者系统提示 metadata 错误，我们需要祭出大杀器：btrfs rescue。

1. 恢复不可恢复的块

有时候日志记录在某个损坏的 chunk 里，导致无法挂载。我们可以尝试清除日志中的坏块记录：

btrfs rescue zero-log /dev/sdXn

这个命令会清除最后一次未提交的事务日志，通常能解决因为断电导致的挂载失败。执行完之后，再试着挂载看看。

2. 恢复超级块

如果超级块（Superblock）损坏，BTRFS 主分区会认为这不是一个有效的文件系统。好在 BTRFS 在磁盘上备份了多个副本。

btrfs rescue super-recover /dev/sdXn
``

这个命令会尝试扫描并恢复损坏的超级块。

### 3. 恢复 Chunk Tree
如果遇到 `open_ctree failed` 的错误，可能是 Chunk Tree 坏了：

```bash
btrfs rescue chunk-recover /dev/sdXn

这个操作比较耗时，它会尝试重新构建块的映射树。强烈建议执行这个命令前，先用 dd 把整个镜像备份一份到其他地方，以防万一。

方案三：终极手段（只读数据提取）

如果以上方法都试过了，文件系统依然无法正常挂载，但确信硬件没坏，数据还在盘上。这时候我们可以忽略元数据，直接暴力提取文件。

使用 btrfs restore 工具：

mkdir /tmp/restore
btrfs restore /dev/sdXn /tmp/restore

这个命令会尝试绕过文件系统的逻辑错误，尽可能把能找到的文件全部“扒”下来。虽然文件名和目录结构可能会乱一点，或者丢失部分数据，但相比于全军覆没，这已经是最后的救命稻草了。

你可以通过 -t 参数指定恢复某个文件，或者 -l 列出所有文件：

# 先列出文件看看有什么
btrfs restore -l /dev/sdXn

# 尝试恢复特定文件
btrfs restore -t /path/to/your/file /dev/sdXn /tmp/restore

亡羊补牢：日常维护建议

经历过一次“生死时速”后，以后使用 BTRFS 建议养成这几个习惯：

1. 定期 scrub：这相当于磁盘体检，能主动发现并修复静默数据损坏。设个每周一次的 cron 任务就行：btrfs scrub start /mountpoint。
2. 不要用满 100%：BTRFS 的预留空间机制很重要，虽然可以调整，但建议始终保留 15%-20% 的空闲空间，避免“无可分配空间”导致的尴尬。
3. 多盘用 RAID1/10：单盘虽然有 COW，但纠错能力有限。双盘镜像能有效防止硬盘坏道导致的元数据丢失。
4. 及时升级内核：现在的 6.x 内核对 BTRFS 的稳定性支持已经非常好了，别死守着那个 4.19 不放了。

BTRFS 绝对是现代 Linux 文件系统的未来趋势之一，虽然偶尔会耍小性子，但只要你掌握了急救技能，它依然是你折腾数据最好的伙伴。希望这篇指南能帮你把悬着的心放回肚子里！