2026-09-27 · 约 6 分钟
Btrfs 对数据与元数据都计算校验和，读取时验证，发现损坏利用冗余副本自动修复。它检测的是"静默数据损坏（bit rot）"：把"损坏后无感"变成"损坏即发现"。
①scrub 不是 fsck，不修树结构一致性；②无冗余（single）时校验失败只能报 EIO，靠备份；③NOCOW 文件无校验（chattr +C 隐式禁用，systemd 日志/libvirt 存储池默认就设了 +C），此类损坏无法自愈。
scrub=校验级巡检（每月一次、换盘前必做）；btrfs-restore=无冗余时只读救文件；btrfs check=专家指导下重建结构，不可对运行中的池直接执行。
断电后池只读或无法挂载；RAID 降级重建中断；SMART 报坏道 scrub 反复报错；误删共享文件夹/快照想找回历史版本。
校验失败提示的是某块数据与记录的校验值对不上，而挂载失败、目录读不出来通常意味着元数据树出了问题。两者的处理顺序不同，判断错方向会白费功夫。
有冗余的数据块错误可以由系统自行纠正，元数据树的问题则要先保护现场，再考虑用只读方式把还能解析的内容导出，避免在受损结构上反复尝试写入。
这类设备上跑的是阵列加文件系统的组合，盘掉线、阵列降级与文件系统层面的损坏可能同时出现。要先把阵列按原参数组装出完整地址空间，再谈文件系统层怎么解析。
跳过前一步直接去修文件系统，等于在错误的数据上做无用功，还可能把可用的元数据改掉。槽位顺序和阵列参数要先记录清楚。
多数可以。只读是文件系统自我保护，数据块通常完好。切勿强行写回或格式化，先只读镜像评估。
不一定。有 RAID1/DUP 冗余通常能自愈；无冗余时数据可能仍在，需只读提取。
底层都是 Btrfs（部分机型 ext4），结构一致但版本布局有差异，需各自元数据解析。
镜像 1-3 天，提取修复 1-3 个工作日。免费检测。
可以尝试。快照保存的是某个时间点的目录状态，如果损坏发生在快照之后，从快照里取出的文件通常是完整的。注意导出目标不能是同一个存储池，否则新写入会继续搅动已损坏的结构。
先别反复开关机，也不要急着重建阵列或格式化。把盘按原槽位标记好，记录阵列类型与盘的数量，再交给能解析该文件系统的机构先做一份只读副本；顺序错了会白白丢掉可用的元数据。
群晖、威联通 NAS 上的 Btrfs，常被宣传成"能自愈"。自愈的前提是校验和还在、 且存在冗余副本或校验盘——少了任何一个，Btrfs 只会告诉你"这块数据坏了"，救不回来。
| 项目 | 取值 / 位置 | 说明 |
|---|---|---|
| 超级块副本 | 偏移 64KiB、64MiB、256GiB 各一份 | 主超级块坏了先读这几处 |
| 超级块魔数 | `_BHRfS_M` | 位于超级块偏移 0x40 处 |
| 默认校验算法 | crc32c（也可选 xxhash/sha256） | 校验和存在，才有自愈的依据 |
| 数据与元数据模式 | single / dup / raid0 / raid1 / raid10 / raid5 / raid6 | 只有 dup 或带校验的 RAID 布局才有第二份副本 |
| scrub 作用 | 后台读取并按校验和比对，发现错误从副本修复 | 无副本时只能报告，不能修复 |
# 只读检查（绝不加 --repair，修复要人工判断）
btrfs check --readonly /dev/sdX1
# 查看设备与校验状态
btrfs filesystem show /dev/sdX1
btrfs device stats /dev/sdX1
# 已有挂载时看 scrub 结果（只读查询）
btrfs scrub status -R /mnt/data真正需要人工介入的情况：元数据树损坏但数据块完好——这时应该把整组盘做成镜像后 离线重建目录树，而不是在挂载状态下反复 scrub，因为 scrub 会写回"修复"结果， 一旦它选错了副本，原盘上的正确版本就没了。
参数判定、镜像方案、固件损坏这类问题，聊清楚不收钱；需要现场检测、书面报价或上门，统一走 项目1 服务页（到店免费检测，出报告后报价，不出结果不收费）。
18620311365
深圳市福田区深南中路2070号电子科技大厦A座35楼D22（华强北地铁站D1口步行320米）