1. 先判风险再动手：RAID10单盘失效的故障边界与决策框架

凌晨两点，值班手机弹出“RAID10阵列降级”的告警，我第一反应不是抓起螺丝刀去机房，而是先确认三件事：哪块盘失效、业务还在不在、备份是否可用。RAID10单盘失效并不等于灾难，它通常还能继续读写，但冗余已经从“双副本”掉到“单副本”，此时任何一次误操作、一次同组盘报错，甚至一次全速重建，都可能把可控故障拖成数据事故。这篇内容围绕RAID10单盘失效后的降级处理全流程展开：从故障确认、物理盘定位、安全换盘，到重建限速、进度监控、重建后校验与长期告警。它适合一线运维、SRE、自建NAS玩家和刚接触软RAID的读者，命令以Linux mdadm为主线，硬件阵列卡场景会给出对应思路。下面按我实际处置时的顺序讲，尽量把“为什么这么做”和“踩过的坑”一起说清楚。

1.1 RAID10降级后到底还剩多少安全垫

RAID10的本质是“先镜像、再条带”。以常见的near=2布局为例，每一份数据都有两个副本，分别落在不同的物理盘上，条带再把多组镜像拼成一个大设备。单盘失效时，坏盘所在镜像组的另一块盘仍然能提供完整数据，所以业务通常不会立刻中断，文件系统也还能正常读写。真正的变化在于：这个镜像组从“两份副本”变成了“一份副本”，安全垫从“还能承受一次意外”变成“再坏一块就可能直接失去数据”。很多人看到阵列还是active就放松警惕，这是RAID10单盘失效处置里最容易踩的坑。

还要区分“同组再坏”和“不同组再坏”。RAID10并不是随便再坏一块就必然全盘不可用，具体后果取决于坏盘是否落在同一个镜像组，以及阵列布局和控制器实现。生产环境里不要做这种赌博：只要阵列处于degraded，就按“冗余已经耗尽”来对待。尤其要注意热备盘是否已经自动顶上，如果热备盘正在重建，阵列实际上又进入了一个新的高风险窗口。此时最该做的是确认备份、限制重建速度、盯住另一块镜像盘的健康状态，而不是继续压测或跑大批量任务。

1.2 先保业务还是先换盘：处置窗口怎么定

处置窗口没有统一答案，核心是平衡“降级期间的风险”和“重建期间对业务的冲击”。如果这台机器跑的是核心交易库，白天直接全速重建很可能把IO延迟打上去，业务侧先出问题；如果盘已经彻底离线、SMART指标明显异常，继续拖到夜间又可能让同组另一块盘在高温高负载下跟着出问题。我的习惯是：先做关键数据备份或快照，再在业务低峰执行换盘；如果盘已经出现大量重映射、待定扇区或内核持续报I/O错误，就不再等低峰，而是尽快安排维护窗口。

下面这张表是我实际判断时常用的决策框架，具体阈值要结合业务SLA和硬件支持能力调整：

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、repair，RAID10换盘后常见的是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 故障判定表：把“看起来坏了”变成可执行结论

这张表不是让你机械套用，而是强迫自己把“现象”落到“原因”和“动作”上。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_speed

sync_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 --mail=monitor@example.com --delay=300 --daemonise smartctl -a /dev/sdb | grep -Ei 'Reallocated|Pending|Offline|CRC|Temperature'

mdadm --monitor适合做基础告警，但它依赖本机邮件配置，生产环境最好接入统一告警平台。常见监控代理有mdadm采集插件，没有插件就写个定时脚本解析/proc/mdstat和/sys/block/md0/md/。热备盘也要单独监控，别让它变成“看起来有、实际不可用”的摆设。备件库里的同容量盘定期上机自检，避免真出事时发现备件也是坏的。

5.3 常见问题速查表

5.4 实操心得：几条反直觉的经验

第一条，重建不是越快越好。全速重建能把降级窗口压到最短，但也可能把业务延迟打爆，甚至让同组另一块盘在高温高负载下提前出问题。生产环境里，限速是默认动作，低峰再放开。第二条，换盘前先备份。RAID10单盘失效时数据通常还在，但重建过程中任何意外都可能让“还能读”变成“读不出来”，备份是唯一兜底。第三条，记录序列号和槽位。设备名会变，序列号不会，换盘前拍照、记录、双人确认，比事后争论“拔的是哪块”有用得多。

第四条，别在同一时间做多件事。重建期间不要跑全盘备份、不要做一致性检查、不要压测新盘，这些都会抢IO。第五条，热备盘要定期演练。很多环境配了热备但从没验证过自动顶上，真出事时才发现热备盘容量不对或者被其他阵列占用。最后再分享一个小技巧：把“先fail再remove、先清签名再加盘、重建前先限速”这三句话贴在机柜门内侧，比出事时翻文档管用；换盘流程写成一张A4纸，包含命令、序列号记录栏和回滚步骤，值班的人照着做，误操作会少很多。