黑群晖断电后存储池损毁？SSH+mdadm命令急救指南

黑群晖断电后存储池“已损毁”？别慌，SSH里这几条命令能救急

“存储池已损毁”——这句话几乎是每个玩黑群晖的人早晚都要经历的“成人礼”。我自己第一次撞见，是一个夏夜全小区跳闸，第二天爬起来打开 DSM，存储池状态直接变成灰色，点进去一行大字：“已损毁”。我当时心跳比硬盘转速还快，脑子里已经开始盘算哪年的照片没备份了。但吃完这几年的亏，我越来越确定一件事：黑群晖断电后出现的“已损毁”，绝大多数情况下是一次“保护性停机”，不是数据被物理抹掉。你真正要做的不是格式化、不是重建池，而是通过 SSH 进去，用几条 mdadm 和 LVM 命令，让系统重新识别那些本来就还在硬盘上的数据。这篇文章就把整套急救流程、每条命令背后的原理、以及我踩过的坑一次性讲透，适合手头有黑群晖、遇到断电重启后存储池异常的朋友照着操作。

1. 断电后的恐慌现场：先弄明白“已损毁”到底在说什么

1.1 黑群晖存储池的三层结构

要理解为什么断电会触发“已损毁”，得先看黑群晖的存储池在 Linux 层面到底是怎么搭起来的。它的结构大致分三层：

• 最底层是物理硬盘上的分区，比如 sda3、sdb3、sdc3，这些分区通过 mdraid 组成 RAID 阵列；
• 中间层是 mdraid 阵列，对应的设备是 /dev/md0、/dev/md1、/dev/md2，其中 md0 放系统引导分区，md1 放 swap，md2 通常是你的数据卷；
• 最上层是 LVM（逻辑卷管理），DSM 会把阵列空间切成物理卷（PV）、卷组（VG）、逻辑卷（LV），再在 LV 之上格式化 ext4 或 Btrfs 文件系统。

SHR（Synology Hybrid RAID）本质上也是这套组合，只不过它用 mdraid 实现不同 RAID 级别拼接，再用 LVM 把各盘分区统一汇聚成一个卷供 DSM 使用。所以你会看到，黑群晖拿 4 块盘做的 SHR 或 RAID5，对应到 Linux 上就是一个 md2，下面挂着 4 个分区成员。

1.2 断电到底打断了什么

正常关机时，系统会执行一套“体面退场”流程：

1. 内核把内存里的脏页（dirty pages）刷到磁盘；
2. 文件系统卸载（umount），日志正确关闭；
3. mdadm 把每个成员的 superblock 状态从 dirty 更新为 clean；
4. LVM 把卷组标记为 inactive，干净退出。

突然断电，这套流程全部被打断。具体表现在两个地方：

第一，RAID superblock 的 State 字段还停留在 dirty。superblock 是写在每个盘分区开头的一段元数据，相当于整组 RAID 的“工作证”，上面记录了 UUID、阵列级别、成员清单、事件计数和状态。断电瞬间各盘写入进度不一致，Event Count（事件计数）没有对齐。内核下次启动时发现状态不是 clean，或者各盘事件计数差异过大，就会采取保守策略：不自动激活阵列。于是 md2 保持在 inactive 状态，DSM 的 UI 上就显示“存储池已损毁”。

第二，如果 md2 没有被正确激活，叠在它上面的 LVM 卷组就成了无源之水，pvscan 找不到可用的物理卷，/volume1 自然无法挂载。

所以“已损毁”大概率是一个软件层面的保护性停机，是系统不确定阵列状态，干脆先不碰它，等你裁决。你要做的不是“重建”，而是“让系统重新识别已经存在的数据”。

1.3 三个故障层级的判断框架

我习惯把断电后的“已损毁”按层级分成三类，方便快速定位：

故障层级	典型现象	恢复难度	出现概率
mdraid 阵列未组装	/proc/mdstat 无 md2 或 md2 为 inactive	低	最高
LVM 卷组未激活	pvscan/vgscan 找不到卷组或显示 inactive	低	次之
文件系统受损	挂载失败、目录缺失、Btrfs checksum 错误	中	较低

无论你遇到哪一种，都建议按“从下往上”的顺序排查：先确认物理盘健康，再组装 mdraid，再激活 LVM，最后处理文件系统。跳过任何一步，都可能把问题搞得更大。

2. 进场第一步：SSH 开通、登录和五分钟硬件排雷

2.1 开通 SSH 并登录

黑群晖默认不开 SSH，需要先到“控制面板 → 终端机和 SNMP → 启用 SSH 功能”这里打开。端口默认 22，如果你为了安全改过端口，后面连接时记得带上 -p 参数。

连接方式：

• Windows 用户可以用 Windows Terminal 自带的 OpenSSH 客户端，或者 Xshell、PuTTY；
• macOS 和 Linux 用户直接终端敲 ssh 命令即可。

命令格式是：

ssh admin@192.168.1.100

这里有两个坑要先提醒：

• DSM 6 和 DSM 7 都不允许 root 直接登录，你需要用 admin 账号或你创建的管理员账号登录，然后再执行 sudo -i 切换到 root。
• 如果 SSH 连接失败，先检查 DSM 的防火墙是否放行了 22 端口，再检查你登录的账号是否属于 administrators 组。黑群晖有时候会因为引导盘问题导致一些服务异常，SSH 起不来，那就得先解决引导和网络问题，这属于另一个话题。

登录并提权：

ssh admin@192.168.1.100 sudo -i

看到提示符变成 root@ 开头，说明你已经进入 root 状态，下面所有命令都基于这个状态执行。

2.2 第一眼：读 /proc/mdstat

进入系统后，第一件事不是去执行什么恢复命令，而是先看一眼阵列当前的真实状态：

cat /proc/mdstat

正常输出长这样：

Personalities : [raid1] [raid6] [raid5] [raid4] md2 : active raid1 sdc3[1] sdb3[0] sdd3[3] sda3[2] 17513607064 blocks super 1.2 [4/4] [UUUU] md1 : active raid1 sdd2[1] sda2[0] 2092288 blocks [2/2] [UU] md0 : active raid1 sdd1[1] sda1[0] 2490176 blocks [2/2] [UU] unused devices: <none>

怎么读这段输出：

• md2 后面如果是 active，说明阵列已经组装完成；如果是 inactive，说明阵列存在但内核没有激活它——这正是断电后最常见的状态；
• [4/4] [UUUU] 表示 4 个成员全部在线；如果看到 [3/4] [UUU_]，说明有一个成员掉了；
• blocks 后面显示的是阵列总容量，super 1.2 是 metadata 版本。

最常见的断电后输出是：

md2 : inactive sdc3[1] sdb3[0] sdd3[3] sda3[2] 17513607064 blocks super 1.2

成员分区都在，但 md2 没有启动。看到这个，心里先松一半：盘都认识，只是没跑起来。

2.3 dmesg 和 SMART：先排除硬件雷

在动任何“组装”操作之前，花五分钟排除硬件问题，能避免你后面白折腾一小时。先看内核日志：

dmesg | tail -n 100

重点搜索这些关键词：

dmesg | grep -E 'I/O error|Buffer I/O|ata.*fail|link reset|exception Emask'

如果出现大量 I/O error，说明某块盘在硬件层面已经有读写失败，这不是单纯断电导致的“假死”，后面操作要更加保守。

接着检查 SMART 信息。DSM 自带 smartctl，可以直接用：

smartctl -a /dev/sda

重点关注三个指标：

• Reallocated_Sector_Ct（重映射扇区数）：持续增长说明盘在物理磨损；
• Current_Pending_Sector（待处理扇区）：非零说明盘有坏道在排队；
• UDMA_CRC_Error_Count：如果这个值高，可能要检查数据线或背板接口。

真实案例：我有一次处理一台断电后“已损毁”的黑群晖，四块盘里三块 superblock 都正常，只有一块盘的 Event Count 差了 10 万以上，SMART 显示 pending sector 已经上千。这种情况下不是执行 --force 强行组阵列，而是需要先判断这块盘的数据是不是已经不可信，甚至要考虑直接从备份恢复。先做硬件排查，再谈软件恢复，顺序不能反。

3. 核心救急命令组合：从阵列重组到卷激活再到挂载验证

3.1 mdadm 重组：让内核重新认识 RAID

确认硬件没问题后，就该处理“inactive”的 md2 了。标准动作分三步。

第一步，如果 md2 已经存在且状态是 inactive，先把它停掉，避免状态残留：

mdadm --stop /dev/md2

如果提示 device busy，说明有进程还在引用它。先检查有没有挂载：

mount | grep md2

确认没有挂载，再用 lsof 或 fuser 找出占用进程。绝大多数情况下不会 busy，因为 DSM 都还没挂载这个卷。

第二步，尝试全自动扫描组装：

mdadm --assemble --scan

这条命令会让内核在系统已知的 superblock 元数据里去匹配所有磁盘分区，把能组装的阵列都组装起来。执行完再看一次 /proc/mdstat：

cat /proc/mdstat

如果 md2 从 inactive 变成了 active，直接跳到 3.2。如果 --scan 没成功，多半是 mdadm 的配置文件 /etc/mdadm.conf 里没有正确记录阵列信息，或者各盘 superblock 的事件计数差异过大。

第三步，手动指定成员组装。先用 lsblk 拿到盘和分区布局：

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

你会看到类似这样的结构：

sda 3.6T ├─sda1 2.4G linux raid autodetect ├─sda2 2G linux raid autodetect └─sda3 3.6T linux raid autodetect sdb 3.6T ├─sdb1 2.4G linux raid autodetect ├─sdb2 2G linux raid autodetect └─sdb3 3.6T linux raid autodetect

sda3、sdb3 这一类就是数据卷 md2 的候选成员。不要凭感觉猜，用 mdadm --examine 去每个分区上读 superblock，确认它们的 UUID 是否一致、事件计数差多少：

mdadm --examine /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

输出里最关键的是几行：

• Array UUID：所有成员必须一致，不一致说明有盘不属于这个阵列；
• Event Count：同一个阵列内各盘的这个数值应该接近，差距过大说明某块盘长时间离线；
• State：显示 clean、active 还是 degraded。

如果四个分区的 UUID 一致，就可以手动组装：

mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

如果 mdadm 因为事件计数不一致拒绝组装，你需要先评估差距，再决定是否加 --force。关于 --force 的底线，我在第 5 章专门说。

组装成功后，md2 应该变成 active。记住，到这一步你只是把 RAID 层恢复，还没让 DSM 看到卷。

3.2 LVM 卷激活：最容易被忽略的一环

md2 active 之后，下一步是激活 LVM。很多新手在这里卡住，因为 mdstat 看着一切正常，但 /volume1 依然挂不上。原因很简单：DSM 在 LVM 之上，LVM 卷组没激活，文件系统自然无影无踪。

依次执行三条扫描命令：

pvscan vgscan lvscan

正常输出会看到：

PV /dev/md2 VG vg1 lvm2 [16.36 TiB / ...] LV /dev/vg1/lv1 VG vg1 lvm2 [15.99 TiB ...]

如果你看到的卷组状态不是 active，或者 lvscan 里 LV 路径存在但卷没有激活，执行：

vgchange -ay

这条命令会把系统里所有卷组激活。激活后检查：

ls -l /dev/mapper/ lvdisplay

看到类似 /dev/mapper/vg1-lv1 的设备节点，说明 LVM 层已经恢复。

这里说一个判断重点：如果 pvscan 什么 PV 都找不到，大概率不是 LVM 元数据损坏，而是 md2 其实还没真正 active。LVM 扫描不到底层设备，自然找不到 PV。所以遇到“找不到卷组”，先回头确认 /proc/mdstat 里 md2 是不是 active，别急着怀疑 LVM 元数据坏了。真有元数据损坏时，可以考虑 vgcfgrestore 从备份恢复，但那个场景极少，而且需要你之前做过 vgcfgbackup。

3.3 文件系统检查与最终挂载验证

LVM 激活后，别急着让系统自动挂载。你可以先做一次只读检查，评估文件系统状态：

fsck -n /dev/mapper/vg1-lv1

这条命令的 -n 参数表示“只读检查，不修复”，非常关键。它能告诉你在没有写操作的情况下，文件系统里有没有 inode、块引用之类的问题。注意：执行 fsck 前必须确认文件系统没有被挂载，否则会有风险。如果 DSM 已经自动挂载了卷，你需要先卸载：

umount /volume1

如果 umount 提示 busy，说明有进程在使用，可以先用 fuser -km /volume1 踢掉占用进程，再卸载。实在卸不掉，可以临时把卷挂载为只读来复制数据：

mount -o ro /dev/mapper/vg1-lv1 /mnt/rescue

多数情况下，断电后的 ext4 或 Btrfs 在挂载时会自动执行日志回放，第一次挂载会比较慢，但能正常完成。验证数据：

mkdir -p /mnt/rescue mount /dev/mapper/vg1-lv1 /mnt/rescue ls -l /mnt/rescue df -h | grep vg1

看到你的共享文件夹、照片、影视文件夹都在，就说明数据完整。确认没问题后卸载，直接重启：

umount /mnt/rescue reboot

重启后 DSM 会自动接管 md2、激活 LVM、挂载卷，存储池状态恢复正常。整条急救链路总结成最短命令集：

sudo -i cat /proc/mdstat mdadm --stop /dev/md2 mdadm --assemble --scan cat /proc/mdstat pvscan vgscan vgchange -ay lvscan reboot

这几条命令的顺序不能乱，md 没起来就去激活 LVM，等于白忙。

4. 实测中最常见的几种“假损毁”场景和现场解法

4.1 场景一：四块盘全在，md2 却 inactive

这个场景占了断电后“已损毁”的七成以上。现象是 /proc/mdstat 里 md2 显示 inactive，但所有成员分区都还在列表里。

发生原因：断电时 superblock 状态还停在 dirty，mdadm 默认不自动激活。内核看到“状态不干净”就选择等命令，于是 DSM 就显示存储池不可用。

解法就是 3.1 的完整流程。我自己实测下来，最简单的三步就能解决：

mdadm --stop /dev/md2 mdadm --assemble --scan cat /proc/mdstat

看到 active 和 [UUUU]，接下来 vgchange -ay，再 reboot。全程五分钟，数据零丢失。

4.2 场景二：md2 已经 active，但 LVM 卷组显示 Not found

这个场景也很常见。你明明在 mdstat 里看到 md2 是 active，pvscan 却告诉你：

No PV found

或者 vgscan 找不到 vg1。这种现象绝大多数不是 LVM 元数据损坏，而是时序问题：Linux 在启动时先扫描 PV，当时 md2 还没组装完成，于是 PV 扫描结果为空。加上 md2 active 之后，LVM 没有自动触发重新扫描，自然看不到。

解法很简单，手动触发一次重新扫描：

pvscan vgscan --cache vgchange -ay

如果还是不行，检查一下 /dev/md2 设备节点是否存在，以及 /etc/lvm/backup 下有没有历史卷组配置备份。极少情况下需要 vgcfgrestore，但前提是你之前通过 vgcfgbackup 生成了备份文件。所以平时养成习惯，在 NAS 稳定运行的时候顺手跑一次 vgcfgbackup vg1，把配置备份到安全位置，关键时刻能救命。

4.3 场景三：一块盘“掉队”，md2 显示 degraded

现象是 mdstat 里出现类似 [UU_U] 的状态，说明 4 个成员里 3 个在线，1 个缺失。

这有两种可能：一种是某块盘在断电后没有被内核识别，superblock 的事件计数落后太多被判定为 stale；另一种是盘物理上已经出问题。区分方法：

lsblk smartctl -a /dev/sdX dmesg | grep -E 'I/O error|ready|fail'

如果盘还在系统里、SMART 没有明显异常、dmesg 没有 I/O error，那大概率只是事件计数落后。查看 md2 的成员详情：

mdadm --detail /dev/md2

输出里会标明谁在谁不在。确认缺失的那块盘分区编号，比如 /dev/sdx3，然后执行：

mdadm --add /dev/md2 /dev/sdx3

add 操作会把盘作为热备重新加入阵列，触发重建。重建期间阵列处于 degraded 状态，系统仍可读写，但性能会下降。注意：如果你不确定这块盘的数据是否和阵列同步，不要直接 add。更稳妥的做法是先备份，再用 --add。如果这块盘显示的 Event Count 和当前阵列差得不多，重建通常没有问题。

4.4 场景四：真的有一块盘硬件坏了

如果 SMART 显示 pending sector 持续增长，或者 dmesg 里刷 I/O error，那就不是“假损毁”，而是真硬件故障。这种情况下的原则是：

• 如果是 RAID1 / RAID5 / RAID6 / SHR1 / SHR2，阵列有冗余，数据还在剩余盘上。先不要做任何修复动作，把当前 md2 的信息完整记录：

  mdadm --detail /dev/md2 > /root/md2-before.txt mdadm --examine /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 > /root/md2-examine.txt

  然后把坏盘替换成新盘，插入同槽位，再在 DSM 存储池界面执行修复。修复过程本质上是把阵列数据重建到新盘，期间不要频繁重启。
• 如果是 RAID 0 或 Basic，那就真的没有冗余，只能评估数据损失，从备份恢复。这也是我一直不建议在主力 NAS 上用 RAID 0 或单盘 Basic 的原因：断电后的“已损毁”虽然大部分能救，但一旦碰上硬件坏盘，RAID 0 就是裸奔。

5. 哪些命令绝对不能乱敲：复盘里总结出的底线原则

5.1 mdadm --create 是数据毁灭指令

我见过不止一个案例：存储池显示已损毁，用户搜到网上说“重新创建 md2”，然后执行了 mdadm --create。一旦 --create 跑起来，mdadm 会认为你是在建一个新阵列，它会向成员分区写入新的 superblock，旧阵列的元数据直接被覆盖。虽然磁盘上的文件数据字节还在，但整组 RAID 的身份信息已被销毁，后续恢复难度会几何级上升。

所以，无论网上教程怎么讲，看到“存储池已损毁”，你的默认回应应该是 --assemble，而不是 --create。--create 只适合你明确知道数据不要了、要重建空阵列的情况。如果阵列真的损坏到无法 assemble，也别急着 create，先备份 superblock，再用 --assemble --force 尝试，最后才考虑数据恢复公司级别的操作。

5.2 fsck 的正确时机是“文件系统未挂载”

fsck 是文件系统检查工具，但它有个硬性前提：必须在文件系统未被挂载时执行。在挂载状态下对 ext4 或 Btrfs 跑 fsck，轻则检查结果无意义，重则因为元数据变更造成进一步混乱。

实际环境中，DSM 往往会在你还没操作时就把卷挂载到 /volume1。所以标准动作是：

umount /volume1 fsck -n /dev/mapper/vg1-lv1

先 -n 只读检查，看看输出里有没有“contains a file system with errors”这类内容。如果确认有问题，再考虑去掉 -n 执行修复。Btrfs 用户不能直接用常规 fsck，应该用 btrfs check，而且 Btrfs 的 check 命令对正在挂载的文件系统同样危险，执行前必须卸载。

5.3 --force 要配合 Event Count 使用

mdadm --assemble --force 能把事件计数不一致的阵列强制组装起来，但副作用是：如果某块盘其实已经离线很久，Event Count 远远落后，强制组装后系统可能把这块旧盘上的陈旧数据当成最新数据，从而覆盖其他盘上的正确数据，造成静默损坏。

我用 --force 前一定会做三件事：

1. 对每个成员执行 mdadm --examine，逐行记录 Event Count；
2. 对比各盘计数，如果只有几十到几百的差异，强制组装风险可控；如果差了上万，必须把落后盘先摘除；
3. 组装完成后立刻做一次文件层面的遍历，比如用 rsync -n 或者 md5sum 抽查关键文件，确认数据没有异常。

另外一个兜底操作，成本很低但收益很高：在动手前把每块盘分区开头的 superblock 区域备份出来：

dd if=/dev/sda3 of=/root/sda3-superblock.img bs=512 count=32768 dd if=/dev/sdb3 of=/root/sdb3-superblock.img bs=512 count=32768

真出现误操作，这个备份能让专业人员把原 superblock 写回去，找回阵列身份。类似的还有 LVM 卷组备份：

vgcfgbackup vg1

这条命令会把 vg1 的配置备份到 /etc/lvm/backup/vg1，万一之后卷组元数据出问题，可以用 vgcfgrestore 恢复。

6. 救回来了，然后呢：断电防护与长期体检

6.1 UPS 是解决问题的根子

一次断电能救，两次三次也能救，但每次都带着风险。最根本的解决方案是给黑群晖配一台带 USB 通讯口的 UPS。APC 的 BK650、施耐德的 SRC 系列，或者国产一些带 USB 的型号都可以。

配置方式不复杂：

1. 用 USB 线把 UPS 连到黑群晖主板 USB 口；
2. 在 DSM“控制面板 → 电源 → UPS”里启用 UPS 支持；
3. 设置当检测到断电后，等待 X 分钟后自动关机，或者当 UPS 电量低于某个百分比时自动关机。

我习惯设置：断电后 3 分钟自动关机，低于 30% 电量强制关机。这样既给缓存脏页足够的落盘时间，又不会把 UPS 电量耗干。

注意：黑群晖对 UPS 的识别有时候不完美，如果 DSM 认不出 UPS 型号，可以看 /var/log/messages 里有没有 usbhid-ups 相关信息。认不出的场景，可以尝试更换 USB 线或换一个 USB 口，部分主板的供电电流太弱会导致 UPS 通讯不稳定。

6.2 SSD 缓存和写缓存在断电时的放大效应

黑群晖的 SSD 缓存有两种模式：只读缓存和读写缓存（回写）。回写缓存性能好，但一旦断电，SSD 缓存里未下刷的数据直接丢失，风险比普通硬盘的写缓存高不少。我见过几台黑群晖因为 NVMe 回写缓存加断电，文件系统直接出现 Btrfs checksum 错误，恢复复杂度明显上升。

建议：如果你的数据重要，SSD 缓存优先用只读模式，或者给 SSD 配置带掉电保护的企业级型号。普通硬盘的写缓存一般不需要关，现代硬盘都有掉电保护逻辑，但如果你用的是很老或很便宜的盘，可以在 DSM 里关闭写缓存换取一点安心。

6.3 定期体检的几条命令

把这次救回来的经验变成日常巡检，比等出事再手忙脚乱强得多。我每两个月会 SSH 进去跑一轮：

cat /proc/mdstat mdadm --detail /dev/md2 | grep -E 'State|Rebuild|Event' smartctl -a /dev/sda | grep -E 'Reallocated|Pending|CRC' vgscan

把这些命令攒成一个脚本或者直接记在手机备忘录里。遇到状态异常，比如 md2 从 clean 变成 degraded，或者某块盘 SMART 数值在涨，尽早处理，别拖到下一次断电。

我个人的做法是，把“断电急救命令清单”放在每台黑群晖的 /root/ 目录下，文件名就叫 rescue-notes.txt，用一次救一次，不指望自己的脑子比硬盘可靠。数据这个东西，平时看不出价值，但断电那五分钟，你会发现一行 mdadm --assemble --scan 比什么都有用。