先还原一下场景某天早上NAS突然开始“哔哔哔”报警手机端群晖管家推送一条刺眼的通知——“存储空间 1 进入损毁状态”。打开 DSM 一看存储管理器里 RAID1 阵列的状态是“堪用”下面还挂着一块红灯硬盘。对于跑着家庭照片、工作资料和影视库的黑群晖来说这个提示基本等同于“心脏停跳”的急诊通知。很多人第一反应是懵RAID1 不是互为镜像吗一块盘坏了不是还能正常读吗怎么就直接“损毁”了这里有个对 RAID1 最常见的误解。RAID1 是镜像不代表群晖会无限容忍坏盘。阵列状态分“正常”“堪用”“损毁”三档。“堪用”意味着还能读写但已经很危险“损毁”则意味着阵列元数据或设备状态已经无法被 DSM 正常识别系统认为这个池子不可用了。注意损毁不等于数据物理消失——绝大多数情况下盘上的数据块还在只是阵列的“编组信息”乱了或者某个成员盘掉线导致阵列无法挂载。更让黑群晖用户头疼的是正版群晖遇到这种情况直接在存储管理器里点“修复”往往就能触发重建但黑群晖因为引导、盘序、SATA 控制器驱动、内核版本等差异GUI 修复经常卡在 1% 或者直接报“无法修复”。这时候唯一的出路就是 SSH 进去手动处理。这恰恰也是黑群晖比白群晖折腾但又比白群晖有意思的地方。这篇文章就是一份完整的、按步骤可以照抄的 SSH 手动重建 RAID1 流程。我会把每一步命令背后的原因也讲清楚而不是只丢给你一串代码。1. 存储空间损毁到底发生了什么RAID1 的脆弱全在元数据先说清楚“损毁”这个词的准确含义这直接决定了你到底该走哪条修复路径。1.1 黑群晖 RAID1 的实际结构不是整盘镜像是分区镜像不少刚入坑的朋友以为 RAID1 就是把两块硬盘做成完全一模一样的内容连分区表都一样。实测并不是这样。群晖创建 RAID1 时每块物理盘会被划分为几个分区。以常见的 3.5 寸 SATA 硬盘为例分区 1DSM 系统分区约 2.4GB用于存放 DSM 系统文件分区 2交换分区swap约 2GB分区 3数据分区占剩余全部空间。群晖的 mdadm 会把两块盘的分区 1 做成一个 md0系统分区 2 做成 md1swap分区 3或者之后的几个逻辑分区做成 md2 或 md3存储池。所以当你看到 DSM 的“存储空间 1”损毁时背后其实是/dev/md2或其他编号这个 Linux MD 设备处于异常状态。知道这个结构的价值在于你修复的目标不是“盘”而是“阵列”。盘坏只是触发条件真正的破坏点往往在 md 超级块的一致性上。1.2 “损毁”的常见触发原因我这次遇到的情况以及问了身边几个同样玩黑群晖的朋友触发“损毁”的典型原因基本就这几类硬盘出现坏道或 SMART 异常导致内核频繁报 I/O 错误mdadm 把这块盘标记为 faulty意外断电双盘同时掉电重启后阵列由于写顺序不一致导致超级块不同步SATA 线接触不良或电源供电不稳导致某块盘间歇性掉线黑群晖引导盘异常比如引导 U 盘损坏导致重启后盘序发生变化mdadm 无法按原顺序组装阵列使用硬盘休眠功能某块盘唤醒失败被内核踢出阵列。注意最后一条这是黑群晖很常见但很容易被忽略的坑。黑群晖的硬盘休眠在某些引导版本和 SATA 扩展卡组合下并不稳定睡眠之后唤不醒就直接掉盘了。后面我会专门讲怎么避免。1.3 为什么 GUI 修复经常失败正版群晖的存储管理器里损毁空间通常会提供一个“修复”按钮。点下去之后系统会在后台自动帮你把缺失的盘重新加入阵列并重建。但黑群晖的“修复”按钮经常处于灰色不可点击状态或者点了之后进度条永远在 0%~1% 徘徊最后提示“无法修复存储空间”。原因也很实际一是黑群晖的 DSM 版本和引导版本很多是魔改的自带的 mdadm 事件监控脚本/usr/syno/sbin/syno_md_fix.sh在某些硬件上没有正确执行权限或依赖二是当阵列超级块已经标记为脏dirty且设备状态不一致时群晖 GUI 会拒绝执行自动修复。这种“安全优先”的逻辑在正版上没问题但恰恰挡了黑群晖自愈的路。所以手动 SSH 修复的本质就一句话绕开群晖 GUI 的校验限制直接用 mdadm 这个底层工具把阵列状态“捋直”了再触发内核级别的重建。2. 动手之前这几件事不做就是数据全毁的开始先不要急着 SSH 进去敲命令。手动重建 RAID1 最大的风险不是命令敲错而是你没搞清楚当前阵列的真实状态就开始操作结果把本来还能用的阵列彻底拆了。2.1 现场拍照记录 DSM 里的盘位与阵列信息打开存储管理器先截图或者手机上拍下来。要记清楚的几个信息出问题的是“存储空间 1”还是“存储空间 2”阵列里的两块盘分别在第几盘位每块盘的型号和容量DSM 显示的阵列状态损毁/堪用/正常有没有提示哪块盘是“已卸载”“未初始化”还是“故障”。这里特别提醒一句如果 DSM 里显示某块盘已经被“移除”或者“未初始化”不要立刻在 DSM 里做“新增硬盘”操作。很多人的数据就是毁在这一步——他们在 GUI 里点了“修复”或者干脆删除存储空间重新创建。2.2 SSH 连接前先确认三件基础信息第一确认黑群晖开启了 SSH 功能控制面板 → 终端机和 SNMP → 启用 SSH 功能。默认端口 22。如果是通过 Docker 或虚拟机方式运行的黑群晖端口可能做了映射注意使用映射后的端口。第二确认你有一个管理员账号。SSH 登录后默认不是 root需要在登录后执行sudo -i切换到 root 权限。第三确认两块盘的设备名。这一步至关重要因为接下来所有 mdadm 命令都依赖正确的设备名。提示在 Linux 中/dev/sda、/dev/sdb这种名称不是固定的物理盘位而是内核按照磁盘识别顺序分配的。换了 SATA 口、加了硬盘、重启了引导后设备名都会变。所以不要凭记忆觉得“第一块盘就是 sda”。SSH 登录黑群晖后先执行cat /proc/mdstat这条输出会直观显示当前所有 md 设备的状态。正常的阵列会显示类似md2 : active raid1 sda3[0] sdb3[1] 7814035456 blocks super 1.2 [2/2] [UU][2/2] [UU]表示两个成员盘都正常在线。如果某个盘掉了会看到md2 : active raid1 sda3[0] 7814035456 blocks super 1.2 [2/1] [_U][2/1] [_U]意味着两个成员中只有一个在线另一个位置是下划线。2.3 用 blkid 和 mdadm -E 确认盘的身份别认错盘然后用blkid查看每个分区的 UUID 和文件系统类型特别注意看数据分区的 UUID 是否和 DSM 里显示的存储空间对应。blkid再针对疑似掉线盘的数据分区通常是分区 3查看 md 超级块信息mdadm -E /dev/sda3 mdadm -E /dev/sdb3mdadm -E会读物理分区上的 md 超级块并显示它属于哪个 md 设备、是第几个成员、UUID、事件计数等。这一步能给两块盘“验明正身”避免把无关硬盘误当阵列成员。这里分享一个我自己的惨痛教训有一次我以为掉线的是盘位 2 的盘但实际上 DSM 显示的是盘位 2物理盘找错了。把另一块不是阵列成员的旧盘加进了阵列结果那个盘上的数据被重建过程清空了。虽然那只是一块测试盘但故事告诉我们先mdadm -E验明正身比什么都重要。2.4 备份备份备份哪怕 RAID1 也要先拉冷备RAID1 的修复过程中由于内核会在重建期间对全盘做同步写入任何中途的掉盘、断电、命令错误都可能导致两块盘的数据头全部损坏。所以进入修复流程之前只要你的系统还能读数据强烈建议先将关键数据文件从共享文件夹复制到外部存储或另一台机器上。这一步在速度上可能很尴尬如果你的存储空间已经显示“损毁”群晖的文件服务可能已经不会正常挂载共享文件夹了。如果还能挂载直接用 File Station 或 rsync 拉文件如果连挂载都不行那就要在阵列组装成功后再做备份因为此时文件系统本身可能还没有被真正破坏。总之记住/proc/mdstat显示“active”并不代表你的数据一定完整“损毁”的警告往往意味着文件系统级别可能产生了不一致备份永远是第一优先级。3. SSH 手动重建 RAID1 的完整命令流程接下来进入正题。以下所有命令都是我在黑群晖环境DSM 7.x 系列实测过的。我这里以一个典型场景为例/dev/md2对应存储空间 1由/dev/sda3和/dev/sdb3组成其中/dev/sdb3掉线了。3.1 场景 A阵列还能自举只是缺了一个成员盘这种情况最常见表现为/proc/mdstat里有 md2状态仍是 active raid1但成员数从 2 变成了 1另一个成员标记为 faulty 或 removed。首先确认当前状态sudo -i cat /proc/mdstat mdadm --detail /dev/md2如果发现掉线盘是/dev/sdb3且你在mdadm --detail中看不到它说明已被移除可以直接尝试把它重新加回去mdadm --add /dev/md2 /dev/sdb3这条命令不会立即清空 sdb3 上的数据。mdadm 会检查 sdb3 的超级块中的事件计数event counter是否与当前阵列匹配。如果匹配它会执行“re-add”逻辑只对新写入的数据差异部分做同步如果不匹配它会标记该盘需要全盘重建。加入之后查看重建进度watch -n 1 cat /proc/mdstat重建期间md2 后面的状态栏会变成类似md2 : active raid1 sdb3[1] sda3[0] 7814035456 blocks super 1.2 [2/1] [U_] [...............] recovery 20.0% (1564037120/7814035456) finish68.6min speed188000K/sec这个输出非常直白等进度跑到 100% 就完成了。实测中最容易踩的坑mdadm --add 报错“设备正忙”如果执行mdadm --add /dev/md2 /dev/sdb3时提示类似mdadm: add new device failed或者Device or resource busy大概率是这块盘的分区被系统自动挂载了或者它上面有残留的 md 超级块被系统当成了另一个阵列。处理方法是先卸载umount /dev/sdb3 2/dev/null mdadm --stop /dev/md127 2/dev/null这里有个黑群晖特有的坑你看着是/dev/sdb3但它可能已经被群晖的自动挂载机制挂到了某个路径下。umount /dev/sdb3会解除占用mdadm --stop /dev/md127是针对那种系统自动把它识别成一个普通 md 设备比如 md127并尝试组装的情况。停掉之后再执行mdadm --add即可。为什么我建议用--add而不是--re-addmdadm --re-add是专门用来把原先的成员盘加回阵列的理论上更安全。但在黑群晖环境中我反而更推荐先试--add原因是群晖内核的 mdadm 版本在检测设备时对磁盘签名的处理比较特殊某些情况下--re-add会报“设备不匹配”导致直接中断。而--add会自动降级判断如果超级块事件计数匹配就做增量同步不匹配就做全量重建。两种路径最终都能让阵列恢复 online唯一的区别是同步速度。3.2 场景 B阵列完全丢失或 md 设备不存在如果/proc/mdstat里根本看不到 md2或者 md2 已经处于inactive状态说明 mdadm 在系统启动时没有成功组装这个阵列。这时候的数据没有丢但你需要手动把阵列“拼”回来。先检查两块数据分区上的超级块mdadm -E /dev/sda3 /dev/sdb3如果输出里能看到两块盘的成员信息、uuid、事件计数就可以手动组装mdadm --assemble --scan更保险的做法是指定成员设备来组装mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3如果--assemble提示超级块版本不一致或者某个盘被标记为“spare”热备盘你可以强制组装mdadm --assemble --force /dev/md2 /dev/sda3 /dev/sdb3--force会在事件计数不完全一致时强制以当前在线成员为准组装。注意这个操作相当于“少数服从多数”如果两块盘的事件计数都有分歧它会选择最近的计数然后将另一块盘设为需要重建。在执行--force前最好先确认两块盘中哪一块是最新的事件计数更大的就是。组装成功后/proc/mdstat应该能看到 md2 的状态。接着检查文件系统fsck -f /dev/md2如果文件系统之前没有正常卸载fsck会提示有 journal 需要重放。执行fsck之后再尝试挂载或者通知群晖扫描。这里提醒一下fsck对 RAID1 来说只修文件系统层面的不一致不要用它对 md 设备做坏道修复那是另一个话题。如果两块盘的超级块都被清了怎么办有一种更严重的情况两块盘上的 md 超级块都失效了或者群晖在重建过程中写入了新的空白超级块。此时mdadm -E可能什么也读不出来。这时候需要重新创建阵列但注意——创建前必须确认分区没有被动过数据分区上的文件系统数据还在。创建命令mdadm --create /dev/md2 --levelraid1 --raid-devices2 --force /dev/sda3 /dev/sdb3不要加--assume-clean让系统做一次全盘同步。执行后文件系统会出现吗大概率不会直接出现因为创建新 md 设备会写入全新的 md 超级块但文件系统超级块在数据分区上应该还在。此时立即执行fsck -f /dev/md2然后尝试挂载到某个目录mkdir -p /mnt/test mount /dev/md2 /mnt/test ls /mnt/test如果文件系统超级块完好你会直接看到数据目录。这里要严肃提醒mdadm --create属于最后的险棋只建议在-E完全读不到数据、且你手里有完整备份冗余的前提下使用。因为它会覆盖原超级块区域在某些极端情况下会导致数据检索更困难。3.3 场景 C群晖 GUI 能显示存储空间但找不到哪个 md 对应DSM 里的“存储空间”和 md 设备的映射关系往往不直观。可以用下面的命令确定cat /proc/mdstat记录下所有 md 设备的编号然后逐一查看mdadm --detail /dev/md2 mdadm --detail /dev/md3State字段显示active表示正常运行inactive表示未组装。Array Slot字段里的0和1是阵列槽位编号不是 SATA 盘位。/dev/sda3里的a、b才是当前系统识别到的物理盘序。还有一种办法是查看目录ls -l /dev/disk/by-id/ ls -l /dev/disk/by-path/by-path可以关联到主板 SATA 口编号by-id关联到硬盘序列号。通过序列号对比哪块盘是物理上哪一块是最靠谱的。4. 重建进度监控与中途异常处理重建一旦跑起来你盯着进度条的同时还需要知道几个异常情况怎么处理。4.1 重建速度太慢如何调整重建速度主要受限于盘的读写速度但 mdadm 也允许你手动调节“同步速率”这个速率受/proc/sys/dev/raid/speed_limit_min和speed_limit_max控制。在黑群晖里默认值有时候被限制得很保守。查看当前限制cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max如果你的阵列还在重建可以临时调高echo 100000 /proc/sys/dev/raid/speed_limit_min echo 500000 /proc/sys/dev/raid/speed_limit_max单位是 KB/s。把最小限速调到 100000约 100MB/s最大 500000约 500MB/s重启后失效但重建期间足够用了。也可以在挂载状态下使用 bit map 来减少异常重启后的校验时间mdadm --grow /dev/md2 --bitmapinternal不过这个操作会占用少量空间也会在重建过程中增加一点 IO 负载黑群晖下非必要不建议开。4.2 重建过程中另一块盘也掉线了这是每个人都不愿意面对的情况。如果重建中另一块盘也报 I/O error/proc/mdstat里会显示md2 : active raid1 sdb3[1] sda3[2](F)(F)表示 faulty。此时阵列进入[U_]或[_U]类似状态唯一能做的就是立即检查硬件SATA 线是否松动、电源供电是否不足、硬盘温度是否过高。要先解决物理层问题否则再怎么重建都是白搭。如果确认物理连接没问题可以尝试把 faulty 盘从阵列中移除再重新加入mdadm --manage /dev/md2 --fail /dev/sda3 mdadm --manage /dev/md2 --remove /dev/sda3 mdadm --manage /dev/md2 --add /dev/sda3但如果故障盘已经出现大量坏道建议直接换盘不要强行 re-add。4.3 重建完成后需要做什么当/proc/mdstat中[UU]两侧都变成 U且没有 recovery/resync 进度时重建完成。这时候去 DSM 存储管理器里刷新一下往往存储空间状态会从“损毁”变成“正常”或者还显示“可修复”。如果还显示“可修复”再点一下 GUI 的修复按钮让它做一次快速修复。但不要以为到这步就万事大吉。RAID1 重建完成只代表 md 层恢复了文件系统层面未必干净。建议执行一次文件系统检查fsck -f /dev/md2如果文件系统较大这个命令会跑比较久但值得做。它会发现并修复因异常断电或阵列降级时产生的不一致索引。检查通过后重启一次群晖看看阵列是否能在开机时自动组装成功。这一步很重要很多修复后“复发”的案例本质问题就是重启后 mdadm 没有正确从磁盘引导文件里读到阵列信息。5. 黑群晖无法自动组装阵列的深层原因与长效修复如果你的黑群晖重启后阵列又恢复“损毁”状态或者把盘摘下来再插回去就找不到阵列基本可以判断为 mdadm 的配置文件或内核组装流程有问题。5.1 mdadm.conf 是否包含了你的阵列信息在群晖系统里/etc/mdadm.conf或/etc/raidtab管理着 md 设备的自动组装信息。黑群晖的这套配置文件在安装系统时生成正常情况下包含了所有阵列的 uuid 信息和成员盘路径。但当你换了引导、升级了 DSM 大版本或者更换了 SATA 控制器驱动后这个文件可能没有自动更新。我们可以在必要时手动把当前阵列信息写入配置文件。先用参数生成配置段mdadm --detail --scan /dev/md2输出的内容形如ARRAY /dev/md2 metadata1.2 namexxx:x uuidxxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx devices/dev/sda3,/dev/sdb3然后在/etc/mdadm.conf中追加或修改对应段落。建议先备份原配置cp /etc/mdadm.conf /etc/mdadm.conf.bak再写入mdadm --detail --scan /etc/mdadm.conf黑群晖的引导脚本会读取这个配置来决定启动时组装哪些 md 设备。需要注意如果里面出现了多余的 ARRAY 条目例如之前测试残留的 md127需要手动删掉否则可能干扰正常组装。5.2 盘序漂移问题的规避思路黑群晖在多次启动后内核识别 SATA 盘的顺序可能变化。比如上一次storage分区是/dev/sda3这次变成了/dev/sdc3如果 mdadm.conf 里还是老的devices/dev/sda3,/dev/sdb3组装时就会失败。更好的做法是让 mdadm 只按 uuid 而非设备路径去识别。将 mdadm.conf 里的 ARRAY 行简化成只有ARRAY /dev/md2 metadata1.2 UUIDxxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx去掉devices这一项系统启动时会通过 uuid 自动扫描各盘分区上的超级块找到匹配的成员。实测这个方法对盘序漂移的免疫效果很好。不过要注意一旦改用 UUID 识别同一个盘上的多个 partition 超级块必须一致否则可能出现错误匹配。做完修改后执行update-grub 2/dev/null reboot重新启动后验证/proc/mdstat是否能自动把 md2 组装成 active。5.3 关于硬盘休眠和掉盘的直接挂钩前面说过黑群晖硬盘休眠唤醒失败是掉盘的常见原因。手动修复阵列之后我强烈建议在 DSM 控制面板的“硬件和电源”里把硬盘休眠设置为“从不”或者至少排除阵列盘。因为黑群晖对硬盘休眠的实现是通过 hdparm 或 sdparm 命令发送 ATA 指令这在白群晖原装硬件上经过严格测试没有问题但黑群晖搭配各种 SATA 扩展卡、PCIE 转 SATA 卡时很多卡的固件并不支持每个盘独立休眠。唤醒时若一个盘响应超时内核就把这块盘标记为 faulty。为了阵列稳定牺牲一点功耗换可靠性值得。6. 手动重建之后的复盘哪些行为能防止下次再犯到现在你的 RAID1 阵列应该已经重新回到“正常”状态。趁这次故障的记忆还热乎建议做三件事第一开启 DSM 的通知推送并且不要把硬盘 SMART 异常当垃圾短信忽略。SMART 的Reallocated_Sector_Ct和Current_Pending_Sector两个指标只要开始增长就是盘在告诉你它撑不住了。这时候要做的是换盘而不是等到掉线之后再修复。第二给阵列加一个“演练”习惯。平时可以每个月 SSH 进去看一眼/proc/mdstat确认[UU]状态正常。顺带跑一次smartctl -a /dev/sda看看几个关键健康参数。这个习惯花不了两分钟但能让你对盘的劣化速度心里有数。第三如果你的 NAS 有额外的空盘位建议配置一块热备盘hot spare。在命令行里把一个空闲分区加入为热备盘当阵列任意成员盘掉线时系统会自动把热备盘拉入并开始重建无需人工干预。命令是把空闲分区直接 add 到 md 设备上但不作为正式成员群晖会自动识别其状态为sparemdadm --add /dev/md2 /dev/sdc3执行后再看mdadm --detail /dev/md2如果spare状态出现了这套自动切换机制就算生效了。在我自己跑黑群晖的这几年里这已经不是第一次用 SSH 手动救阵列了。相比白群晖 GUI 一键修复黑群晖的容错空间确实小一些但也正因为这样每一次故障都逼着你去理解 RAID 的本质mdadm 的超级块、事件计数、成员盘槽位、元数据版本这些概念在后来的故障排查中反复用到。下次再遇到“存储空间损毁”的通知你至少不会再慌到删池重建了。最后分享一个很实用的小技巧修复完成后记得把 DSM 的“存储空间”命名习惯改一改。在存储管理器里给每个共享文件夹加上明确的用途前缀比如“photo-archive”“work-sync”。下次如果只坏一块盘你从报错信息里能立刻判断出这个存储空间对应哪些数据、影响面有多大、是否需要优先抢救。这些细节关键时刻比任何命令都管用。