硬盘SMART巡检：该看哪几个属性值

  1.  Home
  2. Text  
    3. Share to：

一、SMART 不是「能看就行」

硬盘坏掉这件事，最麻烦的地方不是坏，而是坏得没有预告。对个人站长来说，一台 VPS 上的数据盘或者家里那台自建服务器，一旦静默损坏，能依靠的往往只有备份，而备份多半停在两周前。SMART 的价值就在于它是一套提前量：厂商在盘体里留了一批计数器，用来记录重新分配扇区、待映射扇区、命令超时、读取校验错误这些「还没坏透但已经异常」的迹象。

但这些数字有个大前提：它只是迹象，不是判决。同一块盘上的重试次数可能因为一次电源瞬断就涨一截，也可能确实在慢慢死。判断要结合趋势、结合具体属性、结合盘的类型（机械盘、SATA SSD、NVMe 三者的判据不同）。本文按「装什么工具、看哪几个数、怎么自动化、坏了怎么处置」四步讲。

二、装工具与第一次采样

Debian/Ubuntu 上只需要一个包：

apt install smartmontools
systemctl status smartd

# 列出所有盘
lsblk -d -o NAME,SIZE,ROTA,MODEL

# 查看是否支持 SMART（USB 硬盘盒经常显示 Unavailable）
smartctl -i /dev/sda
smartctl -i /dev/nvme0

几个前提条件不满足，后面看到的数据全是假的或者空的：

  • 必须用 root 或有 CAP_SYS_RAWIO 的权限，普通用户执行 smartctl -a 会返回权限错误但退出码未必非 0。
  • RAID 卡后面的盘看不到。硬件 RAID 下 smartctl -d megaraid,N /dev/sda 可以穿透，软 RAID（mdadm）通常能直读，但盘会被 md 独占唤醒。
  • USB 硬盘盒是最常见的坑。多数 USB-SATA 桥接芯片不透传 SMART，smartctl -i 会显示 SMART support is: Unavailable。部分芯片可用 -d sat 强制，有些要 -d usbjmicron，能不能读到完全看盒子。
  • NVMe 走的是另一套日志，smartctl -a /dev/nvme0 输出的字段和 ATA 完全不同，不要拿 ATA 的经验往上套。

第一次采样要做的事是把当前状态存一份基准，后面所有判断都是与它对比：

mkdir -p /var/log/smart
for d in /dev/sd? /dev/nvme?n1; do
  [ -b "$d" ] || continue
  n=$(basename "$d")
  smartctl -x "$d" > /var/log/smart/${n}-$(date +%Y%m%d).txt 2>&1
done
ls -l /var/log/smart/

用 -x 而不是 -a，因为扩展信息里包含错误日志（Error Log）和设备自检记录，这两项在排查时非常关键。

三、机械盘：五个真正需要盯的属性和它们的阈值

ATA 盘看原始值（RAW_VALUE），不是当前值（VALUE）与阈值（THRESH）的关系。后者是厂商内部的归一化刻度，很多厂商设阈值极低，盘快死了归一化值仍然大于阈值，于是 smartctl 判断 PASSED。这是「SMART 显示正常但盘已经不行了」的最常见原因。

  • ID 5 Reallocated_Sector_Ct（重映射扇区数）：最硬的指标。原始值非 0 就说明有扇区已经物理损坏并被备用区替换。小于 10 且长期不涨可以观察；大于 0 而且一个月内涨了，直接换盘。
  • ID 197 Current_Pending_Sector（待映射扇区数）：读写时校验失败、等待替换的扇区。它比 ID 5 更急，因为这块区域还没被隔离，一次读取就可能失败。非 0 就当作告警，做一次全盘读测（smartctl -t long）看能不能重映射掉。
  • ID 198 Offline_Uncorrectable（脱机不可纠正）：离线自检时读写错误且无法纠正。只要非 0 就必须换盘，没有观察的余地。
  • ID 187 Reported_Uncorrect：不可纠正错误的累计计数，与 198 互补，198 为 0 而 187 持续增长同样危险。
  • ID 199 UDMA_CRC_Error_Count（接口 CRC 错误）：这个不代表盘坏，而是 SATA 线或背板接触不良。线材、背板、热插拔槽位都可能贡献。持续增长先换线，别急着换盘。

另外两条容易被误读：

  • ID 9 Power_On_Hours 只说明服役时长。机械盘普遍在 3~5 万小时后故障率上升，但这不是阈值，一块用了 6 万小时仍零重映射的盘，比用了 5000 小时已有 200 个重映射的盘健康得多。
  • ID 194 Temperature_Celsius 过高会加速老化。持续 50 度以上要看机箱风道，数据中心盘 40 度上下是正常的。

四、SSD 与 NVMe：换成另一套判据

固态盘的故障模式与机械盘完全不同，重映射扇区这项基本不适用，真正的杀手是写入寿命耗尽和主控掉盘。SATA SSD 通常关注：

  • ID 241 Total_LBAs_Written 或 ID 246 Total_Host_Sectors_Written：累计写入量，单位因厂商而异（有的是 512 字节扇区数，有的是 LBA 数），必须结合 smartctl -i 里的容量和厂商文档换算，不要直接当 GB 读。
  • ID 231 SSD_Life_Left 或 ID 202 Percent_Lifetime_Remain：剩余寿命百分比，这是厂商归一化后的值，掉到 10% 以下就该规划更换。
  • ID 233 Media_Wearout_Indicator（Intel 系）同类含义。

NVMe 用 smartctl -a /dev/nvme0，直接看几个百分比字段，不需要换算：

Percentage Used:                    4%
Data Units Written:                 58,312,004 [29.8 TB]
Data Units Read:                    91,204,556 [46.7 TB]
Media and Data Integrity Errors:    0
Error Information Log Entries:      12
Available Spare:                    100%
Available Spare Threshold:          10%
  • Percentage Used 是寿命消耗，超过 80% 开始准备换盘；
  • Available Spare 掉到阈值附近说明备用块快用完，这是硬告警；
  • Media and Data Integrity Errors 非 0 就是数据已经出过错，配合 Error Information Log 看是否有不可恢复错误；
  • Unsafe Shutdowns 高说明电源不稳或频繁硬重启，长期会磨损映射表。

五、把巡检做成定时任务

人不会每天登录去看一行行数字，所以必须自动化。smartd 本身就能做告警，配置在 /etc/smartd.conf：

# 全部盘：每天 3 点短自检，每周日 4 点长自检
DEVICESCAN -a -o on -S on -s (S/../.././03|L/../../7/04) -m root -M exec /usr/share/smartmontools/smartd-runner

-a 开启全部检测，-o on 启用离线数据收集，-S on 保存属性变化，-s 定义自检计划。机械盘每周长自检对 I/O 有一定影响，尽量放在业务低峰；SSD 长自检主要是读，压力小得多。

smartd 的告警有它自己的局限：它只在属性越过厂商阈值时才报，而前面说过阈值往往设得太松。所以更实用的是自己写一条带判断的巡检脚本，按属性 ID 抓原始值：

for d in /dev/sd? /dev/nvme?n1; do
  [ -b "$d" ] || continue
  echo "== $d"
  smartctl -A "$d" 2>/dev/null | awk '$1==5||$1==197||$1==198{print "ATA",$2,"raw="$10}'
  smartctl -a "$d" 2>/dev/null | grep -E 'Percentage Used|Available Spare:|Media and Data Integrity Errors'
done

把输出接到自己的告警渠道（邮件、企业微信、ntfy 都行），只在「ID 5 或 197 或 198 的原始值非 0」或者「Percentage Used 超过 80」时才发送。这种少而准的告警比每天一封「一切正常」的日报有用得多——后者三周之后就没人看了。

六、自检与读测：什么时候该跑

两种自检的用途不同：

  • smartctl -t short 约 1~2 分钟，检查主控、电机和部分介质，适合每天跑；
  • smartctl -t long 机械盘要几小时（按容量），SSD 通常几分钟到半小时，能扫到全盘介质。

读测不是在「怀疑坏了」时才做，而是在「想确认它还能用」时做。具体判据是：当前有待映射扇区（ID 197 非 0），跑一次长自检，如果这些扇区被成功重映射到备用区、197 归零、5 增加相应数量，说明盘的纠错机制还在工作，可以继续观察；如果长自检中途失败、或者 197 重映射后又涨回来，那就是介质在持续劣化，该换。

smartctl -t long /dev/sda
# 等自检结束（-c 查看进度），然后看结果
smartctl -l selftest /dev/sda
smartctl -l error /dev/sda

注意长自检期间盘带负载，机械盘做全盘读会让业务 I/O 明显变慢。生产环境建议安排在凌晨，并在告警里区分「自检导致的高延迟」和「真实故障」。

七、确认要换盘时的处置顺序

看到硬告警之后的顺序很重要，做错一步可能导致本来能救的数据救不回来：

  1. 先别再跑任何全盘扫描或 dd 读测。待映射扇区多的盘，每次全盘读都在加速它彻底失效。
  2. 先把最重要的数据复制出来，按重要性而不是按目录顺序。数据库导出放在第一位，然后是上传文件、配置文件。
  3. 换盘，不要尝试修复。软件层面的扇区修复对已经物理劣化的盘只是把问题往后推，而且过程中随时可能变成不可读。
  4. 新盘装机后重新验证一遍 SMART 是干净的，并且把 smartctl -x 的输出存档，作为它的基准。
  5. 复盘备份策略。一块盘坏掉不应该让人紧张，如果紧张了，说明备份的验证环节有问题——定期做一次「从备份完整恢复」的演练，比每天看 SMART 数字更能保命。

八、小结

SMART 的使用姿势可以总结成三句话：机械盘看 ID 5/197/198 的原始值而不是归一化值；固态盘看 Percentage Used 与 Available Spare；告警要只报异常，不要天天报正常。工具层面只装 smartmontools、每天短检、每周长检、再配一条按属性 ID 判断的自定义脚本，就足够覆盖个人站长绝大多数盘故障的提前量。真正决定数据安危的仍然是备份，SMART 只是让你在坏之前有多一点时间去做那件早就该做的事。

Last modification：October 31st, 2026 at 12:25 pm
© 允许规范转载

相关文章

Leave a Comment