说实话折腾过黑群晖的人最怕看到的不是服务挂掉而是存储管理里那四个字存储空间损毁。第一反应基本都是“完了数据是不是没了”。但玩过几天 Linux 的人都知道在绝大多数 RAID1 场景下“损毁”不等于“全丢”它只是告诉你“镜像的两块盘之间有一块跟阵列失联了”。数据其实还完整躺在那块健康盘上问题在于怎么把掉队的那块盘拉回来让阵列恢复可用状态。这篇文章我会完全从命令行入手用 SSH 登进 DSM 系统讲解 RAID1 阵列重建的完整思路和操作流程。这套方法不挑设备白群晖、黑群晖、各种自组 NAS 只要跑的是 DSM原理都一样。适合手里设备已经出现“存储空间损毁”提示、或者想提前把修复流程搞明白的玩家。我会把每一步为什么要做、命令执行后应该出现什么结果、哪些地方容易翻车全都讲清楚尽量做到保姆级。1. 先搞清楚“存储空间损毁”背后发生了什么1.1 RAID1 的镜像机制和降级原理RAID1 的原理非常朴素两块硬盘写一模一样的内容一块挂了另一块还能顶住。但这个“顶住”是有代价的——阵列进入降级状态也就是磁盘阵列控制器视角里的 degraded。此时存储卷还能读写可一旦剩下的这块盘再出问题数据才是真的危险。在 DSM 系统里RAID1 并不是一个黑盒底层完全由 Linux 的 md 多磁盘管理框架接管。你看到的“存储空间损毁”在 mdadm 视角下通常是两种状态之一阵列降级有一块盘标记为 faulty 或 removed或者阵列本身状态干净但文件系统层报错。前者是盘掉了、线松了、盘序乱了导致的后者往往是被降级期间出现的异常写入、非正常断电折腾出来的。理解这个区别很重要因为修复动作完全不同。降级阵列要做的是把故障盘从阵列中踢出去然后重新加入一块好盘让 md 层自动重建镜像文件系统层损坏要做的则是先确认阵列成员健康再用 fsck 或 btrfs 工具修卷内部结构。这篇文章主要讲前一种也是最常见的情况。1.2 黑群晖下“损毁”常见的三种原因结合我自己维护过的几台设备DSM 报“存储空间损毁”绝大部分是下面三类第一类是物理盘掉线。SATA 线接触不良、硬盘供电不稳、硬盘本身出现坏道导致 IO 超时md 层在超时后会把盘踢出阵列。这种最常见也是最容易误判的——很多人以为硬盘报废了结果换根线就好了。第二类是盘没坏但阵列元数据乱了。比如异常重启、引导时两块盘的 superblock 状态不一致mdadm 无法确定谁是正确成员干脆降级或拒绝组装。第三类是黑群晖特有现象盘序变化。你插了块新盘、换了 SATA 口、动了引导参数系统里 /dev/sda、/dev/sdb 的对应关系发生漂移DSM 拿不到预期的盘位就会把存储空间标记成损毁。这种情况在真机上不大容易犯但在折腾黑群晖的人手里几乎人人都踩过。把这几种情况记在脑子里后面操作时就有了判断依据不会一上来就盲目重建。2. SSH 入场先给存储阵列做个体检2.1 开启 SSH 与登录注意点群晖默认不开 SSH。控制面板 → 终端机和 SNMP → 启用 SSH 功能端口默认 22不建议改到奇怪端口自己家用怎么方便怎么来但如果是暴露在公网环境强烈建议用密钥登录并做 IP 白名单。登录这一步Windows 用户直接用系统自带的 OpenSSH 客户端命令是ssh 你的用户名你的群晖IP如果你改过 SSH 端口记得加参数ssh -p 端口号 你的用户名你的群晖IP这里有个很多人不知道的细节DSM 的 SSH 登录用户名必须是你有管理员权限的账号。默认 admin 或者你自己创建的 administrators 组账号都可以。登录进来之后你会看到类似 Linux 的 shell 提示符但这个环境比较精简很多工具都没有不过 mdadm、smartctl 这些关键工具是自带的。登录后第一件事先看一下系统时间和当前运行的内核确认 DSM 服务正常uptime uname -a2.2 一条条看懂体检报告接下来是重头戏看阵列状态。第一命令永远是cat /proc/mdstat正常情况下你会看到类似下面的输出Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [raid0] [raid10] md2 : active raid1 sdb3[1] sda3[0] 1953382464 blocks super 1.2 [2/2] [UU] bitmap: 1/8 pages [8KB], 32KB chunk重点看[2/2]和后面的[UU]。[2/2]表示阵列总共需要 2 块盘、当前有 2 块盘工作[UU]表示两块盘状态都健康。如果你是[2/1] [U_]那就是有一块盘掉线了对应位置显示下划线或者代表 faulty 的字符。再看对应 RAID 设备的详细状态mdadm --detail /dev/md2这里我会注意几个字段State是active, degraded还是clean这决定了接下来做什么。Raid Devices和Working Devices看是否缺盘。Number列表里的State哪块盘是faulty哪块是active sync。如果是降级状态mdadm --detail 的输出里会明确写出故障盘例如/dev/sdb3显示faulty或者直接整行消失。还需要用df -h和cat /etc/mtab把/dev/md2和存储卷/volume1对应起来。确认你修的是哪一个 md 设备这一步别省修错了后果很严重。2.3 盘位定位别把好盘当成故障盘做任何操作之前必须确认故障盘到底对应物理机箱里的哪个盘位。这是我的血泪教训曾经有过一次盘序漂移系统认为故障的是 /dev/sdb实际上物理上出问题的却是另一块盘。如果盲操作等于把好盘踢掉。如何定位两条路第一用硬盘序列号。先列出所有磁盘的信息lsblk -o NAME,SIZE,MODEL,SERIAL,WWN再看 mdadm 里记录的是哪块盘的哪块分区例如/dev/sdb3那就到lsblk输出里找到sdb对应的SERIAL然后去机箱上对照盘体标签。第二黑群晖玩家常用的技巧在/sys/block/sdX/device/里读厂商和型号信息cat /sys/block/sdb/device/model cat /sys/block/sdb/device/vendor把序列号和型号抄下来物理盘位上肯定有对应的标签纸一对照就清楚了。如果机箱盘位不方便贴标签至少也要在操作前确认阵列里两块盘的序列号分别指向哪两个盘位。还有一个辅助手段直接对疑似故障盘做 SMART 检测smartctl -a /dev/sdb重点看SMART overall-health self-assessment test result是不是 PASSED再看Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable这几项有没有爆表。如果盘本身已经一堆坏道就别再让它回阵列了直接换新盘。3. 手动重建 RAID1从降级到恢复的完整流程3.1 准备阶段备份、快照以及一颗冷静的心先说一句可能得罪人的话如果卷里是独一份的数据而且你从来没做过备份那在动手之前先停一停。RAID 从来不是备份它只是在两块盘之间同步副本。重建过程中最怕的是误操作把健康盘上的数据搞没。最稳妥的做法是在开始重建前先把健康盘上的共享文件夹数据备份到外接硬盘或者另一台机器上。如果数据量太大实在不好备份至少把最关键的资料拷出来。这一步不是浪费时间是给自己留退路。如果有条件顺手给卷拍个快照。但在存储空间损毁的状态下DSM 的快照可能已经不可用所以别把宝押在快照上老老实实备份核心数据。3.2 确认故障盘把它摘离阵列假设我们通过cat /proc/mdstat和mdadm --detail /dev/md2确认了 md2 阵列降级故障盘是/dev/sdb3。先看这块盘上是不是还有残留的 RAID 成员信息mdadm --examine /dev/sdb3如果输出能看出它是 md2 的成员但状态为 faulty 或 removed那就执行摘除操作mdadm --fail /dev/md2 /dev/sdb3 mdadm --remove /dev/md2 /dev/sdb3第一条命令是把盘标记为故障第二条是从阵列中移除。如果第二步报Device or resource busy说明这块盘仍在被系统访问可以试试先停止相关服务或者用mdadm --remove --force /dev/md2 /dev/sdb3但 force 之前要确认没有进程在读写这块盘。群晖里最简单的方法是从 DSM 图形界面停用对应的存储空间如果 DSM 界面还能操作的话。3.3 清理故障盘残留的元数据摘除之后这块盘上的 superblock 信息还在。如果就这么直接重新加入mdadm 可能会认错老朋友拒绝重建。所以要先把残留的 RAID 元数据抹掉mdadm --zero-superblock /dev/sdb3这一步执行后没有任何输出是正常的可以用mdadm --examine /dev/sdb3再查一次如果显示No md superblock found说明已经清干净了。这里有个容易翻车的细节如果故障盘是整盘被替换成新盘新盘连分区都没有那还要先建分区。群晖的卷一般对应的是/dev/sdb3这种分区设备不是整块/dev/sdb。如果你拿一块全新硬盘直接mdadm --add /dev/md2 /dev/sdb大概率不会成功因为 md 层期望的是分区。如何给新盘分区用 fdisk 或者 parted。群晖系统里通常自带 fdiskfdisk /dev/sdb在 fdisk 交互界面里依次输入g创建 GPT 分区表n新建分区分区号建议和原来一致按回车用默认起始扇区大小上创建全盘分区最后w写盘。但要注意群晖默认的数据分区在盘上的位置有特定规律如果你完全照搬官方原盘的分区布局比较麻烦。一个更省心的办法是直接用好的那块盘作参考用sgdisk如果系统有把分区表拷贝过来sgdisk /dev/sda -R /dev/sdb sgdisk -G /dev/sdb第一行复制分区表到新盘第二行随机化新盘的 GUID防止两块盘因为 GUID 冲突被系统认成同一块盘。没装 sgdisk 的话可以用 fdisk 手动建分区然后把分区类型改成 Linux RAID autofd。新建分区不影响后续 mdadm 识别。3.4 把盘重新加入阵列现在到了关键一步把盘加回去mdadm --add /dev/md2 /dev/sdb3正常情况下这条命令没有输出。随后再敲一次cat /proc/mdstat你会看到类似这样的内容md2 : active raid1 sdb3[2] sda3[0] 1953382464 blocks super 1.2 [2/1] [U_] [.............] recovery 35.2% (688132992/1953382464) finish184.6min speed110000K/sec注意新加入的盘在[n]里的编号可能不是[1]而是[2]这很正常只要它在工作就行。[2/1]表示阵列有 2 个盘位、当前有 1 个可用后面跟着的[U_]表示一个健康一个在恢复中。有些情况下mdadm --add不生效没有任何提示但/proc/mdstat里也没有 sdb3。这时大概率是上一步 superblock 没清干净回去检查一下。3.5 等待 rebuild 并监控进度重建过程取决于硬盘容量和转速。一块 4TB 的盘从 0 到 100% 通常要 8 到 20 个小时具体看盘速和系统 IO 负载。重建期间系统负载会明显升高所有读写都会变慢这是正常的。监控进度的方式是watch -n 5 cat /proc/mdstat每 5 秒刷新一次看 recovery 百分比和 finish 时间。也可以手动读内核参数cat /sys/block/md2/md/sync_action cat /sys/block/md2/md/sync_completed重建过程中不建议重启机器更不建议拔盘。如果实在需要重启重启后cat /proc/mdstat一般会自动继续 resync但保险起见重启后先看一眼状态如果卡住了要手动触发echo repair /sys/block/md2/md/sync_actionrepair会重置同步状态继续跑但只有在确认阵列没有新错误时才用。等到[2/2] [UU]出现同时mdadm --detail /dev/md2里显示State: clean重建算是完成了。但别高兴太早此时还要检查文件系统层是否正常。3.6 重建完成后验证文件系统与重新挂载md 层恢复了DSM 不一定立刻认账。查看卷对应的实际文件系统类型blkid /dev/md2输出里TYPEbtrfs或TYPEext4。如果是 ext4可以对阵列做只读检查e2fsck -f -n /dev/md2-n表示只检测不修复确认错误不多再考虑-f -y自动修复。注意在存储空间已经挂载的情况下不要跑 e2fsck否则可能把卷搞坏。群晖的卷位置挂载很特殊通常会自动挂到/volume1所以如果 DMS 还没认出来不要急着手动 mount先确保 md 层全绿然后重启系统让 DSM 自己重新识别。如果是 btrfs查错手段是btrfs device stats /dev/md2 btrfs filesystem check /dev/md2但 btrfs check 在卷已挂载时不能执行而且--repair参数风险极高非救援场景不要碰。通常群晖会在 btrfs 元数据出问题时自动修复如果你的情况是刚重建完先重启看 DSM 是否自动挂载。如果重启后 DSM 依然显示存储空间损毁但/proc/mdstat是干净的 [UU]那问题大概率在文件系统层需要用 LiveCD 启动到 Linux 环境做 fsck。不过这是另一个话题后面常见问题里我会讲排查思路。4. 实操高频问题与黑群晖专属避坑4.1 常见报错速查表把我在实操里遇到过的典型报错整理一下方便你对照排查。现象可能原因处理方法mdadm --add后无反应/proc/mdstat 没变化盘上残留元数据或分区类型不是 Linux RAIDmdadm --zero-superblock后重试检查分区类型mdadm --remove报 Device busy卷正被占用盘仍在线参与阵列停用存储空间或先--fail再--removeresync 卡在某个百分比不动坏道导致 IO 卡死或 io 负载过高查 SMART 坏道情况降低负载必要时echo repair重建完成后 DSM 仍报损毁文件系统层错误非 md 层问题重启验证btrfs/ext4 检查修复重启后阵列变成 inactivemdadm 未能自动组装mdadm --assemble --scan --force后查看状态mdadm --assemble 报设备冲突两块盘 GUID 冲突或 superblock uuid 相同用--updatesuper-minor或mdadm --examine仔细核对卷显示只读文件系统以只读挂载保护数据备份后重新挂载修复文件系统很多报错表面看是命令执行失败实际是状态机没到位比如盘还在阵列里就尝试 add、元数据没清就 add、设备还被 vold 占用就 remove。遇到报错别慌先用cat /proc/mdstat和mdadm --detail /dev/mdX确认现状再决定下一步。4.2 黑群晖的特殊情况盘序错乱、SATA 控制器、引导参数黑群晖和原厂群晖最大的区别在于底层硬件不固定主板上多了各种 SATA 控制器、PCIe 转 SATA 卡、直通卡导致盘序问题特别突出。开机后/dev/sda可能不是物理上第一个盘位这直接影响你对阵列成员盘位号的判断。最稳的做法是用序列号盘位不要用 sdX 字母。每次操作前执行lsblk -o NAME,SERIAL,MODEL,SIZE记录每个 sdX 的序列号再和机箱上的盘位进行映射。这个过程很枯燥但值得花几分钟做因为整个重建流程中最大风险就是选错盘。另外一个黑群晖特有问题引导参数SataPortMap配置不当。如果这个参数没设置对某些 SATA 控制器端口可能不被识别导致拔插硬盘后盘序漂移DSM 和管理层找不到原来的卷。遇到开机后 mdstat 里找不到 md2但盘上数据完好时优先检查引导配置再手动mdadm --assemble。4.3 如果两块盘都掉线了怎么救这是个极端情况但真的会发生。某次异常断电后系统可能对两块盘都失去信任md 设备直接显示 inactive 或者干脆不出现。这种时候不要急着--zero-superblock因为所有盘上的元数据都是宝贵线索。先用mdadm --examine /dev/sda3 /dev/sdb3看两块盘各自的 superblock 信息重点看 UUID 和 Events事件计数。Events 是阵列每次状态变化时递增的计数器谁的 Events 大谁的数据就更新。正常操作是mdadm --assemble --scan --force如果失败指定具体设备mdadm --assemble /dev/md2 /dev/sda3 /dev/sdb3 --force--force让 mdadm 相信两块盘能组成阵列强制组装。但这一步有风险如果两块盘上的数据本来就不同步mdadm 只能根据事件计数选择较新的一份另一份会被当作过期成员丢弃。所以强制组装前一定要先备份那种看不出来价值却非常重要的文件单独克隆镜像也可以但对家用玩家来说至少要做到“确认两块盘中的一份数据你能接受”。4.4 重建期间的操作禁忌重建不是打游戏没有后悔药。下面这几件事是绝对的红线第一不要在重建过程中拔硬盘。重建期间阵列对故障容错能力极低拔走健康盘等于让阵列失去全部数据副本。第二不要在重建过程中重启系统。如果非要重启也至少等重建完成或确认 sync 能断点续跑。第三不要同时执行两个阵列的重建。有多块盘同时掉线的场景务必逐块处理。第四不要盲目跑btrfs check --repair或e2fsck -y这类带自动修复的命令。文件系统修复工具在错误的时机运行很可能把原本可读的数据改成不可读。还有一个小技巧如果重建速度慢到无法忍受可以临时提升同步速度参数echo 200000 /proc/sys/dev/raid/speed_limit_min echo 500000 /proc/sys/dev/raid/speed_limit_max单位是 KB/s。但这会让磁盘长时间高负载如果你的盘本来就半死不活还是会卡住问题不在速度参数而是盘本身健康不达标。5. 修复后的收尾与防复发建议5.1 重建完成后必做的几件事等[UU]全绿第一件事不是去 NAS 上看电影而是把这几件事做完才算真正收工。确认 DSM 存储管理器状态。登录 DSM 图形界面看一眼存储空间是否已经恢复为“正常”。如果你是在 DMS 提示损毁的情况下走的命令行重建图形界面刚打开时可能还显示异常等一两分钟再刷新它通常会自动同步状态。做一次完整 SMART 检测。对刚刚归队的那块盘执行smartctl -t long /dev/sdb长检测少则两三个小时多则十几小时。跑完后用smartctl -l selftest /dev/sdb看检测结果如果最后一行是Completed without error这块盘才是真正健康的状态。顺手把 mdadm 的配置刷新一遍让系统对当前阵列记录更准确mdadm --detail --scan /etc/mdadm.conf群晖系统一般会自动维护这个文件但手动执行没有坏处尤其是黑群晖换过引导、插过盘之后。5.2 让 RAID1 更抗造的日常策略阵列重建这件事治标更要治本。吃过一次亏之后我给自己定了几条规矩分享出来供参考。第一别再裸奔了RAID1 只是冗余不是备份。至少把照片、文档、数据库定期同步到另一台机器或者网盘哪怕是 rsync 单向推送到冷备盘也比什么都没有强。第二加一块热备盘。DSM 支持在存储池里设置热备盘Hot Spare只要阵列出现降级备盘立刻自动顶上并开始重建把人工干预时间从几小时压缩到几分钟。对不擅长命令行的人来说这是性价比最高的保险。第三定期看 SMART 指标。每个月花几十秒跑一次smartctl -a /dev/sda重点关注Reallocated_Sector_Ct和Current_Pending_Sector这两个数值只要持续上涨就是盘在向你告别。第四给 NAS 配上 UPS。RAID 重建过程中突然断电等于把刚缝好的伤口又撕开而且很可能造成新盘和旧盘的事件计数不一致让系统重新陷入“不知道该信谁”的状态。如果你照着这个流程走完了最后注意一件事重建完成后把 DSM 里“存储空间损毁”的历史日志清理或忽略掉避免之后误判为阵列又有问题。很多人在这一步被误导反复折腾一个已经健康的阵列。我在多次手动重建过程中最大的体会是RAID1 阵列本身并不脆弱脆弱的是我们对盘位、盘状态、元数据这三样东西的确认习惯。只要每一步都先确认再动手不靠猜、不靠赌绝大多数“损毁”都能在命令行下救回来。尤其是黑群晖玩家命令行的灵活性其实比图形界面高得多只是要求你用之前先把每一步的原理想清楚。