看到“存储空间损毁”这六个字玩黑群晖的人基本都懂那种心里一沉的感觉。我前阵子就亲手把一台双盘RAID1的黑群晖救回来了全程靠SSH一条一条敲命令没靠群晖图形界面。先说结论只要硬盘没有物理性死亡数据分区本身没有被完全写花这套手动重建RAID1的流程成功率相当高。接下来我会把判断阵列状态、确认盘符、降级移除故障盘、复制分区表、重新加入新盘到等待同步完成的整条链路掰开讲清楚。适合遇到“存储空间损毁”提示的黑群晖用户、NAS维护者以及所有想搞明白Linux mdraid底层逻辑的人参考。照着操作前先把重要数据备份好别指望教程能帮你兜底。1. 故障分析先从“存储空间损毁”说起1.1 群晖RAID1的底层结构mdraid与分区布局群晖的RAID1从底层看就是Linux标准的mdraid。你执行的所有操作本质都是在跟mdadm打交道群晖图形界面只是给mdadm包了一层皮。DSM会把每块硬盘划分成几个分区第一个分区用于引导相关几百MB到几个GB第二个分区是系统核心第三个分区才是用户数据。以最常见的双盘安装为例两块硬盘的p1组成md0p2组成md1p3组成md2。你看到的“存储空间1”一般就挂在/dev/md2上。之所以要理解这层结构是因为当系统提示“存储空间损毁”时可能是md2出了问题也可能是md0/md1连带导致DSM判断异常。只有先识别是哪一层坏了修复才精准。我见过有人在GUI里对着“存储空间1”折腾半天其实真正掉的是系统分区所在的md1数据分区还活着。这种“找错病灶”的操作在SSH里扫一眼/proc/mdstat就能避免。1.2 “存储空间损毁”是到底怎么发生的先说两个容易混淆的状态“存储空间降级”和“存储空间损毁”。降级意味着阵列里还有一块盘在正常工作系统仍然能读写只是冗余没有了此时存储管理器会提示“修复”换上新盘就能自动重建。损毁则往往是双盘同时掉线、阵列元数据损坏或者其中一块盘掉线时另一块也大面积报错导致md设备直接进入inactive状态。触发损毁的原因我见过的主要有三类一是断电尤其是异常断电RAID1写缓存里的元数据来不及落盘二是SATA线松动或背板接触不良一块盘突然从总线上消失阵列标记为degraded长时间不处理第二块盘出坏道后整体崩溃三是硬盘本身物理坏道扩散SMART报警后没有及时换盘。从DSM界面的表现来看损毁状态下存储管理器可能显示“存储空间x损毁”并且修复按钮是灰的或者点修复之后几秒钟又弹回原样。这并不代表数据没了很多时候只是阵列层的元数据不一致导致系统不敢自动挂载。这时候图形界面能做的很有限SSH才能看到真实状态。1.3 什么时候必须上SSH手动操作三种典型场景第一种GUI点击修复失败一直提示类似“无法修复存储空间”。第二种系统启动后存储空间没自动挂载但磁盘都还在。第三种你需要把阵列拆开重新组装比如换引导、换主板后阵列识别不全。出现这些情况手动用mdadm反而更直接。你能清楚看到每个md设备的状态、每个成员盘是否在线也能自己决定是先保住单盘数据还是强制启动阵列。当然手动操作的前提是理解每一步在干什么不然乱敲命令比不修更容易搞坏数据。这也是我写这篇教程的初衷把底层逻辑讲明白而不是丢给你几条命令让你照抄。2. SSH登录与阵列状态摸底2.1 开启SSH并用终端连接群晖在群晖控制面板里找到“终端机和SNMP”勾选“启用SSH功能”端口默认22设个高强度密码。黑群晖的引导系统基于Linux所以SSH服务开着就能连。Windows用户推荐Xshell、MobaXterm或者Bitvise SSH Client这三款都比较顺手macOS和Linux直接终端执行ssh。用VS Code的Remote SSH插件也能连但建议先用纯终端把网络链路确认通再折腾插件不然容易分不清是SSH问题还是插件问题。连接命令ssh admin192.168.1.100登录后执行sudo -i把权限提到root后面所有mdadm命令都必须在root身份下跑。注意群晖默认不允许root远程登录都是先普通用户登录再提权。如果你习惯免密登录可以把本地公钥加到群晖的/root/.ssh/authorized_keys里。有些引导版本中authorized_keys权限必须设置为600目录700否则SSH会拒绝。这一点我踩过坑。要是连接不上先ping一下IP再用telnet 192.168.1.100 22或者nc -vz 192.168.1.100 22确认端口通不通最后检查群晖防火墙有没有放行22端口。很多时候不是SSH服务的问题而是防火墙把端口挡了。2.2 三步摸清阵列现状登录后别急着动手先用几条命令把家底摸清楚。第一步cat /proc/mdstat看阵列状态。这个文件列出了所有软raid设备以及它们的成员盘。正常状态会显示类似md2 : active raid1 sata1p3[0] sata2p3[1]后面还有resync、recovery、reshape等进度字段。如果你看到[U_]或[_U]说明有一块盘掉了。看到inactive说明阵列没有被激活。第二步lsblk看磁盘和分区。群晖里盘符可能是/dev/sata1、/dev/sata2DSM新版本常见也可能是/dev/sda、/dev/sdb用lsblk能看到整盘和分区对应关系。第三步df -h看volume挂载点再mount | grep md看md设备挂在哪里。结合mdadm --detail /dev/md2看阵列成员盘的详细信息。你会发现群晖界面告诉你的“存储空间损毁”在命令行里往往只是“md2缺了一个盘”这么简单。2.3 动手前的备份与记录无论是什么级别的故障动阵列之前先想清楚能不能接受最坏结果。理想情况下健康盘上的数据已经有了备份副本。实在没有备份我建议先把阵列停掉单独挂载健康盘看看能不能把关键目录复制出来。动手前在纸上写清楚这几项故障盘在哪个槽位、对应的设备名是sata1还是sata2、阵列是md0还是md2、健康盘上的数据分区UUID是什么。写下来不是多此一举我见过太多人盯着终端敲了半小时结果把盘符搞反把好盘拔了最后数据全丢。这一步怎么强调都不为过。3. 手动重建RAID1的完整操作流程3.1 第一步把故障盘从阵列中降级并移除假设你已经确定故障盘是/dev/sata2p3这个分区是数据分区md2的成员。第一件事是告诉阵列这块盘我不再信任了。mdadm --manage /dev/md2 --fail /dev/sata2p3 mdadm --manage /dev/md2 --remove /dev/sata2p3--fail会把盘标记为failed--remove把它从阵列里摘出去。执行之后cat /proc/mdstat应该只看到sata1p3[0]在干活阵列状态变成degraded但系统还能正常读写。有几个常见情况要注意。如果盘是突然掉线系统可能已经自动把它标记为failed你直接remove即可。如果mdadm提示设备不存在说明Linux已经彻底不认得这个设备那就别纠结直接从物理上拔盘。如果阵列整体处于inactive这一步要先解决我放在后面问题汇总里讲。总之先让阵列在单盘模式下稳定运行这是后续所有操作的前提。3.2 第二步物理换盘与分区表复制移除故障盘之后把机箱断电拆下故障盘换上同容量的新盘重新开机。除非你确定阵列处于degraded状态且背板支持热插拔否则别带电拔盘。新盘不需要初始化文件系统。群晖RAID1里的用户文件系统建立在md设备上不是建立在单硬盘分区上的。你真正要做的是让新盘的盘面结构和原先故障盘一样分区数量、分区边界、分区大小完全一致。最省事的办法是拿健康盘的分区表直接复制过来。假设健康盘是/dev/sata1新盘是/dev/sata2执行sfdisk -d /dev/sata1 /tmp/sata1.txt sed -i s/sata1/sata2/g /tmp/sata1.txt sfdisk /dev/sata2 /tmp/sata1.txtsfdisk -d导出的分区表文件里有一行device: /dev/sata1用sed替换一下更保险。执行完后让内核重新读取分区表blockdev --rereadpt /dev/sata2再用lsblk确认新盘的p1、p2、p3都分出来了。如果你用的黑群晖引导环境里没有sfdisk只有fdisk也可以手动建分区但一定要对着健康盘的分区起始扇区来不能凭感觉。3.3 第三步把新盘加入阵列触发重建分区就绪之后把新盘的数据分区挂到阵列里mdadm --manage /dev/md2 --add /dev/sata2p3如果之前这块盘或者分区上残留了别的md超级块add会报错提示device or resource busy或者干脆add不进去。解决办法是先把超级块清零mdadm --zero-superblock /dev/sata2p3然后再add。add成功之后内核会自动发现“这是RAID1缺少的成员”开始resync。这个过程不用你手动触发内核会在几秒内自动开始。如果没开始执行mdadm --detail /dev/md2看看状态或者确认一下内核日志dmesg | tail。这里有个细节群晖会同时有md0、md1、md2如果系统提示你“系统分区”也有问题需要按同样的流程依次修复先修系统相关的小阵列再修数据阵列。一般情况下先保证md2挂载恢复用户数据优先。3.4 第四步等待同步并校验文件系统执行完add马上cat /proc/mdstat你会看到类似md2 : active raid1 sata2p3[1] sata1p3[0] [....] resync 24.4% (xxx/xxx) finish...这说明重建已经在跑。等resync到100%再用mdadm --detail /dev/md2确认两个设备状态都正常。接下来校验文件系统。群晖默认的文件系统是btrfs重启后系统大概率会自动挂载。如果没挂载先执行btrfs device scan然后尝试挂载mount /dev/md2 /mnt或者挂载时加degraded参数适合只有单盘能挂载的场合mount -o degraded /dev/md2 /mnt如果是ext4用fsck -f /dev/md2。全部正常后回到DSM图形界面刷新存储管理器存储空间应该变成“正常”。这里提醒一句重建完成后别立刻往里面塞大量数据先让系统跑一两天观察有没有新的IO错误冒出来。4. 重建期间的监控与系统保护4.1 看进度与判断重建速度重建监控的核心就一个文件/proc/mdstat。它会实时显示resync的百分比和剩余量也会显示是哪个md设备在同步。想知道更详细的信息用mdadm --detail /dev/md2里面会列出rebuild/resync状态、每个成员盘的健康状态。同步速度不是一个固定值取决于总线带宽、硬盘持续读写速度和CPU占用。常见的SATA机械盘重建大概在80-150MB/s之间SSD阵列会快很多200MB/s以上。比如一个2TB数据分区实际有效数据可能只有几百GB但因为RAID1是全盘镜像同步重建时间通常按整盘容量估算。你可以用剩余MB数除以当前速度大致算出还要多久。内核也提供了速度限制参数在/proc/sys/dev/raid/speed_limit_min和speed_limit_max。默认min是1000KB/smax很多系统设成200000KB/s。如果你发现重建被限速了可以临时拉高echo 100000 /proc/sys/dev/raid/speed_limit_min echo 400000 /proc/sys/dev/raid/speed_limit_max注意这只是临时调整重启恢复默认。正常情况下不建议动除非你确认当前速度低是因为限速而不是硬盘自身太慢。4.2 重建期间千万不要做的事不要重启NAS。重建没完成就重启新盘可能已经从阵列里摘出去或者resync从头再来一次极端情况下阵列变成inactive。不要往阵列里疯狂写数据。虽然RAID1重建时系统还可以读写但高负载会拖慢同步也会放大IO错误概率。最好暂停下载任务、视频转码等重负载服务。不要去动另一块健康盘。有的人嫌健康盘响应慢想去摸摸它是不是坏了结果一不小心把盘从阵列里手动fail了那就真变成裸奔了。注意散热。机械盘持续读写一两个小时机箱风扇不够的话温度能飙到50度以上高温环境下重建容易诱发新坏道。机箱如果小把盖板打开用个风扇直吹都是有效的土办法。别在重建期间改阵列结构比如加盘、换RAID级别、扩容。这些操作要等同步完成、存储管理器确认正常之后再说。4.3 理解超级块为什么新盘要清掉旧数据mdadm会在每一块成员盘上写超级块记录阵列的UUID、RAID级别、成员顺序等元数据。当你往阵列里加一块之前用过的盘如果不把这块盘上的旧超级块清掉内核可能误以为它是另一个阵列的成员拒绝添加。mdadm --zero-superblock /dev/sata2p3就是把这个位置的元数据擦掉让它变成一张“白盘”。另外群晖的RAID元数据布局和标准Linux略有差别但底层还是在/dev/sataXpY上写超级块。这就是为什么你手动add之前必须先确认分区编号是否和健康盘一致。分错区、用错盘符轻则重建失败重则把另一块正常盘的数据卷进新的resync里数据就真没了。5. 典型故障与排查经验5.1 问题一阵列变成inactive怎么办阵列inactive是最让人紧张的状态因为它意味着系统根本不把md设备当可用设备挂载。现象通常是/proc/mdstat里显示md2 : inactive sata1p3[1]或者干脆没有md2条目。处理思路是先把阵列手动组装起来mdadm --stop /dev/md2 mdadm --assemble /dev/md2 /dev/sata1p3 /dev/sata2p3如果只有一块盘健康可以只写健康盘的成员mdadm --assemble --force /dev/md2 /dev/sata1p3--force会强制使用剩余成员启动阵列在确认这块盘数据基本正常的情况下可以试。启动后立刻把重要数据拷贝出来。这种能救但救完别指望阵列还能继续正常服役该换盘换盘该备份备份。5.2 问题二add新盘时报capacity too small如果新盘容量比阵列记录的最小成员容量还小mdadm会直接拒绝提示capacity too small。比如原来的故障盘是一块1TB盘你换了一块800GB的盘分区表复制的起点和终点不一样阵列认为是有效容量不足。要么换回规格相同的盘要么把分区规划成不超过阵列认可边界。这种提示不是数据损坏只是容量校验没过别慌。还有一种add失败的常见原因是device or resource busy说明分区正被别的设备占用。这种情况先看cat /proc/mdstat确认它没被别的md设备占用再用lsblk确认没有挂载点必要时直接重启再执行add。5.3 问题三重建完成后存储空间仍然显示损毁阵列resync到100%不代表DSM界面就一定恢复“正常”。因为群晖的存储空间还依赖文件系统层尤其是btrfs如果不一致DSM依然会报警。我的排查顺序是先确认底层阵列健康mdadm --detail /dev/md2两个成员都应该是active sync。再看文件系统能不能挂载mount /dev/md2 /mnt失败就btrfs device scan后再试。如果btrfs报错先btrfs filesystem check /dev/md2按提示修复。群晖里运行这些命令要小心最好先备份btrfs元数据。最后重启NAS让DSM重新扫描一遍通常到这一步存储管理器就恢复“正常”了。还有一种是系统分区md1重建不完整导致DSM对存储管理器报出错误的不可用判断这种需要把md1也加到阵列里补同步。5.4 问题四盘符漂移换盘之后BIOS、主板端口的枚举顺序变化/dev/sata1和/dev/sata2的对应关系可能对调。严格来说Linux在枚举时按端口命名不同引导版本表现不一样但只要你换了盘就一定要用分区UUID确认身份不要只看盘符顺序。用lsblk -f /dev/sata1或者blkid /dev/sata1p3拿到每个分区真实UUID。健康盘复制过来的分区表和原盘一致UUID也会被复制但md超级块里的UUID是阵列自己的指向md2。物理盘的身份可以结合smartctl -i /dev/sata1查看序列号来确认。一句话以序列号和UUID为准别信盘符。5.5 常见问题速查表现象可能原因排查命令处理建议存储空间损毁提示阵列降级或inactivecat /proc/mdstatmdadm --detail /dev/md2先组装/启动阵列再换盘重建add报resource busy分区被占用或残留superblocklsblkcat /proc/mdstat清空超级块后重新addadd报capacity too small新盘容量不足lsblk查看容量换同规格盘或调整分区边界重建很慢或卡住硬盘坏道、限速、高负载smartctl -a /dev/sataXiostat -x 1检测健康盘暂停负载临时调高限速重建完仍报警文件系统btrfs错误btrfs filesystem check /dev/md2备份元数据后修复必要时degraded挂载导出数据掉盘后开机卡引导系统分区md0/md1损坏cat /proc/mdstat单盘启动后拷贝数据重建系统分区修完这一次我对RAID1的心态反而更敬畏了。它防的是单块盘故障不是备份它能扛住一次坏道扩散但扛不住你两年不备份加上机箱里还有一根劣质SATA线。手动重建阵列这套流程说白了就五步确认掉盘、fail掉、remove掉、换完盘add回来、等resync。真正难的不是命令而是遇到问题时能不能保持冷静不把好盘拿去陪葬。最后再分享一个我自己的习惯阵列恢复正常之后顺手把mdadm --detail --scan的输出备份一份。下次再碰到类似问题直接照着重建能省不少时间。希望这篇东西能让你在SSH窗口前少慌几分钟多保住几TB数据。
黑群晖存储空间损毁手动修复：SSH命令行重建RAID1全流程
看到“存储空间损毁”这六个字玩黑群晖的人基本都懂那种心里一沉的感觉。我前阵子就亲手把一台双盘RAID1的黑群晖救回来了全程靠SSH一条一条敲命令没靠群晖图形界面。先说结论只要硬盘没有物理性死亡数据分区本身没有被完全写花这套手动重建RAID1的流程成功率相当高。接下来我会把判断阵列状态、确认盘符、降级移除故障盘、复制分区表、重新加入新盘到等待同步完成的整条链路掰开讲清楚。适合遇到“存储空间损毁”提示的黑群晖用户、NAS维护者以及所有想搞明白Linux mdraid底层逻辑的人参考。照着操作前先把重要数据备份好别指望教程能帮你兜底。1. 故障分析先从“存储空间损毁”说起1.1 群晖RAID1的底层结构mdraid与分区布局群晖的RAID1从底层看就是Linux标准的mdraid。你执行的所有操作本质都是在跟mdadm打交道群晖图形界面只是给mdadm包了一层皮。DSM会把每块硬盘划分成几个分区第一个分区用于引导相关几百MB到几个GB第二个分区是系统核心第三个分区才是用户数据。以最常见的双盘安装为例两块硬盘的p1组成md0p2组成md1p3组成md2。你看到的“存储空间1”一般就挂在/dev/md2上。之所以要理解这层结构是因为当系统提示“存储空间损毁”时可能是md2出了问题也可能是md0/md1连带导致DSM判断异常。只有先识别是哪一层坏了修复才精准。我见过有人在GUI里对着“存储空间1”折腾半天其实真正掉的是系统分区所在的md1数据分区还活着。这种“找错病灶”的操作在SSH里扫一眼/proc/mdstat就能避免。1.2 “存储空间损毁”是到底怎么发生的先说两个容易混淆的状态“存储空间降级”和“存储空间损毁”。降级意味着阵列里还有一块盘在正常工作系统仍然能读写只是冗余没有了此时存储管理器会提示“修复”换上新盘就能自动重建。损毁则往往是双盘同时掉线、阵列元数据损坏或者其中一块盘掉线时另一块也大面积报错导致md设备直接进入inactive状态。触发损毁的原因我见过的主要有三类一是断电尤其是异常断电RAID1写缓存里的元数据来不及落盘二是SATA线松动或背板接触不良一块盘突然从总线上消失阵列标记为degraded长时间不处理第二块盘出坏道后整体崩溃三是硬盘本身物理坏道扩散SMART报警后没有及时换盘。从DSM界面的表现来看损毁状态下存储管理器可能显示“存储空间x损毁”并且修复按钮是灰的或者点修复之后几秒钟又弹回原样。这并不代表数据没了很多时候只是阵列层的元数据不一致导致系统不敢自动挂载。这时候图形界面能做的很有限SSH才能看到真实状态。1.3 什么时候必须上SSH手动操作三种典型场景第一种GUI点击修复失败一直提示类似“无法修复存储空间”。第二种系统启动后存储空间没自动挂载但磁盘都还在。第三种你需要把阵列拆开重新组装比如换引导、换主板后阵列识别不全。出现这些情况手动用mdadm反而更直接。你能清楚看到每个md设备的状态、每个成员盘是否在线也能自己决定是先保住单盘数据还是强制启动阵列。当然手动操作的前提是理解每一步在干什么不然乱敲命令比不修更容易搞坏数据。这也是我写这篇教程的初衷把底层逻辑讲明白而不是丢给你几条命令让你照抄。2. SSH登录与阵列状态摸底2.1 开启SSH并用终端连接群晖在群晖控制面板里找到“终端机和SNMP”勾选“启用SSH功能”端口默认22设个高强度密码。黑群晖的引导系统基于Linux所以SSH服务开着就能连。Windows用户推荐Xshell、MobaXterm或者Bitvise SSH Client这三款都比较顺手macOS和Linux直接终端执行ssh。用VS Code的Remote SSH插件也能连但建议先用纯终端把网络链路确认通再折腾插件不然容易分不清是SSH问题还是插件问题。连接命令ssh admin192.168.1.100登录后执行sudo -i把权限提到root后面所有mdadm命令都必须在root身份下跑。注意群晖默认不允许root远程登录都是先普通用户登录再提权。如果你习惯免密登录可以把本地公钥加到群晖的/root/.ssh/authorized_keys里。有些引导版本中authorized_keys权限必须设置为600目录700否则SSH会拒绝。这一点我踩过坑。要是连接不上先ping一下IP再用telnet 192.168.1.100 22或者nc -vz 192.168.1.100 22确认端口通不通最后检查群晖防火墙有没有放行22端口。很多时候不是SSH服务的问题而是防火墙把端口挡了。2.2 三步摸清阵列现状登录后别急着动手先用几条命令把家底摸清楚。第一步cat /proc/mdstat看阵列状态。这个文件列出了所有软raid设备以及它们的成员盘。正常状态会显示类似md2 : active raid1 sata1p3[0] sata2p3[1]后面还有resync、recovery、reshape等进度字段。如果你看到[U_]或[_U]说明有一块盘掉了。看到inactive说明阵列没有被激活。第二步lsblk看磁盘和分区。群晖里盘符可能是/dev/sata1、/dev/sata2DSM新版本常见也可能是/dev/sda、/dev/sdb用lsblk能看到整盘和分区对应关系。第三步df -h看volume挂载点再mount | grep md看md设备挂在哪里。结合mdadm --detail /dev/md2看阵列成员盘的详细信息。你会发现群晖界面告诉你的“存储空间损毁”在命令行里往往只是“md2缺了一个盘”这么简单。2.3 动手前的备份与记录无论是什么级别的故障动阵列之前先想清楚能不能接受最坏结果。理想情况下健康盘上的数据已经有了备份副本。实在没有备份我建议先把阵列停掉单独挂载健康盘看看能不能把关键目录复制出来。动手前在纸上写清楚这几项故障盘在哪个槽位、对应的设备名是sata1还是sata2、阵列是md0还是md2、健康盘上的数据分区UUID是什么。写下来不是多此一举我见过太多人盯着终端敲了半小时结果把盘符搞反把好盘拔了最后数据全丢。这一步怎么强调都不为过。3. 手动重建RAID1的完整操作流程3.1 第一步把故障盘从阵列中降级并移除假设你已经确定故障盘是/dev/sata2p3这个分区是数据分区md2的成员。第一件事是告诉阵列这块盘我不再信任了。mdadm --manage /dev/md2 --fail /dev/sata2p3 mdadm --manage /dev/md2 --remove /dev/sata2p3--fail会把盘标记为failed--remove把它从阵列里摘出去。执行之后cat /proc/mdstat应该只看到sata1p3[0]在干活阵列状态变成degraded但系统还能正常读写。有几个常见情况要注意。如果盘是突然掉线系统可能已经自动把它标记为failed你直接remove即可。如果mdadm提示设备不存在说明Linux已经彻底不认得这个设备那就别纠结直接从物理上拔盘。如果阵列整体处于inactive这一步要先解决我放在后面问题汇总里讲。总之先让阵列在单盘模式下稳定运行这是后续所有操作的前提。3.2 第二步物理换盘与分区表复制移除故障盘之后把机箱断电拆下故障盘换上同容量的新盘重新开机。除非你确定阵列处于degraded状态且背板支持热插拔否则别带电拔盘。新盘不需要初始化文件系统。群晖RAID1里的用户文件系统建立在md设备上不是建立在单硬盘分区上的。你真正要做的是让新盘的盘面结构和原先故障盘一样分区数量、分区边界、分区大小完全一致。最省事的办法是拿健康盘的分区表直接复制过来。假设健康盘是/dev/sata1新盘是/dev/sata2执行sfdisk -d /dev/sata1 /tmp/sata1.txt sed -i s/sata1/sata2/g /tmp/sata1.txt sfdisk /dev/sata2 /tmp/sata1.txtsfdisk -d导出的分区表文件里有一行device: /dev/sata1用sed替换一下更保险。执行完后让内核重新读取分区表blockdev --rereadpt /dev/sata2再用lsblk确认新盘的p1、p2、p3都分出来了。如果你用的黑群晖引导环境里没有sfdisk只有fdisk也可以手动建分区但一定要对着健康盘的分区起始扇区来不能凭感觉。3.3 第三步把新盘加入阵列触发重建分区就绪之后把新盘的数据分区挂到阵列里mdadm --manage /dev/md2 --add /dev/sata2p3如果之前这块盘或者分区上残留了别的md超级块add会报错提示device or resource busy或者干脆add不进去。解决办法是先把超级块清零mdadm --zero-superblock /dev/sata2p3然后再add。add成功之后内核会自动发现“这是RAID1缺少的成员”开始resync。这个过程不用你手动触发内核会在几秒内自动开始。如果没开始执行mdadm --detail /dev/md2看看状态或者确认一下内核日志dmesg | tail。这里有个细节群晖会同时有md0、md1、md2如果系统提示你“系统分区”也有问题需要按同样的流程依次修复先修系统相关的小阵列再修数据阵列。一般情况下先保证md2挂载恢复用户数据优先。3.4 第四步等待同步并校验文件系统执行完add马上cat /proc/mdstat你会看到类似md2 : active raid1 sata2p3[1] sata1p3[0] [....] resync 24.4% (xxx/xxx) finish...这说明重建已经在跑。等resync到100%再用mdadm --detail /dev/md2确认两个设备状态都正常。接下来校验文件系统。群晖默认的文件系统是btrfs重启后系统大概率会自动挂载。如果没挂载先执行btrfs device scan然后尝试挂载mount /dev/md2 /mnt或者挂载时加degraded参数适合只有单盘能挂载的场合mount -o degraded /dev/md2 /mnt如果是ext4用fsck -f /dev/md2。全部正常后回到DSM图形界面刷新存储管理器存储空间应该变成“正常”。这里提醒一句重建完成后别立刻往里面塞大量数据先让系统跑一两天观察有没有新的IO错误冒出来。4. 重建期间的监控与系统保护4.1 看进度与判断重建速度重建监控的核心就一个文件/proc/mdstat。它会实时显示resync的百分比和剩余量也会显示是哪个md设备在同步。想知道更详细的信息用mdadm --detail /dev/md2里面会列出rebuild/resync状态、每个成员盘的健康状态。同步速度不是一个固定值取决于总线带宽、硬盘持续读写速度和CPU占用。常见的SATA机械盘重建大概在80-150MB/s之间SSD阵列会快很多200MB/s以上。比如一个2TB数据分区实际有效数据可能只有几百GB但因为RAID1是全盘镜像同步重建时间通常按整盘容量估算。你可以用剩余MB数除以当前速度大致算出还要多久。内核也提供了速度限制参数在/proc/sys/dev/raid/speed_limit_min和speed_limit_max。默认min是1000KB/smax很多系统设成200000KB/s。如果你发现重建被限速了可以临时拉高echo 100000 /proc/sys/dev/raid/speed_limit_min echo 400000 /proc/sys/dev/raid/speed_limit_max注意这只是临时调整重启恢复默认。正常情况下不建议动除非你确认当前速度低是因为限速而不是硬盘自身太慢。4.2 重建期间千万不要做的事不要重启NAS。重建没完成就重启新盘可能已经从阵列里摘出去或者resync从头再来一次极端情况下阵列变成inactive。不要往阵列里疯狂写数据。虽然RAID1重建时系统还可以读写但高负载会拖慢同步也会放大IO错误概率。最好暂停下载任务、视频转码等重负载服务。不要去动另一块健康盘。有的人嫌健康盘响应慢想去摸摸它是不是坏了结果一不小心把盘从阵列里手动fail了那就真变成裸奔了。注意散热。机械盘持续读写一两个小时机箱风扇不够的话温度能飙到50度以上高温环境下重建容易诱发新坏道。机箱如果小把盖板打开用个风扇直吹都是有效的土办法。别在重建期间改阵列结构比如加盘、换RAID级别、扩容。这些操作要等同步完成、存储管理器确认正常之后再说。4.3 理解超级块为什么新盘要清掉旧数据mdadm会在每一块成员盘上写超级块记录阵列的UUID、RAID级别、成员顺序等元数据。当你往阵列里加一块之前用过的盘如果不把这块盘上的旧超级块清掉内核可能误以为它是另一个阵列的成员拒绝添加。mdadm --zero-superblock /dev/sata2p3就是把这个位置的元数据擦掉让它变成一张“白盘”。另外群晖的RAID元数据布局和标准Linux略有差别但底层还是在/dev/sataXpY上写超级块。这就是为什么你手动add之前必须先确认分区编号是否和健康盘一致。分错区、用错盘符轻则重建失败重则把另一块正常盘的数据卷进新的resync里数据就真没了。5. 典型故障与排查经验5.1 问题一阵列变成inactive怎么办阵列inactive是最让人紧张的状态因为它意味着系统根本不把md设备当可用设备挂载。现象通常是/proc/mdstat里显示md2 : inactive sata1p3[1]或者干脆没有md2条目。处理思路是先把阵列手动组装起来mdadm --stop /dev/md2 mdadm --assemble /dev/md2 /dev/sata1p3 /dev/sata2p3如果只有一块盘健康可以只写健康盘的成员mdadm --assemble --force /dev/md2 /dev/sata1p3--force会强制使用剩余成员启动阵列在确认这块盘数据基本正常的情况下可以试。启动后立刻把重要数据拷贝出来。这种能救但救完别指望阵列还能继续正常服役该换盘换盘该备份备份。5.2 问题二add新盘时报capacity too small如果新盘容量比阵列记录的最小成员容量还小mdadm会直接拒绝提示capacity too small。比如原来的故障盘是一块1TB盘你换了一块800GB的盘分区表复制的起点和终点不一样阵列认为是有效容量不足。要么换回规格相同的盘要么把分区规划成不超过阵列认可边界。这种提示不是数据损坏只是容量校验没过别慌。还有一种add失败的常见原因是device or resource busy说明分区正被别的设备占用。这种情况先看cat /proc/mdstat确认它没被别的md设备占用再用lsblk确认没有挂载点必要时直接重启再执行add。5.3 问题三重建完成后存储空间仍然显示损毁阵列resync到100%不代表DSM界面就一定恢复“正常”。因为群晖的存储空间还依赖文件系统层尤其是btrfs如果不一致DSM依然会报警。我的排查顺序是先确认底层阵列健康mdadm --detail /dev/md2两个成员都应该是active sync。再看文件系统能不能挂载mount /dev/md2 /mnt失败就btrfs device scan后再试。如果btrfs报错先btrfs filesystem check /dev/md2按提示修复。群晖里运行这些命令要小心最好先备份btrfs元数据。最后重启NAS让DSM重新扫描一遍通常到这一步存储管理器就恢复“正常”了。还有一种是系统分区md1重建不完整导致DSM对存储管理器报出错误的不可用判断这种需要把md1也加到阵列里补同步。5.4 问题四盘符漂移换盘之后BIOS、主板端口的枚举顺序变化/dev/sata1和/dev/sata2的对应关系可能对调。严格来说Linux在枚举时按端口命名不同引导版本表现不一样但只要你换了盘就一定要用分区UUID确认身份不要只看盘符顺序。用lsblk -f /dev/sata1或者blkid /dev/sata1p3拿到每个分区真实UUID。健康盘复制过来的分区表和原盘一致UUID也会被复制但md超级块里的UUID是阵列自己的指向md2。物理盘的身份可以结合smartctl -i /dev/sata1查看序列号来确认。一句话以序列号和UUID为准别信盘符。5.5 常见问题速查表现象可能原因排查命令处理建议存储空间损毁提示阵列降级或inactivecat /proc/mdstatmdadm --detail /dev/md2先组装/启动阵列再换盘重建add报resource busy分区被占用或残留superblocklsblkcat /proc/mdstat清空超级块后重新addadd报capacity too small新盘容量不足lsblk查看容量换同规格盘或调整分区边界重建很慢或卡住硬盘坏道、限速、高负载smartctl -a /dev/sataXiostat -x 1检测健康盘暂停负载临时调高限速重建完仍报警文件系统btrfs错误btrfs filesystem check /dev/md2备份元数据后修复必要时degraded挂载导出数据掉盘后开机卡引导系统分区md0/md1损坏cat /proc/mdstat单盘启动后拷贝数据重建系统分区修完这一次我对RAID1的心态反而更敬畏了。它防的是单块盘故障不是备份它能扛住一次坏道扩散但扛不住你两年不备份加上机箱里还有一根劣质SATA线。手动重建阵列这套流程说白了就五步确认掉盘、fail掉、remove掉、换完盘add回来、等resync。真正难的不是命令而是遇到问题时能不能保持冷静不把好盘拿去陪葬。最后再分享一个我自己的习惯阵列恢复正常之后顺手把mdadm --detail --scan的输出备份一份。下次再碰到类似问题直接照着重建能省不少时间。希望这篇东西能让你在SSH窗口前少慌几分钟多保住几TB数据。