一次使用 ChatGPT 5.6 sol 自动修复群晖 NAS Btrfs 元数据损坏的实战记录 _ 北京SEO公司_SEO顾问

2026-07-1523:15:55其他杂项18字数 11503阅读38分20秒阅读模式2026-07-15

LocalSync2026-07-15

# 一次使用 ChatGPT 5.6 sol 自动修复群晖 NAS Btrfs 元数据损坏的实战记录

本文记录一次真实的群晖 DSM 7.2.1 故障处理：读写 SSD 缓存中的一块 SSD 故障后，Btrfs 元数据出现系统性校验错误，存储空间被强制切换为只读。整个过程由 ChatGPT 5.6 sol 通过 SSH 辅助完成取证、只读验证、临时 overlay 模拟修复、精确离线写回和启动后验证。

在开始这次尝试之前，我已经做好了最坏的准备：把约 14 TB 数据复制到其他硬盘，再重装 DSM。仅数据迁移、校验和系统重建估计就要花上好几天。抱着“死马当活马医”的心态，我决定先让 GPT 5.6 SOL 尝试修复；没想到从只读取证、SSD 元数据比对、临时 overlay 验证，到正式离线写回并恢复可写，前后大约 9 个小时就解决了问题。

重要警告：本文不是可直接复制的修复教程。物理偏移、逻辑地址、设备名和元数据块均只属于这一台 NAS。照抄写盘命令极可能永久毁坏文件系统。遇到类似问题时，应先备份，并让有经验的人针对本机重新取证。

脱敏说明

本文已对以下信息做统一替换：

NAS 地址：[NAS_IP]
SSH 用户名：[SSH_USER]
SSH 密码：[REDACTED]
博客域名：[BLOG_DOMAIN]
NAS 公网域名：[NAS_DOMAIN]
Btrfs UUID/FSID：[BTRFS_UUID]
本地工作目录：[WORKDIR]

磁盘设备名、Btrfs logical bytenr、物理偏移和校验值予以保留，因为它们是理解取证方法的关键，但它们绝不能用于其他机器。

结论先行

最终结果如下：

RAID5 本身始终保持 clean [UUUU]，不是 RAID 降级或机械盘掉盘。
Btrfs 共暴露出 454 个元数据校验异常 logical bytenr。
其中 444 个节点仍有一份有效的 Metadata,DUP 镜像，可以由 scrub 自愈。
剩余 10 个节点的两份 HDD 镜像全部损坏，是导致文件系统 forced-readonly 的关键。
10 个节点中，8 个在重新插回的两块 SSD 中找到了校验正确的缓存副本。
最后 2 个节点没有现成正确副本，但损坏模式可被确定为固定位置的单比特翻转；在内存中修正后，CRC32C 与节点头部记录完全一致。
使用只读 device-mapper linear overlay 替换这 20 个物理区间后，完整 btrfs check --readonly 可以遍历文件系统，只剩两个非致命的 inode nbytes wrong 统计错误。
经二次明确授权后，离线把 10 个修正节点写入两份物理镜像，共 20 个 16 KiB 块，并逐块回读 SHA-256 验证。
NAS 重启后 /volume1 正常以 rw 挂载，DSM 报告 pool_normal / fs_normal，不再 forced-readonly。
后续 scrub 开始用完好的 DUP 副本修复其余单镜像损坏。

这次恢复没有运行高风险的 btrfs check --repair，也没有重组或加载原 SSD 缓存。

一、事故背景

NAS 使用四块 HDD 组成 SHR/RAID5，文件系统为 Btrfs。为了提高小文件、快照、Active Backup 和 Hyper Backup 的性能，另用两块 SSD 创建了读写缓存，并勾选了 DSM 中的：

将所有 Btrfs 元数据都固定到 SSD 缓存

创建 SSD 缓存时固定全部 Btrfs 元数据

后来其中一块 SSD 报错。我把故障 SSD 取下后，存储空间进入只读状态。数据目录多数还能读，文件看起来也没有大规模丢失，但 DSM 明确提示文件系统异常。

DSM 显示存储空间因文件系统错误进入只读

表面症状：

存储池仍能识别全部四块 HDD。
存储空间显示“只读”。
iSCSI LUN 持续重试 I/O。
容器、备份、日志和索引服务不断尝试访问 /volume1。
DSM 建议备份或迁移数据，但当时没有足够空间做完整备份。

二、最开始的疑问

最初考虑过几个常见方案：

直接运行 btrfs check --repair。
重新安装 DSM。
把 SSD 插回去，尝试重新加载缓存。
备份后重建 RAID/文件系统。

逐项分析后得到：

btrfs check --repair 会直接修改树结构，官方和工具自身都标注危险。在没有验证副本时不能先跑。
重装 DSM 只会重装系统分区，不能修复 /volume1 的 Btrfs 元数据树。
直接加载旧 flashcache 或重组 md3 可能让缓存元数据再次覆盖 HDD，风险不可控。
备份重建仍是最稳妥的标准方案，但当时客观上没有足够备份空间。

因此最终选择了一条更慢但可验证的路径：所有分析先只读；先在临时 overlay 中证明修正有效，再决定是否写回 HDD。

三、第一轮只读检查

3.1 正确使用 `btrfs check`

一开始直接执行：

btrfs check --readonly

工具返回 too few arguments。这是因为必须指定设备，而且应在文件系统卸载后执行：

sudo btrfs check --readonly -P /dev/synorbd_1

本机 DSM 自带的是较旧的 btrfs-progs v4.0。帮助信息明确写着：

WARNING: the repair mode is considered dangerous

所以全程没有在原设备上执行 --repair。

3.2 基础存储状态

只读预检确认：

/dev/md2: RAID5, clean, [UUUU]
/volume1: btrfs, ro
/dev/synorbd_1: 约 27.26 TiB
Btrfs data: single
Btrfs metadata: DUP
SSD cache: DUMMY
ssd dev: (none)
cache reads/writes: 0/0

这组信息非常重要：

HDD RAID 没有降级。
当前缓存层已经退化为 DUMMY 直通，不再读写 SSD。
故障集中在 Btrfs 元数据，不是 RAID5 条带不可读。

3.3 先停止 iSCSI

iSCSI LUN 不断重试 I/O，会制造噪声并增加负载，因此先停止 ScsiTarget，确认客户端断开。之后整个修复和验证期间 iSCSI 都保持关闭。

四、为什么把两块 SSD 插回去有用

用户把两块 SSD 重新插回 NAS 后，没有加载它们，也没有执行：

flashcache_load
flashcache_rescue -w
flashcache_rescue -c
flashcache_rescue -i

只把 /dev/sdg1 和 /dev/sdh1 当成普通只读块设备扫描。

这一步的核心思想不是“恢复缓存”，而是：

把 SSD 当作一份可能保留旧 Btrfs 元数据节点的只读取证介质。

扫描器以 Btrfs FSID、节点头、logical bytenr、generation、owner、level 和 CRC32C 为条件，寻找与 HDD 损坏节点对应的 16 KiB 块。

五、454 个异常节点的分类

首次离线检查日志中提取到 454 个唯一 metadata bytenr。随后根据 Btrfs chunk mapping，把每个 logical bytenr 映射到 HDD 上的两份 Metadata,DUP 物理镜像并读取节点。

结果：

分类	数量	含义
至少一份 HDD 镜像 CRC 正确	444	可由 scrub 使用好副本修复坏副本
两份 HDD 镜像都错误	10	文件系统无法自行修复，是致命点

10 个关键 logical bytenr：

15522122104832
15522144894976
15522327003136
15522516205568
15522558918656
15522585919488
15522742157312
15523016491008
15523023912960
18932942880768

其中 8 个在 SSD 中找到了以下字段全部匹配且 CRC 正确的副本：

FSID
bytenr
generation
owner
level
stored checksum

另外两个是：

15522144894976
18932942880768

SSD 和 HDD 上保存的版本都不能直接通过 CRC。

六、发现系统性的单比特损坏

比较数百个“SSD 正确、HDD 错误”的节点后，差异不是随机坏块，而是高度固定：

16 KiB 节点偏移 4813
偏移 8909
偏移 13005
错误位均为 0x80
正确副本表现为 0x80 -> 0x00

最常见模式统计：

323 个节点：4813 xor 0x80
69 个节点：4813 和 8909 各 xor 0x80
29 个节点：8909 xor 0x80
18 个节点：13005 xor 0x80
2 个节点：8909 和 13005 各 xor 0x80

对最后两个没有正确副本的节点，在内存中只翻转偏移 4813 的 0x80 位，重新计算 CRC32C，结果分别精确等于节点头部原先记录的 checksum。

这不是“猜一个可能值”，而是同时满足：

数百个独立节点呈现同一损坏模式。
两块 SSD 和两份 HDD 副本内容一致。
仅翻转一个位即可让 CRC32C 精确匹配。
bytenr、generation、owner、level 均保持不变。

因此这两个节点可以确定性重建。

七、先制作可回滚修复包

正式操作前生成修复包，内容包括：

10 个修正后的 16 KiB 节点。
每个节点在 HDD 上的两份原始镜像，共 20 个原始块。
logical bytenr 和 physical offset 映射。
来源类型：ssd-valid 或 pattern-reconstructed。
generation、owner、level、stored CRC、computed CRC。
每个文件的 SHA-256。
JSON manifest。

远端包与下载到本地的 tar 归档 SHA-256 一致：

693b42f6cc3734e3bdcef31f3e7b89d2fff3ff94cc5d11b519ae5b9e5468387e

注意：这个哈希只用于记录本次案例，其他机器绝不会相同。

八、卸载卷时踩过的坑

为了运行离线检查，首先尝试正常停止占用者并卸载 /volume1。实际遇到的占用包括：

SMB
Synology Finder / synoelasticd
Active Backup
Snapshot Replication / s2s_daemon
Log Center
alist
Container Manager
WebDAV Server
Tailscale
Docker 的 /volume1/@docker 子挂载

踩坑过程：

synopkg stop 返回成功，不代表 systemd 子单元已经停止。
pkg-SynoFinder-synoelasticd.service 会继续持有数百个索引文件 FD。
Docker 有两个子挂载，必须按最深路径优先正常卸载。
普通 FD/CWD 扫描不够，还要检查 executable、memory maps 和 mount namespace。
即使用户态引用归零，DSM 仍可能让普通 umount /volume1 返回 busy。
synostgvolume --unmount -p /volume1 可以通过 DSM 离线框架停止依赖，但会连 SSH 一起停掉，所以必须使用放在系统根分区上的自包含脚本。

整个过程中没有使用 umount -f 或 lazy unmount。

九、临时 overlay 验证

9.1 dm-snapshot 方案失败

最初计划使用 2 GiB 稀疏 COW 文件和 device-mapper snapshot：

origin: /dev/synorbd_1
cow: loop device
snapshot: /dev/mapper/btrfs_overlay_test

但 DSM 内核拒绝让 dm-snapshot 引用仍挂载的 origin，返回：

Device or resource busy

即使 origin 已设为块级只读也一样。

9.2 精确只读 linear overlay

进一步确认存储路径：

/dev/synorbd_1
  -> cachedev_0 (flashcache-syno, DUMMY, no SSD)
  -> /dev/vg1/volume_1
  -> /dev/md2

对 20 个目标物理块逐一比较：

/dev/synorbd_1
/dev/mapper/cachedev_0
/dev/vg1/volume_1

三层容量和 SHA-256 完全一致，证明 DUMMY cache 是 1:1 直通。

于是构造一个完全只读的 dm-linear 设备：

绝大多数扇区映射到 /dev/vg1/volume_1 的同一偏移。
仅 20 个 16 KiB 区间映射到一个 320 KiB 的修正块文件。
device-mapper 设备以 --readonly 创建。
生成 41 段 linear table。

验证结果：

readonly_overlay_verified blocks=10 origin_unchanged=20
overlay_ro=1
origin_ro=1

也就是说，检查程序看到的是“假设 10 个节点已经修好”的完整文件系统，而 HDD 一字节未改。

十、overlay 上的完整只读检查

执行：

btrfs check --readonly -P /dev/mapper/btrfs_overlay_test

检查依次通过：

checking extents
checking fs roots

最终摘要：

found 16202897543184 bytes used err is 1
root 256 inode 15764557 errors 400, nbytes wrong
root 256 inode 23594450 errors 400, nbytes wrong

没有发现：

bad tree block
corrupt tree
failed to read
extent item/backref mismatch
root tree 断裂

这说明 10 个修正块足以消除导致文件系统不可遍历的致命错误。剩下两个 inode nbytes wrong 是 inode 统计字段不一致，不是节点丢失；本次不冒险用全局 --repair 处理。

临时修复验证后的阶段性总结

十一、二次授权后正式写回

在用户明确回复“现在正式应用修复”后，才进入原盘写入阶段。

正式脚本放在系统根分区，流程如下：

再次验证 overlay 最终结果只包含两个已知 nbytes wrong。
确认没有 btrfs check 进程。
确认 RAID5 clean 且 degraded=0。
调用 DSM 官方离线框架：

bash synostgvolume --unmount -p /volume1

确认 /volume1 和 /dev/synorbd_1 已完全无挂载。
写前逐块读取 20 个物理位置，并确认 SHA-256 等于备份。
把 10 个修正节点分别写入两份 Metadata,DUP 镜像。
使用同步写入并执行 fsync。
写后逐块回读，确认 20/20 SHA-256 等于修正块。
成功后自动重启，让 DSM 按正常启动流程重新挂载卷。

关键日志：

pre_write_verified blocks=20
written ... blocks=20
post_write_verified blocks=20
formal repair write verified

不要复制本文中的 bytenr 或物理偏移。Btrfs 每台机器的 chunk mapping 都不同。

十二、重启后的成功结果

重启后检查：

/volume1: btrfs rw
summary status: pool_normal
original status: fs_normal
/dev/md2: clean [UUUU]
write_io_errs: 0（首次验证时）
read_io_errs: 0（首次验证时）
corruption_errs: 0
generation_errs: 0
本次启动无 forced readonly
iSCSI: inactive

最重要的是：DSM 已恢复正常可写，原来导致灾难的 10 个双镜像损坏节点已经修复。

十三、为什么还需要 scrub

精确写回只解决了 10 个“两份镜像全坏”的节点。另有 444 个节点是一份坏、一份好。

Btrfs scrub 会：

读取数据和元数据。
按 checksum 检查内容。
如果一份 DUP 镜像坏、另一份好，用好副本修复坏副本。
记录不可纠正错误。

它不是：

btrfs check --repair
RAID 重建
备份
SSD 缓存恢复

scrub 日志中开始出现：

BTRFS: read error corrected

证明它确实在修复剩余坏副本。

十四、过热关机插曲

第一次 scrub 运行约 34 分钟后，NAS 页面、SSH、SMB 等所有服务端口都不可访问，但 Ping 仍通。当时一度怀疑 scrub 导致 DSM 卡死。

后来 DSM 通知明确给出真实原因：硬盘 2 温度超出工作范围，NAS 因硬盘过热自动关机。

DSM 通知显示硬盘过热并自动关机

被中断的 scrub 状态：

interrupted after 00:34:02, not running
total bytes scrubbed: 582.38 GiB
约 3.87%
0 uncorrectable errors

系统开机后 scrub 不会自动继续，需要手动重新开始。DSM 中对应的功能叫“数据清理”。

DSM 的数据清理入口

手动运行后：

DSM 显示数据清理正在运行

重新开始时的温度：

HDD 1: 51 C
HDD 2: 50 C
HDD 3: 47 C
HDD 4: 45 C
SSD 1: 30 C
SSD 2: 30 C

这提醒我们：scrub 会制造持续全盘 I/O。它不一定是故障根因，但会显著增加发热。应先清灰、检查风扇、改善硬盘仓通风并使用较高风扇档位，再安排 scrub。

十五、事故根因分析

15.1 “固定全部 Btrfs 元数据”扩大了影响面

正常设计下，两块 SSD 组成 RAID1 读写缓存，坏一块应能降级运行。因此事故不能简单归结为“勾选框一定有 bug”。

但在读写缓存中固定全部 Btrfs 元数据，会让文件系统最关键、最活跃的树节点长期处于缓存路径。一旦 SSD、缓存 RAID、掉电或缓存卸载流程异常，故障影响可能从：

缓存失效、性能下降

升级为：

关键元数据副本同时不可用 -> transaction abort -> forced readonly

本次 HDD 上大量节点出现相同位置的 0x80 单比特错误，而 SSD 上保留了正确版本，说明缓存故障或退出过程中发生了系统性错误写回/未完成写回。

对于没有完整备份、可靠性优先的 NAS，这个性能选项不值得开启。

15.2 RAID 正常不等于文件系统正常

RAID5 的 [UUUU] 只说明四块成员盘在线、阵列条带可读，不代表 Btrfs 元数据 checksum 和树结构正确。

15.3 “文件还读得到”不等于风险轻

Btrfs 是 COW 树结构。一个看似无关的元数据叶节点损坏，可能只在删除、快照、回收 extent 或提交事务时被访问。一旦事务关键路径读到两份都坏的节点，整个文件系统可能被强制只读。

十六、主要踩坑记录

btrfs check --readonly 需要设备参数。
不要在挂载卷上运行 btrfs check。
不要把 --repair 当作第一步。
停止套件不等于所有子服务停止。
检查占用要覆盖 FD、CWD、EXE、mmap、子挂载和 mount namespace。
不要使用强制/lazy unmount 掩盖占用。
不要为了找缓存数据而重新加载旧 flashcache。
SFTP 在本机 DSM 被禁用，最终改用 SCP。
dm-snapshot 无法直接引用已挂载 origin。
DUMMY cache 下层是否 1:1，必须逐块验证，不能假设。
只读 overlay 是正式写回前最有价值的保险。
远端命令超时不代表任务没有启动。 scrub 命令超时后实际仍在运行。
服务不可访问不一定是文件系统再次损坏。 本次是硬盘过热关机。
scrub 前必须解决散热问题。
恢复可写后应先稳定观察和备份，再单独确认是否启动高负载 scrub。

十七、可复用的安全决策流程

下面是可以迁移到其他案例的原则，不包含任何可照抄的物理写入：

1. 停止产生重试 I/O 的业务（例如 iSCSI）
2. 确认 RAID、LVM、cache device 和 Btrfs 的实际拓扑
3. 保持原设备只读
4. 离线运行 btrfs check --readonly
5. 提取损坏 logical bytenr
6. 根据 chunk mapping 检查每份物理镜像
7. 搜索其他只读介质中的候选副本
8. 验证 FSID/bytenr/generation/owner/level/CRC
9. 制作原始块备份、修正块和 manifest
10. 在只读 overlay 上完成全量检查
11. 只有验证结果清晰且获得明确授权后，才考虑离线精确写回
12. 写前校验、同步写入、写后回读、重启验证
13. 文件系统恢复后，用 scrub 修复剩余可恢复副本
14. 最终仍应建立真正的独立备份

十八、建议的长期配置

不再勾选“将所有 Btrfs 元数据固定到 SSD 缓存”。
优先使用只读 SSD 缓存；缓存损坏最多损失性能。
如果必须用读写缓存：使用带断电保护的企业级 SSD、RAID1、UPS，并保留独立备份。
SSD 报错后，通过 DSM 正常停用缓存，不要直接拔盘。
定期执行数据清理，但放在维护窗口并监控温度。
重要数据至少保留一份不依赖当前 NAS 的备份。
为硬盘温度、SMART、风扇和 SSD 寿命设置告警。

十九、脱敏后的完整对话记录

以下记录按原对话顺序整理。为便于阅读，删除了重复的终端进度行和工具内部调用，但保留了所有决策、用户授权、错误、结论和关键输出。

阶段 A：发现只读故障

用户：

我的群晖 NAS 报错了，可能是基础文件系统错误。之前用两块 SSD 做缓存，并把文件系统基础文件写到 SSD 上，其中一块 SSD 报错后被取下。请通过 SSH 做只读分析。地址 [NAS_IP]，用户 [SSH_USER]，密码 [REDACTED]。

助手：

先进行只读预检，不运行 repair、scrub、balance、mdadm 写操作或缓存重组。确认 RAID、设备映射、卷挂载模式、Btrfs 日志和活动进程。

用户：

没有足够空间做完整备份，希望通过文件系统修复。参考了一篇 DSM 7 文件系统损坏修复文章。

助手：

文章中的流程只能作为背景。必须先区分 RAID、LVM、缓存层和 Btrfs 的具体错误，不能直接套用 btrfs check --repair。

用户：

btrfs check --repair 是干什么的，能修复文件系统错误吗？

助手：

它会尝试修改 Btrfs 内部树结构，确实能修复部分一致性错误，但工具明确标记为危险。错误根、错误版本或硬件 I/O 问题下可能让可恢复数据变得不可恢复，所以不能作为第一步。

用户：

搜索 Btrfs 元数据校验失败导致 forced readonly 的解决办法。

助手：

forced-readonly 通常是事务提交路径遇到不可恢复元数据错误后的保护动作。应先停止写入、确认硬件和冗余副本，再离线只读检查。

用户：

执行 btrfs check --readonly 后提示参数不足。

助手：

必须指定未挂载的块设备，例如：

btrfs check --readonly -P /dev/synorbd_1

用户：

请按最安全的步骤操作修复。

助手：

先停止业务 I/O、收集只读证据、卸载后运行只读检查。任何原盘写入都需要第二次明确确认。

阶段 B：停止业务与重启

用户：

VMware/Hyper-V iSCSI LUN 正在连续重试 I/O，停掉这个服务。

助手：

停止 ScsiTarget，并确认 iSCSI 客户端断开。

用户：

iSCSI 已断开。给 NAS 重启一下。

助手：

执行受控重启，开机后重新确认 RAID 与挂载状态。

用户：

已开机。把两块 SSD 装回去会有帮助吗？

助手：

有可能，因为 SSD 上可能保留有效元数据副本。但只能把它们作为只读取证介质，不能重新加载缓存或执行 flashcache rescue 写操作。

用户：

除了备份重建 RAID，还有别的办法吗？数据没丢，为什么少量损坏会造成这么严重的后果？重装 DSM 有帮助吗？

助手：

少量关键元数据节点可位于事务、extent 回收或根树路径上，两份副本同时损坏即可迫使整个卷只读。重装 DSM 不会修复数据卷 Btrfs。可尝试从冗余副本或 SSD 缓存恢复，但必须先证明副本正确。

阶段 C：SSD 取证

用户：

两块 SSD 已插回，请检查能否恢复元数据。好了没？请给明确结论，能恢复就先规划，我说 OK 再做。

助手：

结论：454 个异常节点中，444 个有有效 HDD 镜像；10 个两份都坏。8 个有 SSD 正确副本，2 个可以由固定单比特模式确定性重建。规划先制作修复包，再在临时 COW/overlay 上验证，不写 HDD。

用户：

OK。

阶段 D：修复包和 overlay

助手：

生成 10 个修正块、20 个 HDD 原始镜像和 manifest。本地与 NAS 端归档 SHA-256 一致。

随后尝试停止卷占用者，依次识别 SMB、Active Backup、Log Center、Snapshot Replication、SynoFinder、Docker、Tailscale、WebDAV 等服务。普通卸载仍 busy。

dm-snapshot 因 origin busy 失败。最终确认 DUMMY cache 下层 1:1 后，使用 41 段只读 dm-linear overlay，把 20 个区间映射到 320 KiB 修正文件。

overlay 验证：

readonly_overlay_verified blocks=10 origin_unchanged=20

完整只读检查最终只剩两个 inode nbytes wrong。

阶段 E：正式写回

用户：

很好，现在正式应用修复。

助手：

这构成第二次明确授权。等待 overlay 检查自然结束后，通过 DSM 离线框架卸载卷，写前确认 20 个原始哈希，写入 20 个修正物理块，fsync 并回读验证，然后自动重启。

正式日志：

pre_write_verified blocks=20
post_write_verified blocks=20

重启后 /volume1 为 rw，DSM 为 pool_normal / fs_normal，RAID5 为 clean [UUUU]，不再 forced-readonly。

阶段 F：SSD 元数据固定选项

用户：

当时勾选了“将所有 Btrfs 元数据固定到 SSD 缓存”，然后一块 SSD 挂了。现在看来不应该勾选，对吗？

助手：

对于没有完整备份、可靠性优先的 NAS，不建议勾选。选项本身在正常 RAID1 缓存下不应因坏一块 SSD 就毁坏文件系统，但它显著放大了缓存故障的影响面。

阶段 G：scrub、过热与重启

用户：

查看 scrub 进度。

助手：

首次查询：34.77 GiB，约 0.23%，0 个不可纠正错误。随后 NAS 只响应 Ping，DSM/SSH/SMB 全部关闭。

用户：

其实 DSM 页面此前已经正常，是不是不应该再做其他操作？

助手：

恢复可用后应先稳定观察和备份。scrub 最终有必要修复 444 个坏副本，但它是高负载维护操作，应该单独确认并安排维护窗口，而不是立即追加。

用户：

DSM 页面拒绝连接。

助手：

确认所有服务端口都关闭但 Ping 正常。建议不要拔电，优先受控关机。

用户：

scrub 是什么意思？查看进度。

助手：

scrub 是 Btrfs 全盘校验与副本自愈。查询显示任务因关机中断，扫描 582.38 GiB，约 3.87%，0 个不可纠正错误，卷重新以 rw 挂载。

用户：

之前是硬盘温度过高自动关机，不是 scrub 导致。系统开机后会自动执行 scrub 吗？

助手：

不会自动继续。当前状态明确为 interrupted, not running。先解决散热，再手动重新开始。

用户：

DSM 里的“数据清理”就是 scrub 吗？我点了手动运行。

助手：

是。新任务运行 2 分 21 秒时扫描 62.76 GiB、0 错误；HDD 温度为 51/50/47/45 C，建议提高风扇并持续监控。

阶段 H：WordPress 容器恢复

用户：

以前 Docker 中运行的 WordPress 博客打不开了。

助手：

检查发现 Container Manager、WordPress、MySQL 和 Redis 都已运行。WordPress 映射为 NAS:7080 -> container:80，本地和公网域名均返回 HTTP 200。之前不可用主要是重启后 MySQL crash recovery 和容器启动需要时间。

用户：

最终域名是 [BLOG_DOMAIN]，忘记当时怎么实现的。

助手：

DNS 开启 Cloudflare 代理；NAS 上 Lucky 容器使用 host 网络并启用反向代理；WordPress 后端监听 7080。链路为 Cloudflare -> 路由器端口映射 -> Lucky -> 127.0.0.1:7080 -> WordPress。

二十、写在最后

这次事故最值得保留的经验不是某条“神奇修复命令”，而是验证顺序：

先证明 RAID 正常，再定位 Btrfs；先找副本，再谈修复；先在 overlay 中证明，再触碰原盘；任何写入都要有原始块备份、写前哈希和写后回读。

如果没有 SSD 中残留的正确节点、没有高度一致的单比特模式，或者 overlay 检查出现新的树结构错误，这次修复就不应进入正式写回阶段，而应回到备份、镜像和专业数据恢复路线。

热门搜索

脱敏说明

结论先行

一、事故背景

二、最开始的疑问

三、第一轮只读检查

3.1 正确使用 btrfs check

3.2 基础存储状态

3.3 先停止 iSCSI

四、为什么把两块 SSD 插回去有用

五、454 个异常节点的分类

六、发现系统性的单比特损坏

七、先制作可回滚修复包

八、卸载卷时踩过的坑

九、临时 overlay 验证

9.1 dm-snapshot 方案失败

9.2 精确只读 linear overlay

十、overlay 上的完整只读检查

十一、二次授权后正式写回

十二、重启后的成功结果

十三、为什么还需要 scrub

十四、过热关机插曲

十五、事故根因分析

15.1 “固定全部 Btrfs 元数据”扩大了影响面

15.2 RAID 正常不等于文件系统正常

15.3 “文件还读得到”不等于风险轻

十六、主要踩坑记录

十七、可复用的安全决策流程

十八、建议的长期配置

十九、脱敏后的完整对话记录

阶段 A：发现只读故障

阶段 B：停止业务与重启

阶段 C：SSD 取证

阶段 D：修复包和 overlay

阶段 E：正式写回

阶段 F：SSD 元数据固定选项

阶段 G：scrub、过热与重启

阶段 H：WordPress 容器恢复

二十、写在最后

3.1 正确使用 `btrfs check`