硬盘 SMART 显示正常第二天就挂了：该盯的是哪几个数的变化速率

某块盘 SMART 自检结果一直是 PASSED，第二天早上直接掉线，数据靠备份捞回来——这种事干运维的迟早会碰上一次。碰过之后你会发现一个很别扭的事实：这项自检本来就不是为了预判故障设计的。它回答的是"这块盘现在有没有越过厂商设定的那条线"，而不是"这块盘还能撑多久"。这两个问题看着像一回事，其实差了十万八千里。

所以这篇不打算给你背一遍 SMART 的参数表，那种东西手册上都有。我们聊的是三件事：磁盘到底能不能提前预判故障、该盯哪些数的变化速率、以及阵列卡的掉电保护失效之后会发生什么。

• "健康"两个字基本没有预判价值。阈值是厂商自己定的，普遍宽松；而且相当比例的故障是突发的，前一天看不出任何征兆。
• 真正有预警价值的是四个数的变化速率：05 重映射扇区计数、C5 当前待映射扇区数、C6 无法校正的扇区计数、以及接口 CRC 错误计数。
• 从 0 到 1 是事件，从 1 往上爬才是趋势。总共 20 个重映射半年没动，和一天之内从 0 涨到 20，是完全两种处置。
• CRC 涨上去别急着换盘。它通常指向线缆、背板、控制器这一层，换块新盘上去照样涨。
• 阵列卡失去掉电保护会静默降级。WriteBack 自动退回 WriteThrough，不报警，监控上只表现为"业务突然变慢"，很多人误判成磁盘坏了。

自检结果一直 PASSED 的盘，第二天早上掉了

先把这个场景拆开看。一块在企业级硬盘里跑了三四年的盘，每周巡检一次，smartctl 跑完整自检，结果一直是 PASSED，各属性的当前值离阈值还有一大截。某个周一早上，监控系统报阵列降级，那块盘已经不在了。事后把盘拔下来单独测，连识别都费劲。

这种事的恶心之处在于，你没法说"巡检没做"。巡检做了，而且做得很规矩。问题出在巡检看的那个指标本身就不管用。

往深一层说，机械硬盘的失效模式大致分两类。一类是渐进式的：盘片上的某些区域磁性慢慢衰减，读的时候信号质量变差，需要多次重试才能读出来，最后彻底读不出来，触发重映射。这类失效有过程，SMART 里能看出轨迹。另一类是突发式的：主轴电机、磁头驱动臂、控制电路、固件逻辑出问题，盘可能上一秒还好好的，下一秒就不响应了。这类失效没有过程，任何基于"当前状态"的检测手段都抓不到。

行业里公开的规模性统计（多家云厂商和硬盘厂商发布过）反复提到一个反直觉的结论：在不少数据集里，重映射扇区数、待映射扇区数这些被公认有用的属性，在故障盘样本中的"异常命中率"并不高，大量故障盘直到最后一刻这些属性还是零。这直接说明了两件事——一是渐进式失效只占一部分，二是想靠 SMART 单独撑起预测，本身就不现实。

那是不是说这套自检一无是处？也不是。它在两件事上很有用：一是确认盘还活着、还能正常通信、接口没掉；二是提供一条时间序列，让你有机会看到渐进式失效的轨迹。只是别把"PASSED"当成"这块盘没问题"，它顶多算"这块盘到目前为止没越过厂商那条很松的线"。

顺带说一句容易被忽略的：SMART 只能看到硬盘自己上报的东西。盘片之上还有线缆、背板、阵列卡、驱动、文件系统这一整条链路。链路里任何一环出问题，硬盘自己是不知道的，它会老老实实报"我很健康"。这就是为什么有些"磁盘故障"换了三块盘还在复现。

这项自检的设计目标本来就不是预测故障

SMART 这套机制最初的用途是"自检与报告"，出发点是给盘一个自我描述的能力：我通电多久了、我经历过几次异常断电、我有多少扇区被替换过、我现在的温度是多少。它是一份体检报告，不是一张天气预报。

报告里的每个属性都有三个值：当前值（归一化后的相对健康度）、最差值（历史最差）、以及阈值（厂商设定的临界线）。自检结论看的是"当前值有没有低于阈值"，只要没低于，就是 PASSED。这里有两个坑。

第一个坑，阈值是厂商自己定的，而且定得相当宽松。厂商的动机可以理解：阈值定紧了，返修率上升，成本受不了；定松了，盘用到过保再坏，大家都体面。所以你会看到有些盘重映射了几百个扇区，自检结论依然是 PASSED。从厂商的判定逻辑看这没错——盘还能用，还没到不能用的地步。但从一个跑数据库的运维视角看，这块盘已经是定时炸弹了。

第二个坑，也是最根本的那个：阈值判定是"当前状态"的判定，它不包含任何时间维度。它不会告诉你这个数是昨天才涨上来的还是三年前就涨上来了。而恰恰是这个时间维度，才是区分"可以放着"和"马上换"的关键。

还有一层局限更隐蔽。SMART 的属性是盘自己的固件在维护的，固件本身出问题、或者盘的控制器已经无法正常响应主机，这些属性就根本读不出来。换句话说，越是临近彻底失效的盘，你越有可能读不到它的数据。

所以正确的姿势是：把 SMART 当成一条需要长期采集的时间序列，而不是一个每次巡检看一眼的是/否开关。开关只有两个状态，信息量太低；序列才有斜率，斜率才是预警信号。

真正有预警价值的是四个数的变化速率

先把物理过程讲清楚，不然看数字就是背口诀。

机械硬盘读一个扇区，本质是磁头扫过盘片上的一段磁性区域，把模拟信号解码成数字。如果这段区域磁性衰减了，或者被污染了、被轻微划伤了，读出来的信号质量会变差。轻的时候，盘靠纠错码（ECC）就能把原始数据还原出来，主机完全无感，只是这次读取花的时间长一点。再差一点，一次读不出来，盘的固件会重试，换读取参数、偏移磁头位置，多试几次。

如果重试若干次之后成功了，固件会做一个判断：这个扇区不可靠了，把它的数据搬到预留的备用区，以后访问这个逻辑地址就走备用区。这就是重映射，对应属性 05 重映射扇区计数（Reallocated_Sector_Ct），计数加一。

如果重试之后还是读不出来，这次读取就失败了。这时固件不会立刻重映射——万一这个扇区其实还有救、只是这次运气不好呢？它会先把这个扇区标记为"待映射"，挂在那儿等下一次有人来访问它再复验。这就是待映射，对应 C5 当前待映射扇区数（Current_Pending_Sector_Ct）。下次访问如果读成功了，扇区被重映射，C5 减一、05 加一；如果确认读不出来，就计入 C6 无法校正的扇区计数（Offline_Uncorrectable / Reported_Uncorrectable），C5 减一。

C6 是最糟糕的那个。它意味着主机要的数据，盘拿不出来。如果这个扇区上放的是普通文件，表现为读文件报错；如果放的是数据库页或者文件系统元数据，可能直接导致数据库崩溃、文件系统只读。很多"突然掉盘"的前一晚，其实 C6 已经悄悄涨了。

理解了这条链路，判读逻辑就很自然了：05 是已经发生的事，C5 是正在悬着的事，C6 是已经出结果的事。C5 和 C6 只要不为 0，就说明盘上存在确认读不出来的区域，这比 05 大得多要严重。

至于变化速率怎么判，说白了就一句话：看斜率，不看绝对值。总共 20 个重映射扇区、半年没变，通常可以先观察，那多半是出厂早期或者某次异常断电留下的一次性损伤；一天之内从 0 涨到 20，马上准备换盘，这说明盘的磁性介质或磁头正在持续劣化，而且是加速的。

采样节奏上，给一个够用的思路：关键业务机器的 SMART 属性，至少每天采集一次并存进时序库，不要只在人去巡检的时候才看一眼。数据库、日志、备份这类写密集的单机，可以做到每几小时一次。看的时候别只看当天的值，拉出最近 30 天的曲线，看有没有台阶。判动手的口径，我会用"连续三次采样上升"这个标准——一次上升可能是噪声或者单次偶发，连续三次上升就是趋势了，这时候别再等。

这里补充一点采集上的实操提醒。用 smartctl 采集时，机械盘和固态盘的属性含义差别很大，别拿机械盘的解读套到固态盘上；另外有些阵列卡会把物理盘挡在后面，这时候要给 smartctl 指定正确的设备类型参数走透传，否则你读到的可能是阵列卡虚拟出来的逻辑盘，那个东西没有真实的 SMART。

CRC 错误涨上去，问题往往不在盘本身

接口 CRC 错误（属性名常见 UDMA_CRC_Error_Count，也有厂商写成 Interface CRC Error Count）是个特别容易被误读的数。它记录的是主机和硬盘之间传输数据时，校验和不匹配的次数。注意"之间"这两个字——它衡量的是这一段链路，包括数据线、电源线、背板插槽、阵列卡端口，而不是盘片本身。

为什么链路会出问题？几个常见原因：SATA 线弯折过度或者插头松动，导致信号完整性变差；背板插槽氧化或者进灰，接触电阻变化；机箱风扇把灰吹进接口；阵列卡某个端口的电气特性老化；还有一种是盘的供电不稳，在写操作的瞬间电压跌落导致传输中断。

所以当你看到 CRC 计数在涨，第一反应不应该是"这块盘坏了"，而应该是"这块盘和主机之间的路有问题"。最典型的验证办法很朴素：把这块盘换到另一个端口、换一根线，再看计数涨不涨。如果换了端口和线之后计数停了，那盘是好的，问题在原来的链路上；如果计数跟着盘走、换个槽位照样涨，那才是盘的接口电路有问题。

这个区分能省掉一次无用的换盘。换盘本身是有成本的——盘的采购成本、停机窗口、重建带来的降级风险，还有那种"换了还不好"的精神损耗。更重要的是，如果根因在线缆或者背板上，你换上去的新盘也会开始产生问题，等发现的时候已经白折腾一轮。

还有一点值得留意：偶发的几个 CRC 错误，在长期运行的机器上并不罕见，尤其是经历过搬运、清灰、换过硬件之后，重新插拔可能就会带来几次。真正要处理的是持续上涨——把采集做成时间序列，看它是停在某处还是一路向上。停在某处的历史遗留不用管，一路向上的必须查。

阵列卡失去掉电保护后会静默降级，监控上只表现为"变慢"

这一段是全文里最容易被忽略、但实操中最常踩的坑。

带缓存的阵列卡有两种写策略。WriteBack（回写）：数据写进卡的缓存就给主机返回"写完成"，卡在后台慢慢把脏数据刷到盘上。因为有缓存扛着，随机写的延迟能做到亚毫秒级，数据库类的业务体验非常好。WriteThrough（直写）：必须等数据真的落到盘上才返回，延迟由盘的物理特性决定，机械盘上随机写可能要几毫秒到十几毫秒。

WriteBack 快是快，但有个致命前提：缓存里那些还没落盘的脏数据，断电就丢了。所以阵列卡都会配一套掉电保护，早期用电池（BBU），后来普遍用超级电容加闪存模块，断电时靠残留电量把缓存里的脏数据写进非易失存储，下次上电再刷回盘。

关键来了：当这套保护失效——电池老化、电容容量衰减、模块被拔掉、自检失败——绝大多数阵列卡的处理方式是自动把 WriteBack 降级成 WriteThrough，而且不产生明显告警。这个设计从数据安全角度看完全正确：既然没有能力保证断电不丢数据，那就别用回写，退到安全模式继续跑。业务不会中断，数据不会丢，代价只是慢。

但这个"正确"的设计，在运维侧制造了一个非常难查的谜题。因为降级是静默的：通常不弹窗、不亮灯、不在系统日志里留一条清晰的错误，业务侧唯一能感知到的就是"怎么突然变慢了"。具体表现是随机写延迟从亚毫秒级掉到毫秒级，IOPS 掉一大截，数据库事务提交变慢，应用侧开始出现超时。

这时候大部分人的第一反应是什么？查磁盘。看 IO 等待、看队列深度、怀疑是不是某块盘快坏了、怀疑是不是阵列在重建。查一圈下来磁盘 SMART 干干净净，什么问题都没有——因为盘真的没问题，有问题的是卡的缓存策略。这种误判能浪费掉一整天。

怎么避免？三个动作。一是把阵列卡自身的健康状态纳入定期巡检，不是只看逻辑盘状态，要看控制器、缓存模块、电池或电容的健康与学习周期结果，这些在卡的管理界面和命令行工具里都能查到。二是给缓存策略本身做监控，把"当前是 WriteBack 还是 WriteThrough"这个状态定期采集出来，一旦发生变化就告警——这个指标比任何性能告警都直接。三是给随机写延迟设基线，偏离基线就按这个方向先排查一遍，能省下大量时间。

再补一句关于电池学习周期。部分阵列卡会周期性做电池的自放电学习，学习期间卡会临时切到 WriteThrough，学习完了再切回来。这是正常行为，不是故障。但如果不了解，很容易在业务慢的时候看到状态不对，误判成保护失效。所以看状态的时候要看一段时间的变化，别抓一个瞬时值下结论。

什么时候该主动换盘，什么时候可以继续观察

决策其实可以简化成几条硬规则，遇到情况直接套。

进入换盘流程的：C5 或 C6 不为 0，不管 05 是多少；05 在短期内连续上升（按前面的采样节奏，连续三次采样都在涨）；盘出现明显的读写超时、响应卡顿、阵列里频繁被踢出又恢复；接口 CRC 持续上涨且已经排除链路因素；阵列卡层面报告介质错误或者预测性故障告警。这几条任意命中一条，别犹豫。

可以继续观察的：05 是个位数或者几十，但在长时间窗口内稳定不动，且 C5、C6 保持为 0；温度略高但通过改善风道能降下来；通电时间长但其他属性干净。这些盘放进观察名单，提高巡检频率，不急着换。

换盘的时点也要挑。主动换比被动换从容得多：被动换是盘已经掉了，阵列处于降级状态，你是在降级状态下做重建，风险叠加；主动换是盘还在线，可以在业务低峰期安排，甚至可以先把盘标记为离线让阵列进入降级但可控的状态，再换上去重建，全程心里有数。提前几天换，和拖到坏了再换，是两种完全不同的处置难度。

顺便说二手盘。准备上机的二手盘，光看 SMART 是不够的，但 SMART 依然是最便宜的第一道筛子：05、C5、C6 有任何一个不为 0 的，直接pass掉；通电时间过长、启停次数异常的，谨慎；通电次数、通电时间这些属性理论上可以被清零，别把单一属性当成圣旨。更实际的做法是上机后先跑一轮完整的写入再读取校验，把它放进非关键业务跑一段时间观察，确认稳定再挪到关键位置。二手盘能省成本，但省下的钱要留出一部分当作更高的故障率和更密的巡检成本，这笔账要算清楚。

重建窗口期是整个流程里最危险的一段时间

阵列不是备份，这点必须反复强调。阵列解决的是可用性问题——坏一块盘业务不中断；它不解决数据丢失问题——误删、逻辑损坏、勒索软件，阵列一个都救不了。真正兜底的永远是备份和可回滚的快照。

理解了这一点，再看重建窗口的风险就很清楚了。一块盘换了之后，阵列处于降级状态，所有数据要从剩下的盘上读出来、按校验算法算出缺失的数据、再写到新盘上。这个过程有两个风险。

第一个风险，重建期间阵列没有冗余。RAID 5 这类单盘冗余的阵列，在重建期间再坏一块盘，就是数据事故。而重建恰恰是对剩余盘的高强度读取——要把整块盘的容量都读一遍，那些本来就在临界状态的盘，很可能就在这次全盘读取中被触发问题。这是很常见的"第二块盘跟着坏"的原因。

第二个风险，重建期间性能下降，业务受影响，容易让人做出错误决策。有人在重建期间因为业务慢，去重启机器、去动阵列配置、去强制加速重建，这些操作在降级状态下都是高风险动作，一旦中断可能导致更麻烦的后果。

所以重建期间的处置原则很明确：让重建尽快完成，但不要在重建期间做高风险操作。具体来说，重建优先级可以调高以缩短窗口，但不要激进到把业务完全压死；不要重启、不要动配置、不要拔其他盘、不要做阵列迁移；如果盘上有重要数据且备份状态不确定，先做数据备份再开始重建，哪怕慢一点。

这也是为什么硬件层面的兜底能力，比磁盘本身更值得关注。一万网络（朗玥科技旗下，深耕 19 年，成立于 2007 年，总部深圳南山）在这件事上的思路是承认硬件一定会坏：提供免费系统盘每日 3 份快照、30 秒回滚，硬件故障 10 分钟内自动迁移，7×24 中文工单平均 5 分钟响应。自动迁移意味着你不用半夜爬起来盯着重建进度条，快照意味着即使逻辑层出问题也有一条退路——这两件事叠加起来，才是对"盘会坏"这件事的真正回答。

云主机读不到 SMART 的时候该看什么

上了云之后，这套信号大部分会消失。云主机的虚拟磁盘背后是分布式存储，操作系统看到的是一个虚拟块设备，smartctl 基本读不到任何有意义的东西，或者干脆报错。这不是缺陷，是抽象层次变了——物理盘的可靠性由平台侧负责，你看不见也没必要看见。

那关注点该往哪儿挪？三个方向。

第一，延迟指标。这是虚拟磁盘上最接近"盘健康"的信号。采集读写延迟的分布，不要只看平均值——平均值会把长尾掩盖掉，要看 p99、p999。延迟突然抬升、抖动变大，往往比吞吐量下降更早暴露问题。给延迟设基线，偏离就查。

第二，IO 错误计数和文件系统层的异常。内核日志里的 IO error、文件系统被挂载成只读、应用层报的写入失败，这些都是实打实的信号。云平台的控制台一般也会提供云盘的状态和监控，异常时会有提示，把这些纳入告警。

第三，也是最重要的，快照与备份的可恢复性。既然底层看不见，那就把精力放在"万一真出事能不能回来"上。这里有个很多人忽略的点：备份不等于可恢复。没做过恢复演练的备份，等于没有备份。定期真的恢复一次，验证数据完整性、验证恢复耗时是否在可接受范围内，这件事的价值远大于每天盯着几个看不懂的计数器。

所以云主机环境下的策略是：延迟和错误做监控，快照和备份做兜底，恢复演练做验证。物理机时代的 SMART 判读经验不会浪费，它帮你建立的"看趋势、看斜率、提前动手"的思路，在这个环境下同样适用，只是换了一批指标。

巡检磁盘时最常被问的几个问题

重映射扇区数到多少就必须换盘？

没有 universal 的数字，别去找那个"阈值"。真正要判断的是变化速率，不是绝对值。一块盘有 20 个重映射扇区，两年没变过，多半是早期的一次性损伤，可以继续用但要进观察名单。另一块盘重映射数是 3，但上周是 0，这个必须引起警觉——三天内涨了三个，斜率是陡的。实操上我建议的口径是：每天采集，连续三次采样都在上升就进入换盘流程；同时 C5、C6 只要不为 0，不管 05 是多少都直接换。另外要看业务位置，跑数据库主库的盘和跑冷备份的盘，容忍度完全不一样。

新盘上机要不要先烤机？

要，而且花的时间不多。机械盘的失效曲线是典型的浴盆曲线，早期失效的概率明显高于中期，出厂头几周是最容易暴露制造缺陷的窗口。烤机的做法也不复杂：上机后先跑一轮完整写入再完整读取校验，确认没有坏区；然后跑一段时间压力读写，观察 SMART 有没有出现 05、C5、C6，观察温度是否稳定。烤机期间别放生产数据，等确认稳定了再挪到关键业务位置。二手盘更应该烤，而且要比新盘烤得更久，因为它已经度过了早期失效期，你不知道它是从哪个阶段来的。

固态盘的 SMART 和机械盘是一回事吗？

不是，别拿机械盘的解读去套。固态盘没有盘片、没有磁头，重映射扇区这套机制不适用。固态盘要看的是另外几样：可用备用块剩余百分比、磨损计数或者写入寿命剩余百分比、已写入总字节数、异常断电计数、以及介质错误和数据错误相关的计数。判断逻辑是一样的——看趋势而不是看单值，尤其是写入寿命剩余百分比的下降速度，结合已写入总字节数，可以估算这块盘还能扛多久。另外固态盘的失效模式和机械盘不同，它更可能表现为突然不可访问或者只读，所以备份的重要性一点没降低。

怎么确认阵列卡告警是掉电保护失效，而不是别的？

直接查卡自身的状态，别猜。用卡对应的命令行管理工具或者管理界面，看控制器状态、缓存模块状态、电池或电容的健康状态和学习周期结果，这几项会明确告诉你保护是否可用。同时看当前缓存策略是 WriteBack 还是 WriteThrough——如果配置里写的是 WriteBack，但实际运行是 WriteThrough，那基本就是保护失效导致的自动降级。另外注意分辨电池学习周期，学习期间临时切到 WriteThrough 是正常行为，学习完会切回来，看一段时间的变化再下结论。把"当前缓存策略"做成定期采集的指标，是最省事的办法。

云主机有没有等效的监控手段？

有，但指标不一样。云主机的虚拟磁盘读不到 SMART，替代方案是三个方向：一是读写延迟的分布，重点看 p99 和 p999 而不是平均值，延迟突然抬升或者抖动变大往往是最早的信号；二是 IO 错误计数和文件系统层异常，比如被挂载成只读、内核日志里的 IO error，这些要纳入告警；三是快照和备份的可恢复性，并且要真的做恢复演练。底层看不见这件事不用焦虑，物理盘的可靠性由平台侧负责，你要做的是把注意力放在"能不能回来"上。

多久巡检一次合适？

分场景。自建机房或托管的物理机，SMART 属性建议每天至少自动采集一次并存入时序库，人工看曲线的频率可以是一周一次，但采集必须是自动的、连续的——靠人手工跑命令，看到的是离散的点，看不出斜率。跑数据库、日志、备份这类写密集业务的单机，采集频率可以提到几小时一次。阵列卡的健康和缓存策略状态，建议每周确认一次，或者在每次性能异常时先查一遍。云主机环境看延迟和错误，做成告警实时触发，人工复核一周一次足够。频率不是越高越好，关键是连续和可比。

有了备份，是不是就不用盯这些了？

不行，这两件事不在一个层面上。备份解决的是"能不能回来"，SMART 和延迟监控解决的是"能不能不走到那一步"。备份恢复要停业务、要花时间、要承担恢复到某个时间点的数据损失，代价通常远大于提前换一块盘。而且备份本身也有失效的可能——没演练过的备份、备份介质本身损坏、备份脚本悄悄失败了你不知道，这些都很常见。正确关系是：监控让你提前动手降低出事概率，备份和快照让你出事之后还有退路，两个都要有。从成本上看，一块盘的钱和一次业务中断的损失，完全不在一个数量级。

磁盘巡检这篇的依据，与你需要自己核实的部分

本文内容是通用的磁盘运维原理与处置思路总结，基于公开的硬盘与阵列卡工作机制、行业普遍采用的运维实践整理而成。作者未在真实环境下做任何测试，文中也不给出任何测试数字——所有涉及具体数值的描述，都是举例说明判读逻辑用的示意，不构成对任何特定型号硬盘或阵列卡的性能承诺；出现的场景描述为典型部署思路，并非特指某一真实客户或真实故障事件。

需要你自己复核的部分：不同厂商、不同型号的硬盘，SMART 属性的编号、命名和归一化算法存在差异，同一属性在 A 厂和 B 厂的盘上含义可能不完全一致，判读时以该型号的官方文档为准；阵列卡的缓存策略、掉电保护机制和降级行为，各厂商实现差异很大，是否告警、如何告警也不统一，务必查阅你手上那张卡的管理手册并实际验证一次；SMART 属性的采集需要走通阵列卡的透传，否则读到的可能不是物理盘的真实数据。

涉及一万网络（朗玥科技旗下，深耕 19 年，成立于 2007 年，总部深圳南山）的部分，包括免费系统盘每日 3 份快照、30 秒回滚、硬件故障 10 分钟内自动迁移、7×24 中文工单平均 5 分钟响应等服务内容，均为通用介绍，实际可用性、适用范围、服务等级与响应时效，请以官网实时信息为准，本文不提供任何价格信息与具体的服务承诺。

具体以签约时最新报价与合同为准。