1. 故障场景还原最先收到的是那封监控报警邮件先说一个我自己的真事儿。某天凌晨两点半手机连续震了三条都是某台业务服务器的监控报警内容很统一RAID 阵列降级请立即检查。说实话凌晨被吵醒的那一刻心情是崩的但因为之前处理过几次类似情况心里大概有数。登录服务器控制台扫了一眼mdadm 状态里清清楚楚写着[UU_U]RAID10 四块盘里有一块掉了。系统还在正常跑业务没中断但整个阵列已经进入降级状态所有数据只靠剩下的三块盘硬撑。这个场景如果你也管着几台自建服务器或大容量 NAS大概率早晚会遇到。标题里那句单盘失效降级处理本质上就是一次关于冗余设计、故障判断和替换操作的完整闭环。RAID10 这个组合在性能和安全性之间找到了一个非常实用的平衡点但前提是你必须在它真正失效的时候知道自己在干什么。这篇文章就把整套流程从头到尾拆开讲清楚包括故障识别、降级状态判定、换盘流程、重建监控以及那些文档里不会告诉你的坑。介于接下来要涉及的指令基本都是 Linux 下的 mdadm 工具如果你的阵列是硬件 RAID比如常见的企业级服务器阵列卡我会单独说明对应的处理路径。软 RAID 和硬 RAID 在原理上是一致的但操作界面和工具差异很大我会在第三节里分别展开。2. 先说清楚 RAID10 为什么不怕单盘失效很多人听到 RAID10 第一反应是两两镜像再条带这个说法对但不完全。RAID10 的本质是先做 RAID1镜像再做 RAID0条带所以它能把 RAID1 的容错能力和 RAID0 的读写性能同时拿到手。具体到四盘 RAID10 的结构是盘 A 和盘 B 组成第一个镜像对盘 C 和盘 D 组成第二个镜像对两个镜像对之间做条带。写入数据时数据被切成两块同时写入两个镜像对每个镜像对内部再各写一份完整拷贝。所以单盘失效时只要失效的盘不是同一个镜像对里的两块系统就能继续正常读写。比如盘 A 挂了盘 B 手里还握着同一份完整数据阵列不会中断。这就是降级状态的意义数据还在但冗余已经减半。关键时刻如果盘 E另一个镜像对里的一块也挂了整阵列就彻底瘫痪。这也是为什么 RAID10 阵列会在任何一块盘失效后立刻发出报警——不要等两块盘出问题才知道事情严重了。2.1 只坏一块盘时数据真的毫发无损吗从数据完整性角度来说是的。因为每个数据块都有两份拷贝你读到的内容是完全一致的。但这里有个隐性风险降级状态下系统要继续承担所有读写压力剩下的盘会因为阵列控制器不断尝试重建数据而承受额外负荷。去年我处理过一台老服务器坏了一块盘之后没有及时处理又跑了两个多月第二块盘在重建过程中当场阵亡数据最终是靠冷备恢复的。那种滋味不想尝第二次。所以接到降级报警之后的第一件事不是马上换盘而是先冷静评估现状然后按顺序操作。贸然拔盘、热插拔顺序搞错、新盘容量不匹配、重建过程中断电这些在降级状态下都是能直接导致数据丢失的动作。后面几节我会按实际处理顺序一条一条说。3. 从报警信息开始定位故障盘识别与影响评估3.1 识别故障盘别凭手气盲猜无论是软 RAID 还是硬 RAID系统都会告诉你到底是哪块盘出了问题。软 RAID 直接用命令cat /proc/mdstat比如输出Personalities : [raid1] [raid10] md0 : active raid10 sdc[2] sdb[1] sdd[3] sda[0] 1465139200 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]注意最后那个[UU_U]U 代表正常下划线代表失效。也就是说编号为 2 的 sdc 掉了。如果你装了 mdadm 的邮件通知失效的那一瞬间你已经收到过一封标题类似DegradedArray event on /dev/md0的报警邮件里面会直接告诉你故障设备名。硬 RAID 的操作界面也能看到类似信息控制器管理界面里通常会列出每个物理槽位的状态失效盘会显示成 Failed 或者类似表述一眼就能定位。有个容易忽略的操作如果你不确定物理盘槽位和系统设备名之间的对应关系最好在服务器关机状态下做个标记。夜里戴着头灯判断哪块灯不亮确实不难但光线差的时候真的容易看岔眼我有次就因为槽位判断失误拔错了盘好在当时只是演练。3.2 确认降级模式的影响范围还能不能继续跑业务这个问题要分情况。降级状态下RAID10 的业务读性能几乎不受影响但如果写入压力大性能会有所下降因为控制器需要额外的计算来完成重建补偿。关键在于你需要知道自己还能撑多久而这个多久没有标准答案完全取决于剩下盘的健康状态。我的习惯是降级之后立刻对剩下的盘做一次 S.M.A.R.T. 健康检查特别是看Reallocated_Sector_Ct重映射扇区数和Current_Pending_Sector当前待映射扇区这两个指标。如果数据已经出现明显增长说明这块盘也在恶化要加快替换速度而且新盘到位之前建议用另一份备份兜底。如果指标正常你有相对充足的时间来完成采购和替换。实操命令注意盘符要改成你自己的smartctl -a /dev/sdb重点关注上边那两个字段的变化趋势。如果之前数值是 0现在变成了 5 或更高那就不该再等了。4. 数据保护与热备部署换盘之前先问自己三个问题很多新手拿到新盘的第一反应是直接往槽位里一插然后开始等重建。这个做法不能说错但准备工作没做扎实的话很容易出意外。换盘启动之前按顺序确认三件事数据备份是否完整。RAID10 防的是单盘失效但它防不了逻辑误删、软件崩溃、病毒破坏。你降级状态下全速运行的阵列任何一次误操作造成的后果都会被 RAID 的完整性掩盖住——RAID 不提供任何层级的逻辑保护。所以如果这台机器上有不可再生数据先同步一份到外部存储。这是最不性感但最重要的一步。是否有热备盘spare。如果你最初配置 RAID10 的时候就预留了热备盘那接下来要做的反而是什么事都别做。热备盘会自动接管失效盘开始重建你只需要监控进度就行。如果没配热备盘就得手动插盘触发重建这也是大多数人会遇到的情况后面我会专门讲手动流程。新盘的容量是否达标。这一步经常有人漏看。RAID10 阵列中每块盘的角色是成对镜像的如果你插入的新盘容量小于同组镜像对的另一块盘阵列控制器可能会拒绝让它上线或者重建完成后导致整阵列容量缩水。最稳妥的做法是选择与原盘完全相同容量、相同类型的盘。混用新旧盘没问题但容量必须不小于原盘。有一次我贪便宜买了同容量但不同转速的盘结果重建性能被拖到令人发指的程度这件事后面会细说。4.1 有热备盘和没热备盘处理路径完全不同有热备的情况下失效发生后阵列会立即进入重建状态你几乎不用做任何事。唯一要做的是观察重建是否顺利完成。重建期间业务继续读写系统性能会有一定程度下降但这是正常现象。有些控制器支持限制重建速度优先保证业务根据你的实际负载在管理界面里调节即可。没有热备的情况才是真正的实操主场。你先确认一下物理槽位上是否已经插好了一块容量和类型都合适的新盘。确认后接下来的操作就是把新盘加入阵列并触发重建这个过程不复杂但有几个命令细节需要小心。我们留给下一节分软 RAID 和硬 RAID 两条路径讲。5. 核心实操流程软 RAIDmdadm与硬 RAID阵列卡双路径对照5.1 软 RAID 路径从移除到重建的一整套命令软 RAID 的整套流程可以用三条命令概括移除故障盘、添加新盘、检查重建进度。但真正执行时每一步都有需要注意的细节。第一步把新盘的旧分区信息彻底清掉。如果是全新盘可以直接跳过但很多情况下你使用的是二手盘或者之前测试过的盘里面残留着分区表和超级块。不清干净的话mdadm 添加时大概率会报错说设备已经被占用或者文件系统不识别。# 假设新盘是 /dev/sde先清分区表 wipefs -a /dev/sde第二步把故障盘从阵列中移除。注意顺序不要搞反先移除旧盘、再添加新盘否则会出现设备名冲突。这里有个容易翻车的细节如果你在添加新盘之前没有先从旧盘槽位移除设备mdadm 会认为你试图把一块非热备盘强制热加入命令可能会执行失败。# 从阵列中移除故障盘 sdc mdadm /dev/md0 -r /dev/sdc移除完成后用cat /proc/mdstat或mdadm -D /dev/md0看一眼阵列状态这时候应该显示[UU_U]但少了一块成员盘。然后再添加新盘# 把新盘 sde 加入阵列 mdadm /dev/md0 -a /dev/sde添加之后阵列会自动开始重建不需要输入额外参数。马上再看一次状态cat /proc/mdstat你会看到类似这样的输出md0 : active raid10 sde[4] sdb[1] sdd[3] sda[0] 1465139200 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U] [....................] recovery 0.3% (4587520/1465139200) finish196.7min speed124176K/sec这个输出信息量很大。左侧是重建进度百分比右侧的 speed 是当前重建速度。重建过程可能持续数小时具体取决于盘容量和阵列负载所以要学会看进度而不是干等着。第三步等待重建完成。这个过程中阵列仍然以完整状态对外提供读写数据安全没有问题但速度会受影响。用watch -n 30 cat /proc/mdstat或mdadm --detail /dev/md0定期检查进度。只有当状态栏显示[UUUU]、没有 recovery 字样时才算真正完成。最后追加一步确认新盘的 UUID 和阵列元数据是正确的。虽然是软 RAID 替我们做了大部分工作但建议备份一下当前阵列配置mdadm --detail --scan /etc/mdadm/mdadm.conf之后更新 initramfs防止重启后阵列识别异常update-initramfs -u这两步虽然不影响当前运行却决定了重启后阵列能否正常自动组起来。很多人忽略这个结果下次服务器重启后阵列直接变成了 inactive 状态那才是真正的手忙脚乱时刻。5.2 硬 RAID 路径管理界面里的操作逻辑大部分企业级服务器使用的是阵列卡比如常见的企业品牌服务器自带的阵列卡。系统内部看到的是一块虚拟盘物理盘管理通过控制器界面完成。单盘失效时控制器会在这块虚拟盘对应的物理盘位置标记为 Foreign 或 Failed并在开机自检或管理界面中生成报警。硬 RAID 的换盘流程第一步是确认物理槽位。控制器通常会显示每个端口/槽位对应的物理盘状态指示灯同步亮起常见的是琥珀色或红色。拔旧盘、插新盘在关机状态下操作最稳妥虽然很多阵列卡支持热插拔但说实话在非必要的情况下我不推荐带电拔盘每年都有用户因为热插拔时的静电或接口问题把旁边的健康盘一起带走。插入新盘后进入阵列卡的管理界面不同品牌按键不同常见的是开机时按某组合键或者在操作系统里启动管理工具。界面里找到虚拟磁盘或阵列配置相关菜单选中降级中的虚拟盘选择添加热备盘或重建。部分控制器会自动扫描到新盘并提示重建。确认重建进度通常也有专门的状态页能看到百分比和预计剩余时间。需要注意的一点是硬 RAID 换盘的容量匹配要求比软阵列严格。很多控制器要求新盘的裸容量必须大于等于原盘否则重建可能失败。直接买和原盘相同型号、相同固件批次的产品是最省心的选择。5.3 重建过程中的监控指标与速度调整重建过程中只要阵列没有报新的错误你就不需要干预它。但有一件事值得做观察重建速度。如果速度一直徘徊在几十 MB/s 甚至更低的水平说明阵列负荷很重或者新盘性能明显不足。这时候你可以选择接受这个速度找业务低峰期再去关注也可以根据控制器的调节策略手动调整重建优先级。软 RAID 下可以通过写入/proc/sys/dev/raid/speed_limit_min和speed_limit_max来设置最低和最高重建速度默认值一般分别是 1000 和 200000KB/s。如果你希望重建过程尽量不影响业务就把 max 调低如果业务不忙、想要尽快重建完就把 min 调高。实测中我一般会维持在默认值让系统自己调度。硬 RAID 的管理界面里通常也有类似选项比如限制重建占用的 I/O 带宽根据你的业务特性选择即可。原则就一条重建期间业务数据的安全优先于重建速度千万不要为了快速重建而压榨那几块老盘。6. 重建完成不等于万事大吉常见翻车场景实录6.1 重建完成后系统报文件系统异常一种让人非常慌的场景是重建显示完成了但访问挂载目录时发现丢文件或者目录结构异常。这通常不是重建本身出了问题而是重建期间系统发生了意外写入失败或者原盘上的文件系统本身已经有损坏。RAID 重建只是把数据从正常盘重新镜像到新盘它不校验文件系统的一致性。碰到这种情况正确做法是先用文件系统检查工具做只读检查而不是立刻强行挂载。比如 ext 系列文件系统可以使用e2fsck -f /dev/md0如果检查过程中发现大量报错说明文件系统的元数据在降级期间已经出了状况。优先把现有数据完整备份出来然后再去修复文件系统这个顺序不能反过来。在文件系统层面做修复之前请先确保有一份完整的数据副本这也是为什么第一节强调先备份再做任何操作。6.2 重建完成速度慢到怀疑人生换盘时踩过的几个坑一次比较典型的经历故障盘替换后重建速度始终只有 30-50MB/s预期 5 小时的重建过程拖到了 20 多个小时。查下来发现新盘虽然容量相同但属于低功耗型号转速和缓存都比原盘低一个档次。RAID10 的重建涉及到同组镜像对之间的持续同步写性能受限于慢的那块盘所以整个阵列性能都被拉低了。另一个常见问题是新盘接了老旧的接口或者错误的数据线导致协商速率只有 1.5Gbps 甚至更低。这种情况在台式机自组 NAS 上尤为常见SATA 线质量差、接口氧化、供电不足都会让链路速度掉档。检测方法很简单用smartctl -d sata -i /dev/sde查看接口速率和协商模式或者直接对比新旧接口速率。所以换盘的时候最好原型号原批次实在买不到同款就选性能等级不低于原盘的型号别在这件事上省钱。6.3 重建过程中第二块盘挂了这可能是所有 RAID10 使用者最害怕的场景。虽然概率不高但真实发生过。重建过程是对剩下的每一块盘高强度读写的压力测试如果某块盘本身就处于亚健康状态很容易在这个阶段暴露出坏道或者掉线问题。如果真遇到了先深吸一口气。在 RAID10 中如果同一镜像对里的两块盘同时失效数据无法恢复但如果挂掉的是不同镜像对的盘那么另一个镜像对还握着完整的数据你可以继续替换坏盘重建流程照常。如果两块失效盘碰巧在同一镜像对里那就只能从备份或快照恢复了这也是为什么我一直强调 RAID 不等于备份你必须有独立的冷备、异地或云端备份。6.4 无法定位物理盘灯不亮界面也看不到一次实操中我通过系统确认了故障盘是/dev/sdc但服务器面板上的硬盘灯全部正常无从分辨哪块物理盘对应 sdc。这类情况在部分服务器上是因为故障盘已经彻底掉线控制器把 LED 状态复位了。解决方法是利用 Linux 下的locate或 smartctl 的盘位定位功能。比如很多硬盘支持 LED 亮起指令smartctl -d sat -t /dev/sdc或者使用ledctl locate/dev/sdc这类工具让指定盘位的 LED 闪烁。如果工具不起作用还有一个土办法拔掉怀疑的盘观察系统里设备是否消失用排除法确认。拔盘前一定确保所有数据都有备份并且这一步不会影响阵列运行——在 RAID10 中拔掉任何一块盘阵列都会从降级状态继续降级或者直接重建如果你拔错了盘反而失去了正确的故障盘数据风险成倍增加。所以老老实实先确认再动手。7. 长期运维真正防止下次凌晨三点被吵醒的做法7.1 给阵列配上主动通知别让它一声不吭如果你用的是 mdadm确保配置文件里设置了邮件通知。在/etc/mdadm/mdadm.conf中像这样配置MAILADDR youremail.com并且让 mdadm 检测到阵列状态变化时发出邮件。实测下来邮件通知能比监控系统早数分钟告诉你故障发生了。如果你用的是企业级监控软件也建议把阵列状态变化事件纳入告警规则。硬 RAID 同理大多数阵列卡管理软件都支持事件邮件通知把 SMTP 服务器配置好就行。不要嫌邮件通知啰嗦平时它安静得像不存在出事时它是唯一能在第一时间叫醒你的信号。7.2 定期健康巡检用 S.M.A.R.T. 数据提前踩刹车很多人只在阵列报警时才想起来去看盘的健康状态这是本末倒置。真正的运维习惯是定期巡检比如每月做一次 S.M.A.R.T. 自检并记录关键参数的变化趋势。重点关注以下几项Reallocated_Sector_Ct重映射扇区数如果持续增长说明盘在物理磨损Current_Pending_Sector待映射扇区这个值不为 0 通常意味着已经出现坏道UDMA_CRC_Error_Count接口通信错误计数过高往往是数据线或接口问题Power_On_Hours和Start_Stop_Count盘的运行时长与启停次数用于评估盘的剩余寿命如果连续两次巡检发现某个指标上升就该开始规划换盘。与其等它真的失效不如主动替换省去一次半夜惊醒的机会。7.3 换下来的旧盘别急着丢先做数据销毁这个点可能有点偏门但真的有人吃过亏。旧盘如果还留在服务器里虽然不在阵列成员列表里了但上面的数据其实还是完整可读的。如果直接丢弃或者送修数据泄露风险很高。正确做法是先将旧盘安全擦除比如用dd写零或者使用专门的擦除工具。如果盘还能通电先擦除再报废如果已经彻底无法通电那就物理销毁盘片别心疼那几十块钱数据安全比什么都重要。8. 实操总结我的个人体会和两条补充建议写到这里整个 RAID10 单盘失效降级处理的流程已经完整走完了。这套流程我前前后后处理过不下十次从最开始的心惊胆战到现在从容应对最大的体会是RAID10 的设计本身足够优雅单盘失效时系统几乎不受影响真正考验人的是人在降级状态下的操作是否冷静、是否按顺序来。备份先行、故障定位、换盘、重建监控、后续巡检五个环节挨个来就能把风险控制在最小。最后再分享两个小技巧。第一如果你的服务支持在线扩容或者阵列迁移可以考虑在换盘之后顺手把阵列做成带热备的配置成本只多一块盘但下次换盘时你连这些步骤都不用做了。第二我用软 RAID 多年除了 mdadm还习惯定期看一眼/proc/mdstat这个文件——它就像阵列的心电图能随时告诉你系统状态是好是坏。下次你听到手机报警震动先照着这篇流程走一遍大概率能稳稳收尾不用经历凌晨三点的兵荒马乱。