黑群晖重启后 Basic 存储池显示“已损毁”的排查与恢复

黑群晖重启后 Basic 存储池显示“已损毁”的排查与恢复

前言

本文记录一次黑群晖裸机重启后，硬盘健康状态显示“良好”，但 Basic 存储池却显示“已损毁”、数据卷被只读挂载的排查过程。

这次故障并不是典型的硬盘坏扇区问题。Linux MD 阵列仍能识别数据分区，Btrfs 文件系统也可以读取，但阵列成员被标记为 faulty，DSM 因此将存储池判定为损毁，并以只读方式挂载数据卷。

重要提醒：本文涉及 mdadm 阵列操作。命令中的设备名只适用于本文案例，不能直接照搬到其他机器。执行任何修复前，都应确认设备名、阵列 UUID、文件系统状态，并优先备份重要数据。

一、系统环境

项目 配置
DSM 型号 DS918+
DSM 版本 DSM 6.2.3-25426
部署方式 黑群晖裸机
数据盘 1TB HDD + 500GB HDD
其他磁盘 29.5GB SSD，用于系统相关分区/独立小卷
故障存储池 1TB HDD 上的单盘 Basic 存储池
文件系统 Btrfs
故障数据卷 /volume2
正常数据卷 /volume3，位于500GB HDD

DSM 存储管理器中的主要表现：

  • 1TB HDD 的“健康状态”为“良好”；
  • 坏扇区数显示为 0；
  • 该硬盘的“分配状态”为“已损毁”；
  • 对应 Basic 存储池状态为“已损毁”；
  • 数据卷无法正常提供写入服务，相关套件也可能停止运行；
  • 500GB HDD 及其数据卷保持正常。

需要注意，DSM 的“健康状态”和“分配状态”不是同一个概念。硬盘 SMART 状态正常，并不代表其所在的 MD 阵列或文件系统一定处于正常状态。

二、第一原则：不要立即删除或初始化

遇到这种情况时，不要直接执行以下操作：

  • 不要删除存储池；
  • 不要初始化硬盘；
  • 不要重新创建 Basic、SHR 或 RAID；
  • 不要运行 mdadm --create；
  • 不要运行 mdadm --zero-superblock；
  • 不要直接执行 btrfs check --repair；
  • 不要为了尝试恢复而反复重启。

删除存储池或重新创建阵列可能覆盖原有 MD 元数据，使本来可以读取的数据变得难以恢复。

三、确认 Linux MD 阵列状态

通过 SSH 登录 DSM，并切换到 root：

sudo -i

查看当前软件阵列：

cat /proc/mdstat

本案例中的关键输出为：

md3 : active raid1 sde3[0](E)
      971940544 blocks super 1.2 [1/1] [E]

同时还有一个正常的数据阵列：

md4 : active raid1 sdf3[0]
      483564544 blocks super 1.2 [1/1] [U]

DSM 即使创建的是单盘 Basic 存储池，底层通常仍会使用单成员 RAID1 形式的 Linux MD 设备：

  • /dev/md3：1TB 硬盘上的故障 Basic 存储池；
  • /dev/sde3：该存储池的物理成员分区；
  • /dev/md4：500GB 硬盘上的正常存储池；
  • [U]：成员正常；
  • (E) 和 [E]：成员被标记为错误。

查看故障阵列详情：

mdadm --detail /dev/md3

本案例关键输出：

Raid Level : raid1
Raid Devices : 1
Total Devices : 1
State : clean, FAILED
Active Devices : 1
Working Devices : 1
Failed Devices : 0

Number   Major   Minor   RaidDevice State
0        8       67      0          faulty active sync /dev/sde3

这里有一个看似矛盾的状态：

  • 阵列元数据为 clean；
  • 唯一成员仍然存在；
  • Active Devices 和 Working Devices 都是 1；
  • 但成员同时被标记为 faulty active sync；
  • 整个阵列因此显示为 FAILED。

这说明数据分区没有消失，主要问题是 MD 层保留了成员故障标记。

四、确认数据卷是否仍可读取

查看挂载状态：

mount | grep -E 'md3|volume'
df -h

本案例中 /dev/md3 已经挂载：

/dev/md3 on /volume2 type btrfs (ro,...)

其中最关键的是：

ro

这表示数据卷被以只读方式挂载。DSM 这样做是为了在检测到存储故障后避免继续写入，从而降低进一步损坏的风险。

空间信息显示：

/dev/md3  890G  241G  650G  27%  /volume2

因此当时约有 241GB 数据仍然可以读取。

确认 Btrfs 能否识别：

btrfs filesystem show /dev/md3

输出显示 Btrfs 文件系统 UUID、设备编号及容量均可正常识别：

Total devices 1
FS bytes used 243.83GiB
devid 1 size 926.91GiB used 926.91GiB path /dev/md3

这进一步证明文件系统没有完全丢失。

五、内核日志中的关键信息

检查硬盘、阵列和 Btrfs 日志：

dmesg | grep -Ei 'sde|ata5|md3|btrfs|I/O|error|failed' | tail -n 300

本案例中的硬盘链路能够正常建立：

ata5: SATA link up 6.0 Gbps
ata5.00: ATA-10: WDC WD10EZEX-00BBHA0
sde: sde1 sde2 sde3

MD 阵列也成功组装：

md: bind<sde3>
md/raid1:md3: active with 1 out of 1 mirrors
md3: detected capacity change

Btrfs 能够识别文件系统，但记录过两次写错误：

BTRFS info (device md3): bdev /dev/md3 errs:
wr 2, rd 0, flush 0, corrupt 0, gen 0

这些字段表示：

字段 数值 含义
wr 2 发生过两次写错误
rd 0 没有记录到读错误
flush 0 没有缓存刷新错误
corrupt 0 没有记录到数据校验损坏
gen 0 没有文件系统代际错误

因此，本案例没有看到大量读错误或 Btrfs 校验损坏，更符合偶发写入失败、掉电、SATA 链路异常或控制器映射问题。

日志中还出现：

md: invalid raid superblock magic on sde3
md: sde3 does not have a valid v0.90 superblock, not importing!

这两行不能单独理解为数据分区元数据已经损坏。启动早期系统尝试按旧版 0.90 MD 元数据识别该分区失败，但稍后已经使用正确的 1.2 元数据成功组装 /dev/md3。

六、为什么普通 SMART 检查没有结果

第一次运行：

smartctl -a /dev/sde

返回：

SMART support is: Unavailable - device lacks SMART capability.

这并不代表硬盘真的不支持 SMART。启动日志显示该 SATA 硬盘被识别为：

Attached SCSI removable disk

这通常与黑群晖的 SATA 端口映射或内部盘、外接盘位掩码配置有关。smartctl 因此按 SCSI 设备访问，没有自动使用 SATA SMART 指令。

应显式指定 SATA 透传：

smartctl -a -d sat /dev/sde
smartctl -l error -d sat /dev/sde

重点检查：

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable
UDMA_CRC_Error_Count

判断原则：

  • Reallocated_Sector_Ct、Current_Pending_Sector 或 Offline_Uncorrectable 不为 0：优先考虑硬盘介质问题，建议先克隆数据并更换硬盘；
  • UDMA_CRC_Error_Count 持续增长：更可能是 SATA 数据线、接口、供电或控制器链路问题；
  • 上述介质错误为 0，且日志没有持续出现 ATA/I/O 错误：可以在备份后尝试恢复 MD 阵列状态。

七、可能原因

根据本次日志，可以确认的是：

  1. 1TB 硬盘仍被系统完整识别；
  2. /dev/sde3 的 MD 1.2 元数据仍然存在；
  3. /dev/md3 能成功组装；
  4. Btrfs 可以识别并读取；
  5. 文件系统被 DSM 保护性地只读挂载；
  6. MD 成员处于 faulty active sync 状态；
  7. Btrfs 曾记录两次写错误；
  8. 当前启动日志未见持续的 ATA 读写错误。

综合判断，可能原因按优先级包括：

1. 重启或断电期间发生写入异常

如果 DSM 没有正常关机、供电短暂中断，或者硬盘写缓存尚未完全落盘，MD 可能会将成员标记为错误。群晖官方资料也将意外断电列为卷损毁和文件系统错误的常见原因之一。

2. SATA 数据线、供电或接口瞬时异常

即使硬盘 SMART 显示健康，链路瞬断或写入超时也可能使 MD 将设备踢出正常状态。

3. 黑群晖磁盘端口映射不正确

本案例中两块机械硬盘都被识别成 SCSI removable disk，而不是标准内部 SATA 数据盘，说明以下配置可能不正确：

  • SataPortMap
  • DiskIdxMap
  • internalportcfg
  • esataportcfg
  • SATA/HBA 控制器驱动

磁盘端口映射不规范可能导致 DSM 重启后盘位编号、内部盘属性或分配状态发生异常。

4. 硬盘本身存在尚未被界面展示的问题

DSM 显示“健康良好”和“坏扇区为 0”不能完全替代完整 SMART 检查。必须使用 smartctl -d sat 获取原始属性后才能进一步排除硬盘问题。

因此，本文不能武断地将原因写成“DSM误报”或“硬盘绝对正常”。更准确的描述是：一次写入或链路异常导致 MD 将单盘 Basic 阵列的唯一成员标记为故障，DSM 随后把 Btrfs 卷切换为只读状态；黑群晖的磁盘端口映射可能是诱因之一。

八、恢复前先备份

由于这是单盘 Basic 存储池，没有任何数据冗余，强制恢复阵列前应先复制重要数据。

本案例的 /volume2 已经只读挂载，可以正常读取，因此正适合进行备份。

需要注意：

  • /volume2 已使用约 241GB；
  • /volume3 仅剩约 144GB，无法容纳完整备份；
  • 应连接容量足够的 USB 硬盘，或者通过网络复制到另一台设备；
  • 至少应优先备份不可替代的数据。

如果数据非常重要，最稳妥的方案是先使用 ddrescue 对整块 1TB 硬盘进行扇区级克隆，再在克隆盘上尝试修复。

九、停止使用故障卷的套件

本案例中 Docker 的子卷也挂载在 /volume2：

/dev/md3 on /volume2/@docker
/dev/md3 on /volume2/@docker/btrfs

恢复前，应先在 DSM 套件中心停止安装在 /volume2 上的所有套件，尤其是 Docker。

也可以通过 SSH 停止 Docker：

synopkg stop Docker

然后检查是否仍有进程占用：

fuser -m /volume2

如果仍有占用，应停止对应套件或进程。不要直接使用 umount -f 或 umount -l 掩盖占用问题。

十、卸载并重新组装故障阵列

风险提示：以下命令会更改阵列运行状态。只有在已经确认 /dev/md3 对应故障存储池、/dev/sde3 是其唯一正确成员，并且已经完成重要数据备份后，才能执行。

1. 按从内到外的顺序卸载

umount /volume2/@docker/btrfs
umount /volume2/@docker
umount /volume2

如果出现：

target is busy

不要继续停止阵列，应先执行：

fuser -m /volume2

确认并停止所有占用进程。

2. 停止 MD 阵列

mdadm --stop /dev/md3

3. 使用原成员强制重新组装

mdadm --assemble --force /dev/md3 /dev/sde3

这里使用的是“重新组装”，不是“重新创建”：

  • --assemble：使用硬盘上原有的 MD 元数据组装阵列；
  • --force：允许 mdadm 接纳被标记为故障、但仍包含有效阵列元数据的成员；
  • 绝不能误写成 mdadm --create。

4. 检查结果

cat /proc/mdstat
mdadm --detail /dev/md3

预期的正常状态类似：

md3 : active raid1 sde3[0]
      ... [1/1] [U]

mdadm --detail 中应不再出现：

State : clean, FAILED
faulty active sync

如果仍然显示 [E]、FAILED，或者命令返回 I/O 错误，应立即停止后续操作，不要反复执行 --force。

5. 让 DSM 自动挂载

阵列恢复为 [U] 后重启：

reboot

建议让 DSM 自己识别并挂载存储池，不要在状态不明时手动以读写方式挂载 Btrfs。

重启后检查：

cat /proc/mdstat
mount | grep -E 'md3|volume2'
mdadm --detail /dev/md3

正常情况下：

  • /dev/md3 显示 [U]；
  • /volume2 从 ro 恢复成 rw；
  • DSM 存储池恢复正常；
  • 停止的套件可以重新启动。

十一、恢复后的长期处理

即使存储池恢复，也应继续处理潜在诱因。

1. 修正黑群晖磁盘映射

根据实际主板 SATA 控制器、扩展卡和硬盘连接方式，重新检查：

SataPortMap
DiskIdxMap
internalportcfg
esataportcfg

目标是让两块数据盘被 DSM 识别为内部硬盘，而不是：

Attached SCSI removable disk

修改前应备份当前引导器配置，不要同时升级 DSM、切换机型和修改磁盘映射，以免增加变量。

2. 检查 SATA 线和供电

  • 关机后重新插拔或更换 SATA 数据线；
  • 检查 SATA 电源接头是否松动；
  • 避免使用质量较差的一分多电源转接线；
  • 如果 UDMA_CRC_Error_Count 持续增长，优先更换数据线和接口。

3. 配置 UPS

意外断电可能造成文件系统错误或阵列异常。建议配置 UPS，并启用 DSM 的安全关机功能。

4. 完成数据校验

确认存储池恢复健康、数据已备份后，再通过 DSM 执行 Btrfs 数据校验。存储池处于“已损毁”状态时不要直接运行修复型检查。

5. 不要把 Basic 当成备份

单盘 Basic 没有容错能力。即使底层显示为单成员 RAID1，也不存在第二份镜像。重要数据应至少采用：

  • NAS 本地副本；
  • 另一台设备或外置硬盘副本；
  • 异地或云端副本。

十二、常用诊断命令汇总

查看 MD 阵列

cat /proc/mdstat
mdadm --examine --scan
mdadm --detail /dev/md3

查看挂载和空间

mount | grep -E 'md3|volume'
df -h

查看 Btrfs 设备

btrfs filesystem show /dev/md3

查看真实 SATA SMART

smartctl -a -d sat /dev/sde
smartctl -l error -d sat /dev/sde

查看阵列成员内部状态

cat /sys/block/md3/md/dev-sde3/state
cat /sys/block/md3/md/dev-sde3/errors

查看相关日志

dmesg | grep -Ei 'sde|ata5|md3|btrfs|I/O|error|failed' | tail -n 300

查看卷占用进程

fuser -m /volume2

十三、总结

本次故障的核心并不是“DSM完全找不到硬盘”，而是：

  1. 裸机黑群晖重启后发生过写入或链路异常；
  2. 1TB 数据盘仍能识别，MD 1.2 元数据仍然存在；
  3. 单盘 Basic 阵列的唯一成员被标记为 faulty active sync；
  4. MD 阵列进入 clean, FAILED 状态；
  5. DSM 将 Btrfs 数据卷以只读方式挂载；
  6. 数据仍可读取，但套件和共享服务无法正常写入；
  7. 在完成备份和 SMART 检查后，可通过停止并强制重新组装原阵列恢复；
  8. 恢复后还应修正黑群晖 SATA 端口映射，并检查数据线、供电及断电保护。

判断这类故障时，不能只看 DSM 界面的“硬盘健康良好”，也不能看到“存储池已损毁”就立即初始化。/proc/mdstat、mdadm --detail、实际挂载状态、Btrfs 错误计数和完整 SMART 数据，才是决定下一步操作的关键依据。

有条件支持一下 🚀 MiniMax Token Plan
订阅一份套餐，解锁最新模型 —— 前沿 Coding 能力、1M 超长上下文、原生多模态，图文音视频共用套餐额度。
🎁 邀友双赢福利
好友订阅享 9折 + Builder 权益，邀请人得 10% 返利 + 社区特权！
立即订阅：https://platform.minimaxi.com/subscribe/token-plan?code=4atiST3IBg&source=link

参考资料

本文是针对特定环境的一次故障记录，不构成通用的一键修复方案。不同 DSM 版本、引导器、RAID 类型、磁盘数量及分区编号可能完全不同。重要数据应优先交由专业数据恢复人员处理。

posted @ 2026-07-24 12:23  愛羅  阅读(62)  评论(0)    收藏  举报