提起 Linux 服务器的存储RAID 这三个字母一定是绕不开的。从家里那台两块盘的小主机到机房里动不动几十块盘的生产服务器RAID 都是一套被验证过无数遍的存储技术落地方案。它要解决的核心问题其实很朴素既想让多块硬盘的容量加在一起、跑出更好的性能又想在某一两块盘突然出问题时数据不丢、服务不中断。这篇文章就从 RAID 的级别选择讲起一直讲到 mdadm 的创建、日常维护和故障处理适合刚接触服务器运维的朋友也适合那些已经被 RAID 卡折腾过几次、想系统梳理一遍的人。我写这篇文章的底气来自这些年实际维护过的机器从双盘家用小机到几十块盘的生产存储踩过的坑不少但也正因为如此下面讲的每一段都值得你花时间看完。1. 为什么还在用 RAID先搞清楚它到底解决什么问题1.1 RAID 不是什么黑魔法就是把多块盘组织成一块盘先别急着敲命令得先想明白一个问题现在 SSD 这么便宜单块大容量盘也不是买不起为什么还要用 RAID真实原因是RAID 的价值不在于一块大盘本身而在于它同时解决了两件单块盘做不到的事——容量叠加和故障冗余。RAID 的英文全称是 Redundant Array of Independent Disks独立磁盘冗余阵列。它通过一套逻辑把多块物理硬盘统一管理起来对操作系统只暴露一个块设备。也就是说你在 Linux 下看到的可能还是 /dev/md0 或 /dev/sda但底层数据实际分布在多块盘上。数据按条带、镜像还是奇偶校验来分布就构成了不同的 RAID 级别。很多新手最容易犯的错是把 RAID 当成备份方案。这是一个非常危险的误解。RAID 1 能扛住一块盘故障RAID 6 能扛住两块盘故障但如果是误删文件、勒索病毒、火灾水淹RAID 一点办法都没有。RAID 的本质是提高可用性不是数据备份。备份是另一套系统要做的事两者不能互相替代。另外强调一点RAID 也并不天然提升一切性能。比如 RAID 1 在写入时通常不会比单盘快太多RAID 5 因为要计算奇偶校验小文件随机写入反而可能比单盘还慢。所以选级别之前先搞清楚你的业务是顺序读写多还是随机读写多再往下聊。1.2 常见 RAID 级别对比0 / 1 / 5 / 6 / 10 到底怎么选先放一张我做运维时经常拿来参考的速查表看完再逐条解释RAID 级别最低盘数可用容量容错能力读性能写性能典型场景RAID 02总容量无高高临时缓存、非关键数据RAID 12单盘容量允许坏 1 块较高与单盘相当系统盘、数据库日志RAID 53(N-1) × 单盘允许坏 1 块高中文件服务器、量大而容错要求一般RAID 64(N-2) × 单盘允许坏 2 块高低大容量存储、归档RAID 104N/2 × 单盘每组允许坏 1 块高高数据库数据盘、虚拟化存储RAID 0 把数据切成条带轮流写到每一块盘上。两块盘合起来容量翻倍读写速度也接近翻倍但一块盘坏数据就全没了。它适合放一些丢了也无所谓的缓存数据或者能快速重建的业务数据。我不建议你把任何重要的系统数据放在 RAID 0 上。RAID 1 则是把同样的数据完整写到两块盘上也就是镜像。两块盘的容量最终只有一块盘可用但任意一块盘坏掉另一块盘还能继续扛着。老牌生产环境里系统盘用 RAID 1 是最稳妥的选择。它的写性能受限于单盘读性能因为可以两端同时读通常会比单盘好一些。RAID 5 在数据块之外增加了奇偶校验块校验块轮流分散存在各块盘上。N 块盘组成 RAID 5可用容量是 N-1 块盘因为其中一块盘的容量用来存放校验信息。当一块盘坏掉时系统能靠其他盘的数据和校验块反推出丢失的数据但重建时 CPU 和磁盘 IO 压力都会明显上升这段时间如果再坏一块盘整个阵列就废了。RAID 6 相当于做了两次校验允许同时坏两块盘安全性比 RAID 5 高一截代价是可用容量变成 N-2 块盘而且写入时要算两次校验性能下降得比较明显。需要大容量、又担心重建期间二次故障的场景可以考虑它。RAID 10 是把镜像和条带结合先把盘两两做成镜像再把多组镜像做成条带。最少需要 4 块盘可用容量是总容量的一半但容错能力和性能都很均衡尤其适合数据库这种对随机写特别敏感的场景。我自己的经验是如果不差盘数据库数据盘能上 RAID 10 就别犹豫。最后补一句RAID 5 和 RAID 6 对盘的容量一致性要求很高。混用不同容量或不同转速的盘不是不行但阵列容量按最小盘算重建也容易被慢盘拖累。有条件的话同一组阵列尽量用同批次、同型号、同容量的盘。2. 硬 RAID 还是软 RAID机器上的盘该交给谁管2.1 硬 RAID 卡服务器上那块独立的阵列卡硬 RAID 意味着有一个独立的物理设备也就是 RAID 卡它上面有自己的处理器ROC和缓存用来完成条带化、奇偶校验计算和写缓存管理。操作系统看到的只是一个已经组合好的逻辑磁盘不需要知道底层细节。硬 RAID 卡的好处是性能稳定尤其是带电池或闪存保护的回写缓存能在断电时把还没有落盘的写入数据保护起来。生产服务器上很常见的 LSI / MegaRAID 系列、Broadcom 新一点的 95xx 系列都属于这一类。管理这类卡时会用到厂商工具很多管理员都熟悉的 storcli 就是其中一种命令大概长这样storcli /c0 show all storcli /c0 /eall /sall show storcli /c0 add vd typeraid1 drives252:0,252:1第一条命令看控制卡整体状态第二条看物理盘状态第三条创建 RAID 1 虚拟磁盘。硬 RAID 一旦配好在 Linux 里通常不需要额外驱动系統直接识别出 /dev/sda 这样的设备。日常监控我一般看 megaraid 相关的日志以及 storcli 输出里的 State 字段里面出现 Dgrd 就要警惕了。2.2 Linux 软 RAIDmdraid的取舍软 RAID 则是由操作系统用软件来实现的 RAID 功能。Linux 内核自带的 mdraid多重设备驱动是最常见的软 RAID 方案它不需要额外硬件直接利用 CPU 和内存完成奇偶校验等计算。很多运维看不起软 RAID觉得软的就是性能差。但 mdraid 这些年其实做得相当成熟内置的 RAID 1、RAID 5、RAID 6、RAID 10 都能支持而且管理工具 mdadm 的命令行设计得很舒服。对大多数中小型业务来说CPU 算力完全不是瓶颈真正决定性能的还是物理盘的 IO 能力。实验室、虚拟机环境、没有 RAID 卡的普通服务器我都是直接用 mdraid。它的一个隐藏优点是迁移性好——Linux 内核版本差距不太大的机器之间整块阵列可以拆下来搬到另一台机器上重新组装而硬 RAID 卡往往跟服务器型号绑定换平台时兼容性容易出问题。选择软 RAID 前也要想清楚几件事一是操作系统必须能从内核层识别阵列所以 /boot 这种启动分区如果放在 RAID 5 上引导阶段可能会有额外麻烦二是 CPU 负载会略高一些但现代 CPU 算 RAID 5 的校验基本没什么感觉三是写缓存由系统内存承担不像硬 RAID 卡那样有独立断电保护所以更要加强 UPS 的配置。2.3 storcli 设置 RAID 模式时几个容易忽略的细节现在很多新服务器出厂时RAID 卡默认可能是 JBOD 模式也有一些是 VMD 控制器直通模式。如果你想用独立 RAID 卡做硬 RAID就需要先进到 BIOS 里的 RAID 卡配置界面或者用 storcli 这类工具把盘切换成 RAID capable 模式再创建虚拟磁盘。用 storcli 时最容易踩的坑是按错盘符控制器。服务器通常有两个控制器一个管前面板一个管后面板命令里如果把 /c0 写成 /c1就可能操作到完全意想不到的磁盘组。我还有一次因为漏加了 write-back 策略阵列创建之后写性能始终上不去后来才发现默认可能是 write-through。硬 RAID 里这两者的差别很大带缓存的卡通常建议 write-back always 回写策略前提是你确认断电保护模块是正常的。创建完虚拟磁盘后别忘了在 Linux 里重新扫描设备或者干脆重启系统。很多机器在 RAID 卡创建完 VD 后操作系统不会立刻感知到新磁盘必须要 rescan 或 reboot。我自己的习惯是配完阵列重启一次看到所有盘都正确识别了再继续做系统安装这一步能省掉后面很多莫名其妙的麻烦。3. 用 mdadm 从零搭建一套软 RAID 阵列3.1 动手前先盘好硬盘布局用 mdadm 做 RAID 之前我强烈建议先花几分钟把磁盘布局规划清楚而不是直接对着两块空盘就开始敲命令。需要想清楚的有三件事用哪些盘做阵列、系统盘和数据盘是否分开、每块盘的分区表怎么建。系统盘和数据盘尽量分开。系统盘单独一块 SSD 或一组 RAID 1 就够用了数据盘再单独组成 RAID 5 或 RAID 10这样系统出问题时不会牵连数据阵列数据阵列重建时也不会拖垮系统 IO。很多人图省事把所有盘塞到一个 RAID 组里结果系统负载一高就互相影响。磁盘分区方面我一般习惯在整块盘上建一个分区或者直接用整盘然后用分区作为 RAID 成员。比如 /dev/sdb 上只建一个分区 /dev/sdb1类型设为 Linux RAID auto。分区的好处是将来如果和 UEFI 引导、LVM 结合灵活性会更高。不过实际操作中直接用整块 /dev/sdb 的情况也很普遍尤其盘数量多的时候会省不少事。还要留意盘中是否残留了之前的 MD 元数据和分区信息。新的空盘可能干净但做过阵列的盘拿出来复用的时候很容易带着旧信息导致 mdadm 组装时认错。稳妥起见复用旧盘时先把盘彻底清一遍wipefs -a /dev/sdb sgdisk -Z /dev/sdbwipefs -a会清掉文件系统、RAID 元数据和分区表签名sgdisk -Z是清 GPT 主表。这两步做完再开始创建阵列能避免 90% 以上的莫名奇怪问题。3.2 创建 RAID 1最稳妥的双盘方案我先拿 RAID 1 演示一次完整流程因为它是思路最直观、也最不容易出错的级别。假设有两块新盘 /dev/sdb、/dev/sdc先确认它们的容量和状态lsblk fdisk -l /dev/sdb /dev/sdc确认无误后创建 RAID 1mdadm --create /dev/md0 --level1 --raid-devices2 /dev/sdb /dev/sdc这里可以加--metadata1.2指定元数据版本。mdadm 默认用的就是 1.2元数据放在盘的起始位置附近现代系统都用这个版本。创建命令执行后mdadm 会问你是否确认输入 y 回车。注意这里有一个看似吓人的警告它提示分区表会被擦除这是正常现象。创建完成后立即查看状态cat /proc/mdstat你会看到类似[UU]的标记表示两块盘都是 healthy。但此时阵列其实还在初始同步也就是把 sdb 的数据镜像到 sdc需要等它 100% 完成才算真正建好。同步期间系统可以正常使用但不要在这个节骨眼重启服务器。接着格式化并挂载mkfs.ext4 /dev/md0 mkdir /mnt/data mount /dev/md0 /mnt/data为了开机自动挂载编辑 /etc/fstab 加一行注意用 UUID 而不是设备名因为设备名在重启后可能变化。先查出阵列的 UUIDblkid /dev/md0然后类似这样写入 fstabUUIDxxxx-xxxx-xxxx /mnt/data ext4 defaults,noatime 0 2写错了 fstab 会导致开机卡在 mount 阶段所以强烈建议写完跑一下mount -a验证。3.3 创建 RAID 5 和 RAID 10容量、性能、冗余的平衡RAID 5 最少要 3 块盘RAID 10 最少要 4 块盘。创建命令也差不多只是 level 和 raid-devices 不同。我以 3 块 2TB 盘做 RAID 5 为例mdadm --create /dev/md0 --level5 --raid-devices3 /dev/sdb /dev/sdc /dev/sdd --chunk64--chunk是条带块大小决定了数据如何切分。64K 是比较通用的默认值数据库类随机读写可以用 16K~32K大视频文件顺序读写可以用 256K。创建 RAID 5 时初始同步时间明显比 RAID 1 长因为要计算校验数据。你可以用--assume-clean跳过初始同步但我自己只有在暂时没有重要数据、又想立刻投入测试的实验室环境才这么干生产环境请老老实实等同步结束。RAID 10 的创建命令是这样mdadm --create /dev/md0 --level10 --raid-devices4 /dev/sdb /dev/sdc /dev/sdd /dev/sdeRAID 10 不需要指定镜像配对mdadm 默认会自动安排布局。如果你有特殊要求可以用--layout参数控制。默认的布局对大多数场景都合适。RAID 10 在 RAID 10 世界里有一个非常好的特性它既借鉴了 RAID 0 的条带性能又保留了 RAID 1 的冗余是很多生产环境的首选。创建完成后不管哪个级别都要把阵列配置写入系统配置文件否则重启后系统无法自动识别。这也是新手最容易漏掉的一步。3.4 配置自动组装让阵列重启后还能找回来mdadm 的阵列信息默认只存在于磁盘的元数据里系统启动时需要有机制来扫描并组装这些阵列。这个机制依赖 /etc/mdadm.conf 配置文件。生成配置很简单mdadm --detail --scan /etc/mdadm.conf然后查看一下内容是否包含 ARRAY 行。更稳妥的做法是同时更新 initramfs让系统在引导阶段就能识别阵列update-initramfs -u不同的发行版命令略有差异CentOS/RHEL 系是dracut --forceDebian/Ubuntu 系是update-initramfs -u。别忘了执行完之后重启一次测试确认阵列能自动组装成 /dev/md0而不是变成 /dev/md127 这类自动命名设备。如果系统将阵列识别成 md127 而不是你期望的名字可以在 mdadm.conf 里给你的阵列固定一个 name或者用 UUID 关联配置。这是我在实际运维里至少见过十几次的问题早点处理能省很多事。4. 阵列日常管理与状态监控4.1 查看阵列状态的几个关键命令阵列建好后不可能一直不管。我日常最常看的三个命令是cat /proc/mdstat、mdadm --detail /dev/md0和smartctl。cat /proc/mdstat是最快的状态窗口几行信息就能看出阵列是否健康、当前是否在同步或者重建。如果看到[UU_U]这种带下划线的标记说明有一块盘掉线了需要立刻处理。下述这种输出就是典型的降级状态Personalities : [raid1] md0 : active raid1 sdc[1] sdb[0] 8381440 blocks super 1.2 [2/2] [UU]方括号里的 [UU] 表示两块盘都在线如果出现[U_]表示第二块盘有问题。这里要养成习惯看到 [U_] 不要慌也不要急着拔盘先看完整日志再决定操作。mdadm --detail /dev/md0会输出完整的阵列信息包括成员盘、设备角色、重建进度、块大小等。我最关心的是State: clean和Devices两行。如果 State 里出现 degraded就要准备找替换盘了。smartctl /dev/sdb -a用于查看物理盘的健康度。RAID 层正常不等于物理盘没有隐患SMART 里的 Reallocated_Sector_Ct、Current_Pending_Sector 这类指标能提前暴露坏道风险。我每周末跑一次全盘 SMART 巡检基本能避免完全没有预兆的故障。4.2 模拟一块盘故障降级、热备、重建光会创建不代表会用最好在正式环境之前演练一遍故障恢复流程。mdadm 支持手动模拟故障mdadm --fail /dev/md0 /dev/sdb执行后 /proc/mdstat 会显示[U_]或[_U]表明阵列进入降级模式。这时业务还可以继续跑但已经失去冗余保护需要尽快更换故障盘。先移除故障盘mdadm --remove /dev/md0 /dev/sdb然后插入新盘或者把之前备用的盘加进来mdadm --add /dev/md0 /dev/sde系统会自动开始重建重建进度可以这样观察watch cat /proc/mdstat重建期间阵列性能会有明显下降尤其是 RAID 5/6奇偶校验计算加同步 IO 会让整组盘都很忙。我的建议是非紧急情况下尽量选业务低峰期做换盘操作重建没完成之前不要再碰组里的其他盘。曾有同事在重建到一半时鲁莽地重启机器结果第二块盘也失去同步最终数据全部丢失这个教训实在深刻。4.3 在线扩容与 RAID 级别迁移mdadm 支持的另一个实用功能是在线扩容不必停机就能把更多盘加进现有阵列。比如一个 RAID 5 原本 3 块盘想扩容到 4 块盘mdadm --add /dev/md0 /dev/sde mdadm --grow /dev/md0 --raid-devices4扩容过程中mdadm 会重新布局所有数据这是一个比较耗时的重排过程期间阵列性能会下降但业务不用停。扩容完成后文件系统还要跟着扩展。ext4 用resize2fs /dev/md0XFS 用xfs_growfs /mnt/data否则你会发现阵列容量增加了文件系统仍然停留在原来的大小。RAID 级别迁移也是可行的比如从 RAID 1 迁移到 RAID 5但整套流程比扩容复杂得多而且每步操作中间阵列都处于脆弱状态。我建议如果不是特别必要别在生产环境做级别迁移。相比之下备份数据、重建新阵列、再导回数据这个方案虽然要停机但可控性高很多。4.4 定期巡检与性能观察阵列不是配好就能一劳永逸我习惯把巡检形成固定周报。巡检内容基本就是这三块阵列状态、物理盘健康度、性能基线。阵列状态检查包括看 /proc/mdstat 是否所有成员盘都在线mdadm --detail 输出的 State 是否为 clean以及是否有 background resync 在跑。物理盘健康度我上面说了用 smartctl 看 SMART 属性尤其关注坏道重映射和待处理扇区数这两个数值只要不是 0就要开始准备换盘了。性能基线比较有意思。我会在阵列刚建立、数据还不多的时候记录一组基础 IO 数据之后每个月跑一遍同样的测试做对比。用的工具是 fiofio --nameraidtest --rwrandrw --size2G --numjobs4 --runtime60 --group_reporting如果发现同样测试条件下延迟或吞吐下降超过 20%就有理由怀疑有盘开始出问题了即便 SMART 还没报错。这种提前量感在运维里往往比事后修复更值钱。5. 常见故障与排查实战5.1 重启后阵列识别不了这是我见过最多的问题之一。重启后lsblk里看不到 /dev/md0或者看到的设备名变成了 /dev/md127业务挂载失败。第一个排查点是 /etc/mdadm.conf 里是否有对应的 ARRAY 记录。如果没有用mdadm --detail --scan扫描当前磁盘上的元数据把输出追加到配置文件。第二个排查点是 initramfs 有没有更新很多发行版在修改 mdadm.conf 后必须重新生成 initramfs否则引导阶段内核压根找不到 RAID 设备。如果设备名变了还有一招手动指定名字组装。先停止自动命名的设备再用名字重新生成mdadm --stop /dev/md127 mdadm --assemble /dev/md0 /dev/sdb /dev/sdc这个操作要求你对阵列里的成员盘有把握别把别的盘加进来。组装前用mdadm --examine /dev/sdb检查盘上的元数据确认确实是同一组阵列的成员。5.2 阵列降级了怎么办阵列进入 degraded 状态后第一反应不应该是立刻--remove故障盘。正确的顺序是先搞清楚是哪块盘出问题以及是逻辑故障还是物理故障。mdadm --detail /dev/md0 dmesg | tail -n 20dmesg 里往往能看到 I/O error、ATA bus error 这类信息。如果只是偶发错误盘本身 SMART 还正常可以尝试把这块盘重新加回阵列重建一次再观察是否复发。如果 SMART 已经显示大量坏道或 pending sectors那就果断换盘。这里要特别强调降级状态持续越久风险越大。RAID 5 在降级状态下如果第二块盘再出问题整个阵列的数据就全完蛋了。如果手头有热备盘也就是创建阵列时通过--spare-devices1预留的空盘故障时阵列会自动用热备盘顶替不需要人工添加。这个功能对生产环境非常实用但前提是热备盘别设了太旧的型号免得重建速度跟不上。5.3 误操作把成员盘摘了还有一种常见情况来自操作失误本来想停掉某个 LVM结果误把 RAID 成员盘执行了mdadm --remove甚至直接拔了盘。这时候千万不要自动重建先停手分析。如果只是从阵列里 remove 了盘盘上的数据实际上没有立刻被覆盖用mdadm --examine还能看到元数据。可以试着重新添加回来触发重建或 re-addmdadm --re-add /dev/md0 /dev/sdb--re-add只适用于盘刚被移除、且数据没有大变动的场景。如果移除后已经很长时间没有写入re-add 成功概率很高。如果阵列已经用其他盘重建过了那旧盘加回来反而会造成问题别再折腾它了数据恢复只能靠备份。拔盘比 remove 还要复杂一些因为盘上元数据可能还标记为故障或 missing。这种情况我会先mdadm --stop /dev/md0再mdadm --assemble --scan让系统重新识别幸运的话能自动恢复位置。这种操作属于经验运气并存没有万全的招所以日常一定把 mdadm.conf 和阵列成员列表备份好越详细越好。5.4 故障排查速查表为了让你在实际出问题时能快速定位我整理了一张速查表现象可能原因先执行的命令下一步/proc/mdstat 显示 [U_]某成员盘故障或掉线mdadm --detail /dev/md0检查 dmesg、SMART确认是否换盘重启后没有 /dev/md0mdadm.conf 缺失或 initramfs 未更新mdadm --examine /dev/sd*重新生成配置并更新 initramfs重建速度极慢盘性能差或阵列被业务持续占用cat /proc/mdstat调整重建优先级--write-behind或错峰重试挂载时报设备不存在设备名变了或被 stop 了lsblk; mdadm --assemble --scan检查 fstab 是否用了 UUID 挂载写性能骤降RAID 5/6 正在同步或校验出错mdadm --detail /dev/md0等待同步完成排查是否有盘降速这块表我贴过几次很多人照着做就能救回阵列。说到底RAID 故障不可怕可怕的是不知道当前阵列处于什么状态、下一步该干嘛。把基础的几招练熟练大多数问题都能在半小时内解决。6. 几个过来人才懂的坑与心得6.1 别在阵列里混用盘型SSD 和 HDD 混组 RAID 是我见过最不合理的做法之一。SSD 和 HDD 的 IO 能力差距太大组进同一个 RAID 5 后整个阵列会被慢速盘拖后腿而且重建时因为两边速度差太多很容易出现同步超时。同类盘混用不同容量也不行我的原则就是一个阵列只用一批产品、同一型号、同一容量。如果确实需要速度容量兼顾不如用两层方案上层用 SSD 做缓存池或者 LVM 缓存下层用 HDD 做 RAID 6。这个方法代价高一些但远比混组一个怪阵列更稳。仓库里做大规模存储的同事都深有体会混盘一时爽重建火葬场。6.2 RAID 不是备份这套话我逢人就想说之前也提过但这里值得再展开一点。RAID 1 可以在坏一块盘时继续跑RAID 6 可以坏两块盘但如果是数据库结构被误删、文件被加密勒索、机房断电导致文件系统损坏RAID 本身一点都救不了你。我自己的服务器上始终保留一份异地备份RAID 阵列只是第一道防线备份才是最终兜底。再补一句RAID 1 上做同步备份时磁盘故障和误删除可以同时带崩生产数据和最近的备份副本所以备份至少保持多版本起码留几天的历史快照。这些话虽然老生常谈但每次 RAID 事故复盘时最后都会落回到备份问题。6.3 定期做一次恢复演练我见过不少团队RAID 阵列配得漂漂亮亮监控告警一应俱全但从没实际演练过盘坏了一块的完整恢复流程。等到真出了事故第一反应往往是查文档、问群里人怎么修宝贵的恢复时间就这样白白浪费掉了。每个月抽一个小时在测试机或者虚拟机里模拟一次故障盘替换、阵列重新组装成本极低收益极高。如果你愿意还可以把演练记录整理成文档下次团队接手时直接照着跑。因为 mdadm 的操作相对直观只要你熟悉了这套流程生产环境真出事的时候你就有底气说我先换盘阵列降级顶住而不是慌慌张张拔电源。我在实际运维中体会最深的一点是RAID 方案本身已经非常成熟真正的风险往往来自人的疏忽和操作不当。每次动手前多确认一遍盘符每次重建前先看准状态每次换盘后仔细确认同步完成这些看似琐碎的好习惯才是让存储系统长期稳定运行的关键。