1. 先判风险再动手RAID10单盘失效的故障边界与决策框架凌晨两点值班手机弹出“RAID10阵列降级”的告警我第一反应不是抓起螺丝刀去机房而是先确认三件事哪块盘失效、业务还在不在、备份是否可用。RAID10单盘失效并不等于灾难它通常还能继续读写但冗余已经从“双副本”掉到“单副本”此时任何一次误操作、一次同组盘报错甚至一次全速重建都可能把可控故障拖成数据事故。这篇内容围绕RAID10单盘失效后的降级处理全流程展开从故障确认、物理盘定位、安全换盘到重建限速、进度监控、重建后校验与长期告警。它适合一线运维、SRE、自建NAS玩家和刚接触软RAID的读者命令以Linux mdadm为主线硬件阵列卡场景会给出对应思路。下面按我实际处置时的顺序讲尽量把“为什么这么做”和“踩过的坑”一起说清楚。1.1 RAID10降级后到底还剩多少安全垫RAID10的本质是“先镜像、再条带”。以常见的near2布局为例每一份数据都有两个副本分别落在不同的物理盘上条带再把多组镜像拼成一个大设备。单盘失效时坏盘所在镜像组的另一块盘仍然能提供完整数据所以业务通常不会立刻中断文件系统也还能正常读写。真正的变化在于这个镜像组从“两份副本”变成了“一份副本”安全垫从“还能承受一次意外”变成“再坏一块就可能直接失去数据”。很多人看到阵列还是active就放松警惕这是RAID10单盘失效处置里最容易踩的坑。还要区分“同组再坏”和“不同组再坏”。RAID10并不是随便再坏一块就必然全盘不可用具体后果取决于坏盘是否落在同一个镜像组以及阵列布局和控制器实现。生产环境里不要做这种赌博只要阵列处于degraded就按“冗余已经耗尽”来对待。尤其要注意热备盘是否已经自动顶上如果热备盘正在重建阵列实际上又进入了一个新的高风险窗口。此时最该做的是确认备份、限制重建速度、盯住另一块镜像盘的健康状态而不是继续压测或跑大批量任务。1.2 先保业务还是先换盘处置窗口怎么定处置窗口没有统一答案核心是平衡“降级期间的风险”和“重建期间对业务的冲击”。如果这台机器跑的是核心交易库白天直接全速重建很可能把IO延迟打上去业务侧先出问题如果盘已经彻底离线、SMART指标明显异常继续拖到夜间又可能让同组另一块盘在高温高负载下跟着出问题。我的习惯是先做关键数据备份或快照再在业务低峰执行换盘如果盘已经出现大量重映射、待定扇区或内核持续报I/O错误就不再等低峰而是尽快安排维护窗口。下面这张表是我实际判断时常用的决策框架具体阈值要结合业务SLA和硬件支持能力调整场景建议动作理由单盘失效业务正常SMART仅少量CRC错误先检查线缆和背板较低峰换盘可能是链路问题不一定是盘体损坏单盘失效SMART重映射/待定扇区明显增长尽快备份安排最近窗口换盘盘体劣化通常不可逆继续拖风险高阵列有热备盘且已自动重建立即限速并监控不要重复加盘重建窗口本身就是高风险期业务对延迟极敏感无维护窗口先备份限速重建分批降载全速重建可能拖垮业务盘位不支持热插拔停机维护按停机流程操作带电拔盘可能损坏背板或控制器1.3 处置路线图五步闭环我把RAID10单盘失效处理拆成五步确认故障、隔离坏盘、准备新盘、加入阵列并限速重建、重建后校验与监控。顺序不能乱尤其是“确认故障”和“隔离坏盘”之间必须把阵列层、系统日志、SMART和物理槽位都对上。很多误操作来自“看到sdX掉了就直接拔”结果拔错盘或者拔掉的是同组另一块健康盘。换盘前记录序列号、槽位、阵列成员关系是最便宜也最有效的保险。准备新盘时不要只盯容量。新盘容量不能小于原盘接口速率、扇区格式、是否CMR、固件兼容性都要看。软RAID对型号一致性的要求没有硬件卡那么严但混用不同容量和不同扇区格式容易带来性能不一致或加入失败。加入阵列前先清掉旧分区表和旧RAID超级块否则mdadm可能把新盘识别成某个旧阵列成员出现“加不进去”或者“加进去又掉”的怪问题。重建阶段的核心是控制速度。RAID10重建不需要像RAID5那样读所有盘做校验计算它主要是从同镜像组的另一块盘读数据、写到新盘所以速度通常更快但仍然是整盘级别的写入。业务IO和重建IO会抢磁盘队列限速不是可选项而是生产环境的默认动作。重建完成后也别急着收工跑一次一致性检查、确认degraded归零、把监控告警补齐才算闭环。下面按这个路线图逐段展开。2. 故障确认实操从告警到定位物理盘2.1 阵列层/proc/mdstat和mdadm --detail先看什么登录系统后先看/proc/mdstat它是最快判断阵列状态的地方。典型降级输出里会出现[3/4] [UU_U]这样的标记3/4表示四个成员里三个正常UU_U表示成员状态序列_或F代表缺失或故障。此时不要只看“active”就放心重点看degraded、failed、recovery这些关键字。如果正在重建会看到[....................] recovery 12.3%之类的进度条如果已经卡住进度可能长时间不动。接着用mdadm --detail /dev/md0看成员明细。重点字段包括State、Active Devices、Working Devices、Failed Devices、Spare Devices、Layout、Chunk Size和Consistency Policy。State : clean, degraded说明阵列还在工作但冗余不完整Failed Devices : 1说明有一块被标记故障成员列表里带faulty或removed的那一行就是问题盘。把设备名、主次设备号、槽位和序列号记下来后面物理定位全靠这些信息对齐。cat /proc/mdstat mdadm --detail /dev/md0 cat /sys/block/md0/md/degraded cat /sys/block/md0/md/sync_action cat /sys/block/md0/md/sync_completed/sys/block/md0/md/degraded为1时表示阵列处于降级状态sync_action可能是idle、recover、resync、check、repairRAID10换盘后常见的是recover。如果sync_action是idle但degraded还是1说明当前没有重建在跑要么热备没顶上要么坏盘还没被移除。此时不要急着重启先把日志和SMART看完确认是盘坏、线缆问题还是控制器偶发超时。2.2 系统与SMART区分真坏盘、假死和链路问题阵列层只能告诉你“哪块盘被踢了”不能直接证明盘体一定坏了。接着看内核日志dmesg -T | grep -Ei ata|scsi|sd|error|fail|timeout|medium error重点找I/O error、medium error、timeout、reset、link down这类记录。如果错误集中在某一块盘而且伴随大量重试盘体或链路的嫌疑就很大如果多块盘同时报错反而要怀疑背板、电源、HBA卡或机箱散热。RAID10单盘失效的现场最怕把背板接触不良误判成盘坏换上新盘后问题复发。SMART是第二道证据。用smartctl -a /dev/sdX看关键属性Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、UDMA_CRC_Error_Count。重映射扇区持续增长、待定扇区不为零、离线不可纠正错误增加通常说明盘体正在劣化CRC错误快速增长则更像线缆、背板或接触问题。SAS盘可以用smartctl -x看更多日志但不要对已经明显故障的盘做长时间自检那会拖延处置窗口。dmesg -T | grep -Ei ata|scsi|sd|error|fail|timeout|medium error smartctl -a /dev/sde smartctl -l selftest /dev/sde这里有个经验如果盘已经被阵列标记faulty但SMART看起来还算健康先别急着下“误报”的结论。看dmesg里有没有链路复位、CRC错误、命令超时看背板槽位是否松动看同一背板上的其他盘是否也有异常。生产环境里我见过好几次是线缆或背板接触问题导致盘被踢换盘反而把问题掩盖了。反过来如果SMART已经出现大量待定扇区就不要再用“重新加回去试试”拖延直接走换盘流程。2.3 物理定位序列号、槽位和LED怎么对齐定位物理盘是换盘前最关键的一步。先用lsblk -o NAME,SERIAL,MODEL,SIZE,TYPE,TRAN拿到设备名、序列号、型号和传输类型再用ls -l /dev/disk/by-id/和ls -l /dev/disk/by-path/看稳定标识。by-id里通常包含序列号by-path里包含PCIe链路和端口信息这两个信息结合机箱槽位图基本能锁定是哪一块盘。不要把/dev/sdX当成永久标识重启或插拔后设备名会变序列号才可靠。lsblk -o NAME,SERIAL,MODEL,SIZE,TYPE,TRAN ls -l /dev/disk/by-id/ ls -l /dev/disk/by-path/ mdadm --detail /dev/md0如果机箱支持LED定位可以用ledctl locate/dev/sde之类的工具点亮槽位灯或者用阵列卡管理工具让对应物理盘闪烁。没有LED就用槽位图和序列号双重确认并在换盘前拍照记录。热插拔操作时先确认背板支持热插拔、电源和风扇正常再动手。拔盘前把坏盘再执行一次--fail和--remove确认阵列成员列表里已经变成removed不要直接拔一块还在阵列里的盘。2.4 故障判定表把“看起来坏了”变成可执行结论现象更可能的原因处理建议阵列标记faultySMART重映射/待定扇区明显增长盘体劣化备份后尽快换盘阵列标记faultySMART健康dmesg有链路复位/CRC错误线缆、背板或接触问题先检查链路必要时换槽位验证多块盘同时faultydmesg大量超时背板、电源、HBA或固件问题先降载备份检查公共硬件重建中另一块盘报I/O error同镜像组风险升高立即备份暂停非关键业务盘在系统中消失lsscsi看不到盘体、背板或供电故障按硬件维护流程处理这张表不是让你机械套用而是强迫自己把“现象”落到“原因”和“动作”上。RAID10单盘失效最怕两种情况一是把链路问题当盘坏换盘后问题复发二是把盘坏当偶发反复--re-add把劣化盘加回去结果重建到一半又掉。确认阶段多花十分钟后面能省几个小时。3. 替换盘准备与安全换盘分区、标识、热备3.1 新盘选型容量、扇区、接口和介质类型新盘第一原则是容量不小于原盘。RAID10成员盘容量不一致时阵列通常按最小盘容量使用混用大容量盘会浪费空间也可能让替换盘无法加入。第二原则是扇区格式尽量一致512e和4Kn混用在某些控制器上会出问题软RAID虽然兼容性更好但也不建议在生产环境冒险。第三原则是介质类型要匹配别用SMR盘去顶替CMR企业盘RAID重建是持续写入场景SMR盘的写入放大和垃圾回收会让重建速度变得很难看。接口速率和固件也要看一眼。新盘接在SATA口上却跑在低速链路重建时间会被拉长固件有已知掉盘问题的批次最好提前查兼容性列表或小批量验证。自建NAS玩家常忽略电源和散热四块盘同时重建时功耗和温度都会上升旧电源余量不足可能导致更诡异的故障。新盘上机前做一次短自检和坏道扫描是加分项但不要用全盘长时间写测试去“烤盘”那会增加不必要的磨损。3.2 安全移除坏盘先fail再remove不要直接拔软RAID环境下坏盘还响应时先执行mdadm --manage /dev/md0 --fail /dev/sde1把它标记为故障阻止阵列继续往这块盘写数据再执行mdadm --manage /dev/md0 --remove /dev/sde1把它从阵列成员里移除。如果盘已经彻底离线--fail可能报错这时直接--remove也可以。移除后确认/proc/mdstat里成员数减少、mdadm --detail里对应行变成removed再动物理盘。mdadm --manage /dev/md0 --fail /dev/sde1 mdadm --manage /dev/md0 --remove /dev/sde1 cat /proc/mdstat mdadm --detail /dev/md0这一步的禁忌是“直接拔”。不支持热插拔的背板带电拔盘可能打火花、损伤接口支持热插拔但阵列没做fail/remove拔盘后内核可能反复重试业务IO被拖慢严重时还会触发控制器复位。硬件RAID卡场景不要用mdadm命令应该在阵列卡管理工具里把物理盘置为Offline/Ready再按厂商流程拔盘。不同卡叫法不一样但顺序都是先让控制器停止使用这块盘再动硬件。3.3 新盘清签名、分区、加入阵列新盘上机后先确认系统识别到它再用wipefs -a清掉旧文件系统签名和旧RAID超级块。如果旧盘来自其他阵列wipefs可能清不干净可以配合sgdisk --zap-all清分区表。接着按原阵列的成员方式处理原来用分区就用分区原来用整盘就用整盘。下面示例按“每块盘一个分区、分区类型设为Linux RAID”的方式写分区起始位置留1MiB对齐避免性能损失。wipefs -a /dev/sdf sgdisk --zap-all /dev/sdf parted -s /dev/sdf mklabel gpt parted -s /dev/sdf mkpart primary 1MiB 100% parted -s /dev/sdf set 1 raid on mdadm --manage /dev/md0 --add /dev/sdf1加入后立刻看/proc/mdstat正常情况下会出现recovery进度。如果新盘之前属于别的阵列--add可能被拒绝先确认wipefs -a已经清掉linux_raid_member签名如果容量比原成员小mdadm会拒绝加入如果分区大小和原成员不一致也可能出现警告。新盘加入后不要马上跑全速重建先按下一节设置限速再让重建继续。3.4 热备盘与自动重建的边界热备盘的价值在于缩短降级窗口。配置了热备的阵列在成员盘被fail/remove后mdadm会自动把热备盘加入并开始重建。但热备盘不是万能的全局热备可能被其他阵列先占用热备盘容量必须足够热备盘本身也要健康。生产环境里我建议给热备盘留独立监控别等主盘坏了才发现热备盘也有重映射。自动重建一旦启动会立刻开始抢IO如果业务正处在高峰最好在热备加入前先设置好speed_limit_max否则重建速度可能把业务延迟打穿。cat /proc/mdstat mdadm --detail /dev/md0 | grep -A8 Number mdadm --manage /dev/md0 --add /dev/sdf1 mdadm --detail /dev/md0 | grep -i spare还要注意--re-add和--add的区别。--re-add用于原来属于这个阵列、只是临时掉线的盘它可能只同步增量部分--add用于全新盘或已经清空签名的盘会触发完整重建。坏盘如果有SMART异常不要用--re-add把它加回去赌运气重建到一半再掉会把风险放大。新盘也不要用--re-add否则可能因为事件计数不匹配而失败。4. 重建过程控制速度、优先级、业务影响4.1 重建原理RAID10到底在重建什么RAID10换盘后的重建本质上是把新盘补进它所属的镜像组然后从同组的另一块健康盘读取数据写到新盘上。它不需要像RAID5那样读所有成员盘做异或校验所以CPU开销小、顺序读写为主速度通常更快。但“更快”不等于“没有影响”重建是整盘级别的持续写入会占用磁盘队列、控制器带宽和背板通道业务IO的延迟和IOPS都会受到影响。阵列在重建期间仍然处于degraded状态直到进度到100%且成员状态变成active。cat /sys/block/md0/md/sync_action cat /sys/block/md0/md/sync_completed cat /sys/block/md0/md/sync_speedsync_action显示recover时表示正在重建sync_completed通常以扇区为单位显示已完成量sync_speed显示当前同步速率单位一般是KB/s。不要只看/proc/mdstat的百分比百分比是估算值真正可靠的是sync_completed是否持续增长。如果它长时间不动而sync_action还是recover就要怀疑卡住、坏道或另一块盘出问题。4.2 限速参数sync_speed_min/max怎么算Linux软RAID的同步速度由/proc/sys/dev/raid/speed_limit_min和speed_limit_max控制单位是KB/s。speed_limit_max是重建速率的峰值上限speed_limit_min是最低推进速度。业务敏感环境里我通常先把max压到60MB/s到80MB/s观察业务延迟后再决定是否上调低峰窗口可以放到150MB/s到200MB/s。设置前先把原值记下来重建完成后恢复避免影响后续一致性检查。cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max echo 50000 /proc/sys/dev/raid/speed_limit_min echo 80000 /proc/sys/dev/raid/speed_limit_max算一下时间一块4TB盘按4,194,304MB估算限速80MB/s时理论时间约4,194,304÷80÷3600≈14.6小时限速120MB/s约9.7小时限速200MB/s约5.8小时。实际时间会更长因为业务IO会插队、磁盘寻道有开销、重建过程中还可能遇到慢扇区。限速太低会让降级窗口拉长风险反而增加限速太高会影响业务。我的经验是先用业务低峰的可接受延迟反推max再留20%余量。stripe_cache_size主要影响RAID5/6的校验写性能对RAID10重建意义有限不建议在RAID10重建时盲目调大。读预取、调度器、队列深度这些参数也有影响但生产环境里不要一次改太多否则出了问题很难回滚。重建期间最值得盯的是iostat -x 5里的await、%util和业务侧的P99延迟而不是追求一个漂亮的同步速率数字。4.3 监控脚本进度、速率、错误一起看重建期间我会开一个循环监控把阵列状态、完成量、速率和内核错误放在一起看。下面这个脚本足够粗糙但实用每分钟打印一次直到sync_action变成idle。如果业务机不能长期开终端可以把输出重定向到日志或者接入现有监控系统。while [ $(cat /sys/block/md0/md/sync_action) ! idle ]; do date cat /proc/mdstat printf completed: %s\n $(cat /sys/block/md0/md/sync_completed) printf speed: %s KB/s\n $(cat /sys/block/md0/md/sync_speed) echo --- sleep 60 done同时另开一个窗口看dmesg -w重点盯I/O error、medium error、timeout、reset。如果重建过程中另一块镜像盘开始报错说明同组风险已经升高这时不要再跑备份以外的大任务优先把关键数据复制到其他存储。mdadm --monitor也可以用来发告警常见做法是配一个本地邮件或告警网关但不要把告警只发到阵列所在机器的本地邮箱机器真挂了没人看得到。4.4 重建异常速度过慢、卡住、另一盘报错重建速度过慢先看三件事限速是不是设得太低、业务IO是不是把磁盘打满、iostat里有没有单盘await异常高。如果%util长期接近100%但进度很慢可能是新盘或同组盘有慢扇区如果dmesg出现重试优先怀疑盘体。不要一看到慢就重启重启可能让重建从头开始也可能让阵列进入更差的状态。先备份再判断。重建卡住的典型表现是sync_completed长时间不变、sync_action还是recover。这时看dmesg有没有SCSI超时看smartctl新盘和同组盘的健康状态看背板链路有没有复位。如果确认新盘有问题可以--fail和--remove把新盘拿掉换盘重来如果同组另一块盘报错优先保护数据不要再做写压力测试。重建失败后阵列可能还是degraded甚至成员状态更乱动手前先把mdadm --detail和/proc/mdstat完整保存下来。5. 重建后校验与长期监控别等下次掉盘才发现5.1 一致性检查check和repair怎么选重建完成不等于数据完全可信。重建过程中如果遇到坏道或者同组盘本身有隐患可能出现静默不一致。重建完成后先确认mdadm --detail里State回到clean、Failed Devices归零、sync_action为idle再安排一次一致性检查。check只读检查并统计不一致块repair会尝试修复。生产环境建议先跑check看mismatch_cnt是否为零再决定要不要repair。echo check /sys/block/md0/md/sync_action cat /sys/block/md0/md/mismatch_cnt cat /sys/block/md0/md/sync_action一致性检查会扫全盘对业务IO有影响放在低峰跑。RAID10的检查会读镜像副本并比较耗时和盘容量、速度有关。mismatch_cnt非零不一定代表数据一定坏了可能是重建期间有写入、也可能是坏道导致但如果持续非零就要结合文件系统检查和应用校验判断。不要频繁全盘repair修复动作本身也有风险先备份再动手。5.2 监控指标与告警配置长期监控要覆盖四个层面阵列状态、成员盘健康、重建/检查进度、内核错误。阵列层监控/proc/mdstat里的degraded、failed、recovery以及mdadm --detail的Failed Devices盘体层监控SMART的重映射、待定扇区、CRC错误和温度系统层监控dmesg里的I/O错误和链路复位业务层监控延迟和错误率。告警规则不要只配“阵列掉了”还要配“降级后30分钟没有开始重建”“重建速率长时间为零”“同组盘SMART恶化”。mdadm --monitor --scan --mailmonitorexample.com --delay300 --daemonise smartctl -a /dev/sdb | grep -Ei Reallocated|Pending|Offline|CRC|Temperaturemdadm --monitor适合做基础告警但它依赖本机邮件配置生产环境最好接入统一告警平台。常见监控代理有mdadm采集插件没有插件就写个定时脚本解析/proc/mdstat和/sys/block/md0/md/。热备盘也要单独监控别让它变成“看起来有、实际不可用”的摆设。备件库里的同容量盘定期上机自检避免真出事时发现备件也是坏的。5.3 常见问题速查表问题现象排查与处理RAID10坏一块还能再坏吗阵列degraded但业务正常不能把单盘失效当“还能再坏一块”的许可同镜像组再坏一块可能直接丢数据能不能直接拔坏盘盘还在阵列成员里先--fail再--remove确认成员移除后再动硬件新盘加不进去--add报错或没反应检查容量、分区大小、旧RAID签名、是否被其他阵列占用重建速度只有几MB/s进度很慢看限速、业务IO、iostatawait、dmesg坏道和链路错误重建完还是degradedsync_action为idle但degraded1看成员状态、新盘是否被踢、dmesg和SMART热备盘不自动顶坏盘移除后没有recovery检查spare是否被占用、阵列是否配置热备、容量是否足够硬件RAID卡怎么判断OS层看不到单盘用阵列卡管理工具看物理盘状态、虚拟盘降级和重建进度5.4 实操心得几条反直觉的经验第一条重建不是越快越好。全速重建能把降级窗口压到最短但也可能把业务延迟打爆甚至让同组另一块盘在高温高负载下提前出问题。生产环境里限速是默认动作低峰再放开。第二条换盘前先备份。RAID10单盘失效时数据通常还在但重建过程中任何意外都可能让“还能读”变成“读不出来”备份是唯一兜底。第三条记录序列号和槽位。设备名会变序列号不会换盘前拍照、记录、双人确认比事后争论“拔的是哪块”有用得多。第四条别在同一时间做多件事。重建期间不要跑全盘备份、不要做一致性检查、不要压测新盘这些都会抢IO。第五条热备盘要定期演练。很多环境配了热备但从没验证过自动顶上真出事时才发现热备盘容量不对或者被其他阵列占用。最后再分享一个小技巧把“先fail再remove、先清签名再加盘、重建前先限速”这三句话贴在机柜门内侧比出事时翻文档管用换盘流程写成一张A4纸包含命令、序列号记录栏和回滚步骤值班的人照着做误操作会少很多。