1. 从零认识软RAID服务器磁盘阵列到底解决什么问题事情的起点很简单手上有一台二手塔式服务器四块 4TB 的机械盘打算拿来放备份数据和一堆虚拟机镜像。单盘跑起来顺序读写也就 150MB/s 上下更让人睡不着觉的是没有任何冗余——盘一坏数据基本就没了。这时候绕不开的一个词就是磁盘阵列。它要解决的核心问题只有两个把多块盘拼成一块逻辑盘来提性能或者给数据加冗余保证坏了盘还能活。硬RAID靠独立阵列卡带缓存和电池性能稳、对系统透明但一张像样的卡少说几百上千二手卡还可能踩到刷固件、掉阵列的坑。软RAID则把这件事交给操作系统的内核模块来做Linux 下就是mdadm这套工具链。它不要额外硬件配置全在文件里坏了盘能看日志能手动干预特别适合我这种预算有限、又需要清楚知道每一块盘在干什么的场景。这篇内容适合三类人看第一类是刚接手服务器运维、被要求把这几块盘做成阵列的新手第二类是想在家用 NAS 或自建服务器上做冗余存储的折腾党第三类是已经会用mdadm但总在重建、扩容、开机自启上翻车的人。我会把 RAID 0/1/5/10 的创建过程、参数计算、故障演练、踩坑经验完整走一遍命令和输出都贴出来你照着抄基本就能跑通。2. 动手前的环境准备与磁盘规划2.1 硬件与系统环境说明先把环境交代清楚不然后面看命令容易对不上号。我这次用的是一台装了 Ubuntu Server 22.04 的机器内核 5.15四块容量一样的 4TB SATA 机械盘分别挂在/dev/sdb、/dev/sdc、/dev/sdd、/dev/sde。系统盘是另外一块 SSD装在/dev/sda这块盘绝对不参与阵列免得手一抖把系统搞没。磁盘容量一致这件事非常重要尤其对 RAID 5 来说。阵列的可用容量是按最小那块盘来算的如果我拿三块 4TB 加一块 2TB 组 RAID 5那 2TB 盘只有 2TB 会被用上剩下的空间白瞎。所以规划阶段第一件事就是确认所有成员盘容量尽量对齐型号批次最好也接近因为不同批次的盘在坏道分布、固件行为上会有差异重建时容易出现连锁问题。我建议在实操前先做一张规划表把自己的盘、角色、用途写清楚避免命令敲到一半忘了哪块盘是干嘛的设备名容量规划角色备注/dev/sdb4TB阵列成员 / 系统盘分别对应阵列槽位/dev/sdc4TB阵列成员保持容量一致/dev/sdd4TB阵列成员预留热备可换/dev/sde4TB热备盘不参与初始写入2.2 磁盘清理与分区类型标记新盘或者从别处拔来的盘上面很可能残留着旧的分区表、文件系统甚至旧的阵列元数据。如果不清干净mdadm创建时会报设备忙或者认到旧的超级块。我习惯第一步先用lsblk看清楚整体结构再用wipefs把签名抹掉lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT sudo wipefs -a /dev/sdb /dev/sdc /dev/sdd /dev/sdewipefs -a会把设备上的文件系统、分区表等各种签名一并清掉这是最省事也最彻底的做法。清完之后我会给每块盘分一个区类型标记成fdLinux raid autodetect。有人喜欢直接拿整块裸盘/dev/sdb去做阵列成员这也完全可以而且更简单少一层分区映射。两种做法都行我这次为了演示规范流程还是走分区的方式sudo fdisk /dev/sdb # 依次输入 n 新建分区、p 主分区、1 分区号、回车取默认起始 # 再输入 t 改类型、fd 选 Linux raid autodetect、w 写入四块盘都这样处理完会得到/dev/sdb1、/dev/sdc1、/dev/sdd1、/dev/sde1四个分区。注意如果你打算后续做在线扩容grow整块裸盘做成员往往比分区的灵活性更好因为分区扩容还要处理分区表但分区方式在混合用途下更清晰。这个取舍先想好重建阵列的成本很高。2.3 mdadm 安装与核心概念对照工具安装很简单Debian/Ubuntu 系直接一条命令RHEL/CentOS 系换dnf即可sudo apt update sudo apt install -y mdadm mdadm --version在敲创建命令之前有几个概念必须先对齐否则参数会填错。RAID level是冗余和性能的组织方式raid-devices是参与数据读写的成员数量spare-devices是热备盘数量平时不参与读写一旦有盘掉线它会顶上chunk size是条带单位也就是数据被切成多大一块轮流写到各盘上默认 512K机械盘和 SSD 的合适取值不一样。理解这四件事再看mdadm --create的参数就不会懵。还有个容易忽略的点阵列设备名/dev/md0、/dev/md1是内核动态分配的重启后如果没固定好配置编号可能会变这会直接导致fstab挂载失败开机进不了系统。所以后面第 4 章我会专门讲怎么把阵列信息固化下来这是软RAID最容易出事的地方务必别跳过。3. 四类常见阵列的创建实操3.1 RAID 0读写性能拉满的条带阵列RAID 0 不提供任何冗余一块盘坏整个阵列的数据就废了所以它只适合放能重算、能重下的数据比如临时编译目录、缓存、可再生的中间文件。它的好处是容量全用上读写接近盘数线性叠加。四块 4TB 组 RAID 0可用容量就是 16TB。创建命令如下至少两块盘起步我这次用两块演示sudo mdadm --create /dev/md0 --level0 --raid-devices2 \ --chunk512 /dev/sdb1 /dev/sdc1敲完回车会弹一句确认Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started.创建完立刻看状态cat /proc/mdstat sudo mdadm --detail /dev/md0/proc/mdstat里会显示md0 : active raid0 sdc1[1] sdb1[0]还有一行chunk size。RAID 0 因为不需要同步校验创建后马上就是active不像 RAID 5 会先经历漫长的resync。--detail输出里的State : clean、Active Devices : 2、Failed Devices : 0都是要关注的字段。提示RAID 0 的 chunk 大小对性能影响不小。做顺序大文件读写512K 到 1M 比较合适做大量随机小 IO比如数据库chunk 太大反而不好可以试 64K 到 128K。这个值用--chunk指定单位是 KB。3.2 RAID 1两块盘的镜像冗余RAID 1 就是镜像两块盘写一样的数据读的时候可以并行读提升读性能写性能基本等于单盘。容量方面两块 4TB 只有 4TB 可用一半的盘拿来当保险。它最简单也最皮实一块盘挂了另一块照样能用适合放系统盘、重要的配置文件和小容量关键数据。sudo mdadm --create /dev/md1 --level1 --raid-devices2 \ /dev/sdb1 /dev/sdc1RAID 1 创建后会立刻开始初始同步resync第一次做的时候会看到进度条。这里有个经验初始同步会全盘扫一遍4TB 机械盘大概要跑好几个小时期间性能会受影响。如果你确定两块盘都是新盘、内容无所谓可以在创建时加--assume-clean跳过初始同步阵列会瞬间可用sudo mdadm --create /dev/md1 --level1 --raid-devices2 \ --assume-clean /dev/sdb1 /dev/sdc1但--assume-clean有风险它假设两块盘数据本来就一致如果其中一块是旧数据跳过同步后两盘内容对不上将来出问题不好排查。所以只有确认盘是全新的、或者数据会重新格式化覆盖时才用它别为了省那几小时乱加。3.3 RAID 5容量与安全折中的主流选择RAID 5 是服务器里最常见的方案用一块盘的容量存分布式校验剩下 N-1 块盘的空间可用允许任意一块盘损坏。三块 4TB 组 RAID 5可用容量是 8TB损失一块盘的容量换来了单盘冗余性价比很高。代价是写性能偏弱——每次写都要读旧数据、算校验、再写这就是常说的写惩罚。sudo mdadm --create /dev/md0 --level5 --raid-devices3 \ --chunk512 /dev/sdb1 /dev/sdc1 /dev/sdd1确认后它会启动然后立刻进入resync状态md0 : active raid5 sdd1[2] sdc1[1] sdb1[0] 8380416 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] [...................] resync 5.0% (209817/4190208) finish180.2min speed368K/sec这个resync是 RAID 5 创建时必须经历的初始化因为校验块要算出来写下去。4TB 级别通常要跑几个小时。注意一点此时阵列虽然能用但正在同步别急着往上写大量数据等状态变成[UUU]且不再 progress 再正式用。RAID 5 还有一个致命弱点就是重建窗口期。当一块盘坏了重建需要读所有存活盘上的数据来还原4TB 盘读一遍可能要十几个小时这期间如果第二块盘也坏了整组数据全没。所以大容量盘上单盘冗余的 RAID 5 越来越不被推荐容量上了 8TB 之后很多人直接上 RAID 6 或者 RAID 10。3.4 RAID 10性能与冗余的居中方案RAID 10 是先做镜像再做条带把盘两两配成镜像对然后在镜像对之间条带化。它需要偶数块盘至少四块可用容量是一半。写性能比 RAID 5 好很多冗余能力也强——只要不是同一镜像对的两块盘同时坏就能扛住。它是数据库、虚拟化存储这类既想要性能又想要安全场景的常客。sudo mdadm --create /dev/md0 --level10 --raid-devices4 \ --layoutf2 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1--layout参数控制镜像对的排列方式f2是近端布局也是默认。创建后同样会先同步。四块 4TB 可用容量 8TB跟三块盘组 RAID 5 一样但 RAID 10 扛双盘故障的能力更强代价是盘用得更多。阵列级别最少盘数4块4TB可用容量容错写性能适用场景RAID 0216TB无最高临时、可再生数据RAID 124TB单盘单盘水平系统盘、关键小数据RAID 538TB单盘一般通用大容量存储RAID 648TB双盘偏低大容量冷数据RAID 1048TB条件双盘高数据库、虚拟机选型这件事没有标准答案我自己的判断顺序是先看数据能不能丢再看要不要性能最后看盘够不够。能丢又图快就 RAID 0不能丢又要快就 RAID 10不能丢但要容量就 RAID 5 或 6。4. 文件系统创建、挂载与开机自启4.1 格式化时的 stride 与 stripe-width 参数阵列建好只是一个块设备上面还得铺文件系统。如果直接mkfs.ext4 /dev/md0ext4 不知道底下是阵列会按单盘逻辑去算块分配容易造成条带对齐错位、性能打折。正确做法是把 chunk 大小换算成 ext4 能理解的stride和stripe-width。以 RAID 5、chunk 512K、4K 块大小为例stride chunk / block_size 512K / 4K 128RAID 5 的校验占一份所以数据盘数是 N-1stripe-width stride × (N-1) 128 × 2 256。RAID 0 和 RAID 10 没有分布式校验stripe-width stride × N。# RAID 5 三盘示例 sudo mkfs.ext4 -E stride128,stripe-width256 /dev/md0 # 如果更看重可靠性和大文件也可以选 XFS sudo mkfs.xfs -d su512k,sw2 /dev/md0这里的sustripe unit就是 512K 的 chunkswstripe width是数据盘的个数 2。这两套参数说白了就是告诉文件系统我下面是一个条带阵列你分配块的时候按这个粒度来对齐对齐之后顺序读写能明显看到提升。提示换算完这些参数最好记在你的运维笔记里。以后换盘、重建、迁移的时候还会用到记错一个数字可能导致性能在无声无息中掉一半而且不容易发现。4.2 mdadm.conf 与 initramfs 的固定动作格式化完别急着挂载先解决一个更要命的问题重启后阵列能不能自动组起来。答案是靠/etc/mdadm/mdadm.confUbuntu或/etc/mdadm.conf部分发行版这个配置文件。如果不写重启后虽然内核能扫到md0但编号可能乱或者干脆不进 initramfs 里组装导致/dev/md0不存在fstab挂载失败系统直接掉进紧急模式。标准流程是先扫描现有阵列把信息追加进去sudo mdadm --detail --scan /etc/mdadm/mdadm.conf cat /etc/mdadm/mdadm.conf输出大致是ARRAY /dev/md0 metadata1.2 nameserver:0 UUIDxxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx这行里的 UUID 是阵列的唯一标识用 UUID 比用/dev/md0稳因为设备编号会变。写完配置文件后最关键的一步是把配置更新进 initramfs这一步十个人里有八个会忘# Debian / Ubuntu sudo update-initramfs -u # RHEL / CentOS 系 sudo dracut -f不更新 initramfs重启时早期引导阶段根本没有正确的阵列配置阵列就组不起来。我见过太多人在这一步翻车以为是盘坏了其实只是忘了更新引导镜像。4.3 fstab 挂载与简易性能验证最后是挂载和开机自动挂载。fstab里同样建议用 UUID先拿到文件系统的 UUIDsudo blkid /dev/md0 # 输出示例/dev/md0: UUIDabcd-1234-... TYPEext4然后写进/etc/fstabUUIDabcd-1234-... /mnt/raid ext4 defaults,noatime 0 2这里的noatime是省去做读操作时更新访问时间的写入对阵列来说能减少不必要的写 IO是很划算的一个选项。第六列写2表示非根文件系统在开机时由 fsck 检查。改完fstab千万别直接重启先做一次空挂载测试否则配错了重启就直接进不了系统sudo mkdir -p /mnt/raid sudo mount -a df -h /mnt/raidmount -a会按fstab重新挂载所有条目能挂上说明配置没问题。然后简单测一下性能心里有个数sudo dd if/dev/zero of/mnt/raid/test.bin bs1M count4096 oflagdirect sudo dd if/mnt/raid/test.bin of/dev/null bs1M iflagdirectoflagdirect绕过页缓存测出来的才是真实落盘速度。RAID 5 三块机械盘的顺序写大概在 200 到 300MB/s读能到 400MB/s 上下不同盘差异很大只要不出现个位数就没大问题。测完记得删掉测试文件。5. 阵列的日常维护与故障演练5.1 模拟掉盘与热备盘自动接管阵列搭起来不代表就完了真正的价值在于坏盘的时候你能不能扛住。所有软RAID上手之后我强烈建议做一次掉盘演练把可能发生的事提前演一遍。方法是手动把某块盘标记为故障sudo mdadm --manage /dev/md0 --fail /dev/sdb1 cat /proc/mdstat标记故障后如果阵列里配了热备盘内核会自动把热备盘拉进来重建/proc/mdstat里能看到recovery进度。如果没配热备盘阵列状态会变成[U_U]或[_UU]也就是降级运行。降级状态下数据还能读性能会下降尤其是 RAID 5但不会立刻丢数据这就给了你换盘的窗口。如果你有闲置的盘可以在创建时就加进去当热备sudo mdadm --create /dev/md0 --level5 --raid-devices3 \ --spare-devices1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1热备盘平时不参与读写但一旦有成员盘故障它自动顶上开始重建不需要人工干预。对无人值守的服务器来说这一块盘能把你半夜被叫起来换盘的风险降很多。5.2 坏盘拔出、替换与重建全过程演练完要把它恢复回去。真实场景里的流程是先确认哪块盘坏了标记故障把它从阵列移除换上新盘再作为热备加回去等重建完成。# 1. 标记故障 sudo mdadm --manage /dev/md0 --fail /dev/sdb1 # 2. 从阵列中移除 sudo mdadm --manage /dev/md0 --remove /dev/sdb1 # 3. 物理拔掉旧盘插入新盘清掉新盘残留签名 sudo wipefs -a /dev/sdb # 4. 新盘重新分区类型标记 fd然后加回阵列 sudo mdadm --manage /dev/md0 --add /dev/sdb1 # 5. 观察重建进度 watch -n 5 cat /proc/mdstat重建过程中有几点必须注意。第一重建期间不要对阵列做大量写入重建本身已经占满了磁盘带宽再叠加业务 IO 会让重建慢上加慢反而拉长了危险窗口期。第二可以在阵列上加内部位图加快重建sudo mdadm --grow /dev/md0 --bitmapinternal位图记录哪些区域需要重建掉盘后只重建变化过的部分能把几小时的重建压缩到几十分钟。代价是平时写操作会略微变慢但对大容量阵列来说非常值得。第三一定要配置监控告警让阵列在降级时主动通知你而不是等你想起来才去查sudo mdadm --monitor --scan --daemonise --mailadminexample.com5.3 在线扩容 reshape 的注意事项盘用满了想加容量软RAID支持在线扩容。假设原来是三块盘的 RAID 5我再加一块盘进去从[UUU]变成四盘阵列# 新盘先分区、标记类型然后加入 sudo mdadm --manage /dev/md0 --add /dev/sde1 # 把阵列成员数从 3 扩到 4 sudo mdadm --grow /dev/md0 --raid-devices4扩容过程中内核会做reshape把数据重新分布到新盘上这一步比普通重建更耗时也更危险。有几个硬性建议扩容前一定先备份数据reshape 中断可能导致阵列无法恢复对 RAID 5 扩容时mdadm 会提示 critical section需要用--backup-file指定一个备份文件防止断电导致数据错位sudo mdadm --grow /dev/md0 --raid-devices4 \ --backup-file/root/md0-backup这个备份文件要放在和阵列不同的物理盘上通常放系统盘即可它只在关键区段临时用不会持续占用空间。reshape 完成后块设备容量变大但文件系统还停留在原来大小需要再扩一次文件系统# ext4 在线扩容 sudo resize2fs /dev/md0 # XFS 直接挂载状态下就能扩 sudo xfs_growfs /mnt/raid扩容是个不可逆的操作中途不能随便停所以我一般选业务低峰的夜间做并且提前算好时间——4TB 级别 reshape 常常超过一整晚。6. 常见问题排查速查与踩坑经验6.1 阵列组装失败、状态异常的排查表软RAID出问题大多集中在组装阶段和故障恢复阶段我把常见现象和原因整理成一张表遇到时对照着查现象可能原因排查方向重启后 /dev/md0 不存在mdadm.conf 未写或 initramfs 未更新检查配置和 update-initramfs开机进紧急模式fstab 用了 /dev/md 且编号变化改用 UUID 挂载create 报 device busy盘上有旧文件系统或旧阵列元数据wipefs -a 清理阵列状态 inactive成员盘缺失或组装信息不匹配mdadm --examine 看每块盘阵列反复降级盘线接触不良、盘本身坏道查 dmesg 里 IO 错误重建速度极慢无位图、盘在忙、盘批次差grow --bitmapinternal当阵列组不起来时最有用的一条命令是逐个检查每块盘上的超级块sudo mdadm --examine /dev/sdb1它会打印这块盘记录的阵列 UUID、成员角色、事件计数。如果多个盘的事件计数不一致说明某块盘落后了可以用--force强制组装但要清楚这是在拿数据一致性冒险务必先备份。6.2 性能不达预期的定位思路阵列跑起来发现比单盘还慢这种情况并不罕见通常有几个原因。第一是文件系统没做条带对齐stride、stripe-width参数不对导致每次 IO 都跨条带产生额外寻道。第二是 RAID 5 的写惩罚随机小写性能天生就差这是级别决定的换 RAID 10 才有明显改善。第三是机械盘的随机 IO 本来就弱如果你的负载是小块随机读盘数再多也比不过一块 SSD这时候该考虑的是加缓存盘或者换 SSD。排查顺序我一般是先用iostat -x 1看每块盘的%util和await如果某块盘 utilization 长期 100% 就是瓶颈在那再用dd分别测单盘和阵列的裸设备速度做对比确认是阵列层的问题还是文件系统层的问题最后检查/proc/mdstat的 chunk 和 layout 是否符合预期。有条经验很实在机械盘组 RAID 5chunk 越大顺序性能越好但重建也越慢这是要用性能和风险一起权衡的。6.3 我踩过的几个坑与经验总结第一个坑是关于--assume-clean的。我曾经给一个看起来是全新盘的阵列加了这个参数跳过同步结果那块盘的某一小段实际残留了旧数据同步又被跳过这块坏数据就永远留在阵列里直到很久以后读文件才报校验错误。所以现在的原则是除非我百分之百确认盘是出厂新盘或者会立刻全盘覆盖否则老老实实等初始同步跑完。第二个坑是设备名漂移。有次维护完重启/dev/sdb和/dev/sdc的顺序变了因为启动时内核扫描顺序不固定好在我全程用 UUID 挂载才没出大事。所以阵列成员盘也建议优先用带稳定标识的方式规划或者在mdadm.conf里让它按 UUID 组装别依赖/dev/sdX这种可能变的路径。第三个坑是忘了配监控。有次一块盘悄悄掉了线阵列降级运行了半个多月没人发现直到第二块盘也出问题才炸雷好在最后数据救回来了。从那以后我给自己定了个规矩凡是软RAID必配mdadm --monitor邮件告警把降级事件第一时间推给自己这比事后救数据便宜太多。最后一个体会是关于备份的。RAID 保证的是可用性不是备份。它挡得住单块盘物理损坏挡不住误删、勒索、文件系统损坏也挡不住机房整体事故。再好的阵列我也一定会在另一台机器或另一个介质上留一份离线备份。这个原则我在最开始做阵列的时候没太在意吃过一次亏之后才真正当回事也希望你别重复这个代价。7. 阵列迁移、退役与后续扩展7.1 把整组阵列搬到另一台机器设备换代或者机箱迁移的时候软RAID有个很实用的特性阵列的元数据是写在成员盘上的整组盘拔下来插到另一台装了mdadm的机器上通常能直接认出来。标准做法是先把原机的阵列停掉再拔盘sudo umount /mnt/raid sudo mdadm --stop /dev/md0停阵列前务必先卸载文件系统否则缓存里的数据没落盘直接断电式拔盘会丢数据。到了新机器上先确认所有成员盘都被识别然后扫描组装sudo mdadm --assemble --scan cat /proc/mdstat sudo mount /mnt/raid如果新机器上已经有同名阵列导致编号冲突就手动指定设备名组装mdadm --assemble /dev/md5 /dev/sdb1 /dev/sdc1 /dev/sdd1。搬到新机后别忘了在新机器上重新生成mdadm.conf并更新 initramfs否则下次重启又会组不起来。这一步和初始搭建时一样容易漏我养成习惯后会把它写进迁移检查清单做完打勾才算完。7.2 阵列退役与磁盘复用阵列整体不用了正确的退役顺序是先卸载文件系统再停阵列然后清掉每块盘上的超级块这样盘才能另作他用或者送人。直接格盘而不清超级块mdadm会认为它还是阵列成员插到别的机器上可能触发自动组装把好好的数据盘当成阵列成员拉进去这种事我见过不止一次。sudo umount /mnt/raid sudo mdadm --stop /dev/md0 sudo mdadm --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1 sudo wipefs -a /dev/sdb /dev/sdc /dev/sdd--zero-superblock专门抹掉阵列元数据wipefs再顺手清掉残留的文件系统签名两步做完这块盘就彻底干净了。如果只是想把某块盘从阵列里拿出来单独用也可以先--fail、再--remove然后对这块盘单独清超级块其他盘不受影响。提示退役流程同样建议在两个地方留记录——设备资产台账里标注该阵列已退役以及确认所有重要数据已经另有备份。阵列停掉之后盘上数据的唯一副本就只剩这几块盘本身了别在这一步想当然。7.3 什么时候该从软RAID升级到别的方案软RAID用得久了会碰到它的天花板。如果业务对写性能要求很高、又跑的是数据库这类随机写密集负载尤其上了 RAID 5那软RAID的写惩罚会让你很痛苦这时硬RAID卡带缓存或者干脆换成分布式存储、SSD 全闪阵列收益会明显得多。另外一个信号是盘数越来越多超过十几块之后纯靠mdadm管理故障和扩容会越来越费神集中化的管理界面或者更高级的存储方案能省不少力气。还有个现实因素软RAID的校验计算吃 CPU。四块机械盘的规模基本感觉不到但如果盘数堆到十几块、又是 RAID 6单核可能就被打满了需要专门看top里的%si和md线程占用。判断标准很简单——如果 CPU 因为阵列计算长期高负载性能又上不去那就是该考虑换方案的时候了。对我自己这台四盘小机器来说软RAID还能舒舒服服再跑好几年不急着折腾。8. 实操中的几个细节补充8.1 磁盘健康与阵列状态的日常巡检阵列的事不是搭完就一劳永逸日常巡检才是保命的关键。我固定每周看一眼这几样cat /proc/mdstat确认所有成员都是[UUU]没有_mdadm --detail /dev/md0看Failed Devices是不是 0smartctl -a /dev/sdb查每块盘的 SMART重点看Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count这三个值有没有增长。SMART 里的待映射扇区一旦开始涨往往是盘要坏的先兆早发现就能趁阵列还健康主动换盘而不是等它掉线。for d in sdb sdc sdd; do echo $d sudo smartctl -H -A /dev/$d | grep -E Health|Reallocated|Pending|CRC done有条件的话把这些巡检脚本化、加进定时任务输出异常再告警。实话说人工巡检靠记性早晚会漏脚本靠的是纪律不会偷懒。8.2 关于测试环境和生产环境的差别最后想提醒一点我这台机器上演练的所有操作包括--fail、--remove、--grow、--assume-clean都是在确认有备份、盘上数据可丢的前提下做的。生产环境里这些命令每一次都要先想清楚后果尤其是--force和--assume-clean这两个参数它们能救急也能闯祸。真正稳妥的做法是在生产上用之前先在虚拟机上把整条流程走一遍记下命令和输出确认无误了再上真机。虚拟化环境里拿几块虚拟磁盘练手成本几乎为零练熟再上生产这是我这些年最省心的一条经验。
