ARTICLE DETAIL

资讯详情

深耕商务建站与企业官网运营的一线实战洞察。

RAID原理、选型与故障处理:从条带化、镜像、校验到RAID 5/6/10实战

RAID原理、选型与故障处理:从条带化、镜像、校验到RAID 5/6/10实战 RAID 这个词大多数人第一次见到是在装机店的配置单上第二次见到是在机房的告警邮件里。它的中文名叫独立磁盘冗余阵列核心思路说白了就一句话把几块普通硬盘用条带化、镜像、校验这三种基本手法组合起来对外呈现成一个容量更大、读写更快、或者更不容易因为单块盘损坏而丢数据的逻辑盘。这套东西从服务器机房一路渗透到家用 NAS、监控录像机、剪辑工作站几乎只要涉及多块盘的场景就绕不开它。但真正把 RAID 用明白的人并不多我见过太多把 RAID 当成备份的、把 RAID 5 堆到十几块大容量盘还觉得稳的、重建到一半第二块盘亮红灯的。这篇就把 RAID 从原理到选型、从建阵列到故障处理完整捋一遍不管你是刚接触存储的新手还是天天跟阵列卡打交道的老兵应该都能捞到点东西。1. 先把话说清楚RAID 到底在解决什么问题1.1 单块硬盘的三道坎一块硬盘的能力是有物理天花板的而且这三道坎互相打架。第一是容量单盘再大也有上限而且盘越大单价往往越不划算第二是性能机械盘受限于主轴转速和磁头寻道随机 IOPS 长期卡在一两百这个量级顺序读写也就两三百 MB/sSATA 接口的固态盘虽然能跑到五百多但接口带宽和主控通道数一样有顶第三是可靠性任何一块盘都有故障率厂商标称的 MTBF 动辄上百万小时可那是统计意义上的平均值落到你手里那块盘上明天坏和五年后坏都是有可能的。更麻烦的是这三者往往不能同时满足——想要大容量就得接受更多盘片和更长寻道想要高性能就得付出更高成本。RAID 的出发点就是用多块盘协同这个手段把这三道坎分别往上顶一顶。1.2 RAID 的能力边界它能救什么救不了什么很多人对 RAID 的期待过高这是所有事故的起点。RAID 真正能救的只有一类问题磁盘介质的物理性故障。盘片划伤、磁头卡死、电路板烧了、固件挂了这类故障只要冗余还在阵列就能继续对外提供服务你换块盘插回去重建就行。但 RAID 救不了的东西同样一长串误删文件、格式化错分区、勒索软件加密、文件系统元数据损坏、操作系统层面的逻辑错误、机箱进水、电源浪涌把整机带走、阵列卡或背板故障、机箱被盗。这些场景下RAID 的镜像和校验会非常忠实地把错误数据同步到每一块盘上。所以行业里有句被说烂了但依然有人不信的话RAID 不是备份。备份要求的是时间维度上的多份副本和离线隔离RAID 给的是同一时刻的空间维度冗余两者根本不是一回事。1.3 几个必须先纠正的认知第一个误区是盘越多越安全。实际情况恰恰相反阵列里的盘越多单盘故障的概率叠加就越高重建时要读取的数据量也越大重建窗口越长二次故障的窗口也就越长。一个 24 盘的 RAID 5年故障概率远高于 4 盘 RAID 5。第二个误区是RAID 0 不算 RAID。它确实没有冗余但它是最纯粹的条带化实现在临时缓存、渲染中间文件、只读镜像分发这类数据可重建的场景里RAID 0 的性价比高得离谱。第三个误区是阵列卡上的缓存越大越好。写缓存只有在有电池或超级电容保护的前提下开 Write Back 才是安全的没有掉电保护的写缓存一次意外断电就足以让整个文件系统报废。这几点在后面的章节里还会反复提到先把地基打牢。2. 三块积木条带、镜像、校验2.1 条带化把 IO 切碎了并行发出去所有 RAID 级别的地基都是条带化。做法是把每一块成员盘按固定大小切成一段一段这个固定大小叫chunk或者 strip常见取值 64KB、128KB、256KB、1MB。然后数据按顺序轮流写到各块盘上第 1 个 chunk 写盘 A第 2 个写盘 B第 3 个写盘 C写满一圈再回到 A。于是一个大文件的顺序读取就变成了 N 块盘同时往外吐数据聚合带宽接近单盘带宽乘以盘数这是 RAID 0 和所有带级别的性能来源。这里有个容易混淆的概念chunk 是单块盘上的一段stripe是一次并行写满所有数据盘的总量等于 chunk 乘以数据盘数量。比如 6 块盘的 RAID 5数据盘 5 块chunk 64KB那么一个 stripe 是 320KB。这个数字很关键后面讲文件系统对齐和条带大小选择时都要用到它。条带大小选错性能会明显打折。基本原则是看你的 IO 特征如果业务以大文件顺序读写为主比如视频素材、备份归档、日志落盘块可以给大一点256KB 到 1MB 都行这样单次 IO 能覆盖多个数据盘带宽拉满如果是数据库、虚拟化这类以小 IO 随机读写为主的负载块要小一些64KB 甚至 32KB避免一次 8KB 的随机读反而触发了跨盘寻道。这里有个反直觉的点条带太小也不好同样大小的顺序读会被拆成更多次跨盘访问每次都要等所有盘响应延迟反而上升。我个人的经验起点是数据库类 64KB、文件服务器 128KB、媒体素材库 256KB 到 512KB然后拿真实业务压测再微调。2.2 镜像最暴力也最可靠的冗余镜像的逻辑简单到不需要解释同一份数据同时写到两块盘上读的时候从任意一块读都行。RAID 1 就是两块盘互为镜像RAID 10 是先把盘两两配对做镜像再把多组镜像条带化拼起来。镜像的好处非常实在写的时候要写两份写放大是 2 倍但读的时候可以两块盘并行读不同的请求随机读性能接近翻倍重建的时候只需要从存活的那块盘完整拷一份数据过去重建速度快而且重建过程中另一块盘的状态是明确的不存在校验计算失败的问题。代价是容量利用率只有 50%四块 8TB 盘做 RAID 10 只有 16TB 可用这是硬成本。所以 RAID 10 一般用在两个地方一是写密集且对延迟敏感的业务二是盘位和预算都还算宽裕但数据非常重要的场景。镜像还有个容易被忽视的细节它防不住逻辑性损坏的同步。如果文件系统写入了错误数据或者某块盘固件有 bug 返回了脏数据镜像会把这个错误原样写到两块盘上你读到的是两份一致的错误。这一点决定了镜像只能解决介质故障不能解决数据正确性问题。真正要防静默损坏靠的是上层文件系统的校验和与定期 scrub而不是 RAID 级别本身。2.3 校验拿 CPU 换容量代价是写惩罚校验的思路是不存完整副本只存一份由所有数据块异或运算得出的校验块任何一块数据丢了用剩下的数据块和校验块异或回去就能恢复。RAID 5 用一份校验允许坏一块盘RAID 6 用两份独立的校验通常是异或加伽罗瓦域运算允许坏两块盘。容量利用率因此大幅提升RAID 5 是 (N-1)/NRAID 6 是 (N-2)/N六块盘的情况下分别是 83% 和 67%比镜像的 50% 好看太多。但校验的代价藏在写操作里这就是所谓的写惩罚。一次随机小块写RAID 5 需要先读出旧数据块、读出旧校验块算出新校验再写回新数据块和新校验块一共 4 次磁盘 IO 才算完成一次逻辑写。RAID 6 更狠要读旧数据、读两个旧校验写新数据、写两个新校验6 次 IO。RAID 10 只写两份2 次 IO。把这个换算成可用写 IOPS公式就很清楚了假设单盘随机写能力 100 IOPS8 块盘的 RAID 5 有 7 块数据盘写 IOPS 大约是 7×100/4 175同样 8 块盘的 RAID 10 是 8×100/2 400。差了将近一倍多。这就是为什么数据库这类写密集业务很多时候宁愿牺牲容量也要上 RAID 10。2.4 热备盘与重建冗余真正兑现的时刻冗余在平时是没有存在感的只有一块盘挂掉、阵列进入降级状态的那一刻它才真正开始工作。这时候如果有热备盘阵列卡或软件会自动把热备盘拉进来顶替故障盘开始重建。热备盘分两种全局热备可以被任意阵列征用专用热备只服务指定的那个阵列。盘位紧张的时候用专用热备更省但灵活性差盘位宽裕就用全局热备利用率高。重建的过程本质上是把缺失的数据重新算出来写到新盘上。镜像类重建是直接拷贝速度取决于源盘的顺序读能力校验类重建要读取同 stripe 内所有其他数据盘和校验盘一边读一边算对整组盘都是满负荷冲击这段时间阵列性能会明显下降业务侧能感觉到延迟抖动。重建时间跟单盘容量强相关粗略估算一下一块 8TB 的盘实际重建速率受限于单盘顺序读和阵列卡处理能力按有效 80MB/s 算8,000,000MB ÷ 80MB/s ≈ 100,000 秒差不多 28 小时。这还只是理想情况业务压力大、盘本身有坏道、重建优先级被限制拖到两三天都很正常。这 28 小时就是你的风险窗口窗口期内再坏一块盘RAID 5 直接归零。所以重建速率限制这个参数要慎用它能保护业务性能但也实实在在地延长了危险期。3. 各 RAID 级别逐个拆容量、性能与适用边界3.1 RAID 0 与 RAID 1两个极端RAID 0 是纯条带容量利用率 100%读写性能随盘数线性提升但没有任何冗余任何一块盘挂了整个阵列的数据全部不可读。它的合理使用场景非常明确数据本身可以从别处重新生成或者重新下载且对性能极度渴求。比如视频剪辑的代理文件缓存、渲染农场的临时输出目录、只读镜像的分发节点。反过来说只要这份数据丢了你会心疼就别用 RAID 0。RAID 1 是纯镜像最少两块盘容量利用率 50%读性能接近翻倍写性能基本等于单盘重建速度最快配置最简单。它最适合小规模、高价值的场景系统盘、数据库日志盘、小型办公文件服务器。两块大容量盘做 RAID 1 现在很常见因为单盘容量上去了两块盘就能凑出够用的空间而且重建窗口短、风险低。唯一要接受的就是那一半的容量损失。3.2 RAID 5性价比之王也是踩坑最多的地方RAID 5 是最广为人知的级别也是被误用最严重的级别。它的账面上确实漂亮最少三块盘容量损失一块读性能接近条带写性能受写惩罚影响但还能接受。在机械盘容量还停留在几百 GB 到 1TB 的年代RAID 5 几乎是默认选项因为重建一块 500GB 的盘只要一两个小时风险窗口很短。问题出在盘容量暴涨之后。一块 8TB 甚至 16TB 的盘重建动辄二三十小时而重建过程中需要读取整个阵列的所有扇区。这里有个绕不开的物理现实大容量机械盘在长时间满负荷读取时遇到不可恢复读错误的概率不再是理论值而是实实在在会发生的事。一旦重建过程中某块盘报出读错误RAID 5 没有第二份校验可以兜底重建直接失败整个阵列的数据就废了。所以现在的通行做法是单盘容量超过 4TB 的阵列基本不推荐 RAID 5要么上 RAID 6要么上 RAID 10。如果非要用 RAID 5成员盘数量控制在 4 到 6 块别堆到十几块。3.3 RAID 6 与 RAID 10大容量盘的现实选择RAID 6 用两份校验换来同时坏两块盘还能活的能力最少四块盘。它的价值不只是多一层保险更重要的是重建期间的安全性RAID 5 重建时只要再来一块盘出问题就完了RAID 6 重建时还有一份冗余顶着而且第二份校验能帮助定位到底是哪一块盘读错了RAID 5 只能发现这组数据错了却不知道是谁错的。代价是写惩罚更重6 次 IO写性能比 RAID 5 再降一截容量利用率也更低。对于近线存储、备份归档、监控录像、大容量 NAS 这类写入不小但延迟不敏感的场景RAID 6 是非常合适的平衡点。RAID 10 走的是另一条路用容量换性能和恢复速度。它最少四块盘容量利用率 50%读性能接近条带写性能是 RAID 5 的两倍多重建速度快、重建期间对同组盘的压力小。对于数据库、虚拟化宿主机、任何写密集且延迟敏感的业务RAID 10 通常是首选。我见过不少团队在数据库服务器上纠结 RAID 5 和 RAID 10 的容量差最后因为一次重建超时把整个库搞挂之后再也没碰过 RAID 5。3.4 RAID 50/60组合级别的适用场景RAID 50 是多个 RAID 5 子组再条带化RAID 60 是多个 RAID 6 子组再条带化。它们的意义在于降低单个子组的盘数从而缩短重建时间和重建影响范围。举个例子12 块盘如果直接做 RAID 6成员盘太多重建时要读 11 块盘拆成两个 6 盘 RAID 6 子组再做条带每个子组只有 6 块成员盘重建只影响这个子组速度和风险都更可控。代价是每个子组都要损失自己的校验盘容量利用率进一步下降而且故障域变成了每个子组各能坏 N 块不是全局的。这类组合级别适合盘位多、容量大、又不想上 RAID 10 的中大型存储池小规模场景没必要折腾。3.5 一张对照表和几个必须会算的数级别最少盘数可用容量容错盘数随机写惩罚典型场景RAID 02N×C01临时数据、可重建缓存RAID 12C1或 N-12系统盘、小规模高价值数据RAID 53(N-1)×C14读多写少、盘数少、小容量RAID 64(N-2)×C26大容量存储、备份、归档RAID 104(N/2)×C每组 12数据库、虚拟化、写密集RAID 506(N-子组数)×C每子组 14中等规模存储池RAID 608(N-2×子组数)×C每子组 26大规模存储池容量算法很直白但要留意厂商标称容量的十进制陷阱8TB 的盘在操作系统里看到大约是 7.28TiB六个 8TB 盘做 RAID 5可用容量是 5×8TB40TB 标称系统里显示大约 36.4TiB再扣掉文件系统元数据实际能用的还要少一点。做容量规划时按系统显示的数值算别按包装盒上的数字算。再算一个 IOPS 的账。假设 8 块万转机械盘单盘随机写 130 IOPS做 RAID 6数据盘 6 块写 IOPS ≈ 6×130/6 130几乎和单盘持平同样的盘做 RAID 10写 IOPS ≈ 8×130/2 520是 RAID 6 的四倍。这就是为什么 OLTP 数据库基本不考虑 RAID 6。如果换成固态盘单盘 IOPS 上万写惩罚带来的绝对差值会被放大但固态盘本身没有寻道开销写惩罚的影响方式又不一样这块后面单独说。4. 落地从选型到建阵列的完整操作4.1 硬件 RAID、软件 RAID还是干脆不用硬件 RAID 依赖独立的阵列卡卡上有自己的处理器和缓存操作系统看到的是一块逻辑盘跟底层细节完全解耦。优点是管理简单、性能稳定、有掉电保护的写缓存、热插拔和重建都是卡自己完成的跟操作系统无关。缺点是卡本身是单点卡挂了你得找同型号的卡来导配置跨品牌迁移基本别想而且卡上缓存没有后备电池或超级电容时千万别开 Write Back。软件 RAID 把活交给操作系统Linux 下的 mdadm、各类支持校验和的文件系统、Windows 的存储空间都属于这一类。优点是配置透明、不依赖特定硬件、迁移方便、阵列元数据跟着盘走出问题能在另一台机器上直接组装起来。缺点是要吃 CPU重建时对系统负载有影响而且没有硬件缓存写性能在某些场景下不如硬件方案。对于预算有限、盘位不多、或者用通用服务器搭存储的场景软件 RAID 完全够用我个人的很多环境就是 mdadm 加一层文件系统校验稳定跑好几年。还有第三种选择不用 RAID。现在云主机、对象存储、分布式存储系统在底层已经做了多副本或纠删码你在单机上再做一层 RAID 5 属于重复建设反而增加了故障点。单机场景如果数据量不大、恢复时间要求不高直接用单盘加备份比搭一个半吊子的 RAID 更实在。4.2 建阵列前必须敲定的几个参数条带大小按前面的原则选数据库 64KB文件服务 128KB媒体 256KB 到 512KB。写策略在有电池或超级电容保护的前提下开 Write Back没有就老老实实 Write Through别为了跑分好看去赌断电。初始化方式分快速初始化和完全初始化快速初始化只写元数据几秒钟完成但后台会慢慢补齐校验这段时间阵列性能是抖的完全初始化会把所有扇区写一遍耗时可能十几个小时但完成后阵列状态是干净的我一般建议新阵列在不赶时间的情况下走完全初始化。文件系统对齐是很多人忽略的一步。如果文件系统的块大小和 RAID 的条带没对齐一次逻辑写会跨越两个物理 stripe触发读改写性能直接腰斩。用 ext4 的话mkfs.ext4时把stride设成 chunk 除以文件系统块大小stripe-width设成 stride 乘以数据盘数。举例chunk 64KB文件系统块 4KB那么 stride 166 盘 RAID 5 数据盘 5 块stripe-width 80。XFS 用的是su条带单元和sw条带宽度单位是块数逻辑一样。固态盘做 RAID 还有个额外的坑要确认 TRIM/DISCARD 能不能透传很多硬件阵列卡是不支持的长期跑下去写放大和寿命都会受影响。下面这套参数是我按常见业务负载总结的起点不是标准答案落到你的环境还得靠实测微调。# 六块盘做 RAID 6条带 64KB带内部写意图位图 mdadm --create /dev/md0 --level6 --raid-devices6 \ --chunk64K --bitmapinternal /dev/sd[b-g] # 查看组装状态和重建进度 cat /proc/mdstat mdadm --detail /dev/md0 # 文件系统按条带对齐chunk 64K / 块 4K stride 16数据盘 4 块 mkfs.ext4 -E stride16,stripe_width64 /dev/md0那个--bitmapinternal是软件 RAID 的一个实用开关。没有位图的时候一次非正常关机后重启阵列要做全量一致性校验才能上线8TB 级别的阵列可能卡几个小时有了位图只重扫脏区域几十秒就能恢复服务。代价是写路径上多一点点开销但在大多数场景下这个交换非常划算。4.3 初始化完成之后要做的三件事第一件是记录配置。把mdadm --detail的输出、阵列卡的配置导出、每块盘的序列号和槽位对应关系全部存一份到别的地方。真出事的时候你会无比庆幸自己有这份记录——尤其是硬件阵列卡坏了要换卡导入配置的时候槽位顺序错一位数据就可能对不上。第二件是建立监控。至少要盯四个指标阵列健康状态、单盘 SMART 里的重映射扇区数和待定扇区数、文件系统使用率、重建/校验任务的进度。SMART 里的Reallocated_Sector_Ct和Current_Pending_Sector只要开始非零增长就说明这块盘在走下坡路别等到它被阵列踢出去才动手。监控采样频率别太高机械盘的 SMART 查询本身有开销一天一次足够但阵列状态要频繁一点。第三件是设定巡检周期。带校验的阵列要定期做一致性校验也叫巡检读把整组盘的所有扇区读一遍发现读错误就尝试用校验修复。频率一般一个月一次放在业务低峰期并且一定要给校验任务限速否则它会把整个阵列的 IO 吃满。# 手动触发一次一致性校验 echo check /sys/block/md0/md/sync_action # 限制后台校验速率避免打满业务 IO单位 KB/s echo 50000 /sys/block/md0/md/sync_speed_max # 查看当前校验进度 cat /sys/block/md0/md/sync_completed4.4 坏盘替换的标准动作发现降级之后第一反应不应该是拔盘而是先确认是哪块盘真的坏了。看阵列状态定位到具体槽位再去看这块盘的 SMART 和内核日志。如果只是超时被踢、SMART 全绿、日志里全是链路层错误CRC 错误、复位、超时那大概率是线缆、背板或者接口接触问题换盘没用换线或者换个槽位可能就好了。这种情况我遇到过不止一次急着换盘反而把好好的盘换走了问题依旧。确认是盘的问题后热插拔换上新盘然后把它加回阵列。软件 RAID 的操作是这样# 先把故障盘标记为移除 mdadm /dev/md0 --fail /dev/sdc --remove /dev/sdc # 插入新盘后加入阵列开始重建 mdadm /dev/md0 --add /dev/sdc # 重建期间盯着进度 watch -n 60 cat /proc/mdstat重建期间要控制业务压力别在这时候跑大批量备份或者全表扫描。如果阵列支持重建速率限制把它调低一点用时间换安全。重建完成后一定要再做一次一致性校验确认新盘上的数据算出来是对的。5. 故障现场降级、掉盘、重建失败怎么处理5.1 掉盘先别急着换盘前面提过一次这里展开说因为这是最高频的误判。一块盘从阵列里掉出去原因至少有四类盘本身介质故障、盘固件 bug 导致超时、链路问题线缆、背板、接口氧化、控制器或驱动问题。这四类里只有第一类需要换盘。判断方法很朴素看 SMART 属性里重映射扇区和待定扇区有没有增长看内核日志里是介质错误还是超时/复位/CRC 错误。介质错误的盘必须换链路错误的盘换上去大概率还会再掉。还有一个隐蔽的情况整组盘同时掉。这基本可以排除介质故障往供电、背板、阵列卡、驱动方向查。我见过因为机箱电源老化导致瞬态掉压几块盘同时被复位阵列直接崩掉。这种时候千万别急着逐块盘重建先把硬件问题解决否则重建一百次也会再崩。5.2 重建失败的常见原因链重建失败最典型的场景是 RAID 5 重建过程中遇到不可恢复读错误。表现形式是重建进度卡住日志里出现读取失败然后阵列要么把另一块盘也标记为故障整个阵列失效要么重建中断。这种情况下如果数据重要不要再对阵列做任何写操作先做全盘镜像再说找专业数据恢复也比自己反复尝试强。第二个常见原因是用了 SMR 盘。叠瓦式磁记录盘在持续写入时性能会断崖式下跌重建过程中写入速度跟不上阵列卡判定超时直接把新盘踢掉重建反复失败。这类盘价格便宜、容量大很容易被误买来做 NAS唯一的辨别方式是查厂商规格书里的记录技术。做 RAID 慎用 SMR尤其是校验类阵列。第三个原因是重建期间业务压力过大阵列卡的处理能力被占满重建任务被饿死或者超时。对策是限速加错峰把重建优先级调低让它慢慢跑别追求速度。5.3 性能不达预期的排查顺序按这个顺序查能覆盖八成问题。先看条带对齐文件系统块和 RAID 条带没对齐是最常见的性能杀手表现为小 IO 延迟明显高于预期。再看写缓存策略Write Through 和 Write Back 的写性能差好几倍如果最近改过配置或者电池失效自动降级到 Write Through性能会突然掉下来。第三看是否有后台任务在跑一致性校验、重建、快照清理都会抢 IO。第四看单盘是否已经有坏道坏道会触发重试一次重试几十毫秒到几秒足以把整体延迟拉爆。最后才去看阵列卡固件、驱动版本、队列深度这些更底层的东西。固态盘做 RAID 还要额外看两个点TRIM 是否透传以及阵列卡是否支持直通模式。很多阵列卡会把固态盘当成机械盘处理队列深度受限性能跑不满有条件的话用直通卡加软件 RAID反而更容易发挥固态盘的性能。5.4 常见问题速查表现象最可能的原因处理方向单盘掉线SMART 重映射增长介质老化换盘尽快重建单盘掉线日志大量 CRC/复位线缆、背板、接触换线换槽先别换盘多盘同时掉线供电、背板、控制器查硬件勿盲目重建重建卡在某个百分比源盘有坏道或新盘 SMR停业务、降速、评估数据抢救写性能突然腰斩缓存降级为 Write Through检查电池/电容状态小 IO 延迟高文件系统未条带对齐重建文件系统并设 stride容量比预期少保留空间、热备、十进制换算核对阵列与文件系统配置校验任务跑不完限速过低或盘有坏道看日志评估换盘5.5 几条用血换来的经验第一条新盘上手先做全盘写测试。买回来的盘尤其是批次相同的盘先跑一遍全盘写入加读取校验把早期失效的盘筛掉。同批次盘同时采购、同时上机故障时间也会趋同这是 RAID 最怕的同批次雪崩。有条件的话分批采购或者混用不同批次。第二条RAID 5 的盘数上限比容量上限更重要。我给自己定的线是单盘超过 4TB 不用 RAID 5成员盘超过 6 块不用 RAID 5两个条件满足任意一个就换 RAID 6 或 RAID 10。这条线不是拍脑袋是重建时间、读错误概率、二次故障窗口三个因素叠加出来的。第三条冗余和备份要分开设计。阵列负责盘坏了业务不停备份负责数据错了还能回去。这两件事的介质、位置、周期都要独立别把备份放在同一个阵列里也别用快照代替备份——快照和源数据在同一个存储上存储挂了就一起没了。第四条改配置之前先备份元数据。硬件阵列导出配置软件阵列保存mdadm --detail和mdadm --examine的输出文件系统的 UUID 和挂载参数也记下来。这些东西平时没用出事的时候能省下几十个小时。第五条定期做恢复演练。不是验证备份文件存在就算完要真的从备份里恢复一份数据到测试环境跑一遍完整性校验。我见过备份任务天天成功、真要用的时候发现备份的是空目录的情况。RAID 阵列也一样定期拔一块盘模拟降级、观察告警是否触发、重建流程是否顺畅这套动作做熟了真出事的时候才不会手忙脚乱。最后分享一个我一直在用的小习惯给每个阵列建一个纯文本的档案卡写清楚建阵列的日期、成员盘的型号序列号槽位、条带大小、文件系统参数、热备盘分配、巡检周期、上次校验时间。放在监控系统之外的地方比如运维文档或者打印机旁边贴一张。这东西看着土但在凌晨三点排查故障的时候它比任何花哨的监控面板都管用。
返回列表
PREV
查看更多资讯
NEXT
返回资讯列表