smartctl 和 smartmontools：Linux 驱动器健康监控完整指南

smartctl 是 smartmontools 软件包的主要命令行界面，专为查询、测试和解析嵌入在 HDD、SSD 和 NVMe 驱动器固件中的 S.M.A.R.T.（自我监测、分析和报告技术）数据而设计。它通过 ATA、SCSI 或 NVMe 接口直接与驱动器固件通信，以获取操作系统本身无法通过标准 I/O 路径暴露的原始诊断遥测数据。

对于任何管理物理或虚拟存储的 Linux 管理员——无论是在裸金属服务器、独立服务器还是本地连接的磁盘阵列上——smartctl 是在不可恢复的数据丢失发生之前检测即将发生的驱动器故障的最可靠工具。

什么是 S.M.A.R.T. 以及为何重要

S.M.A.R.T. 是一种内置于 1996 年后生产的几乎所有消费级和企业级存储设备中的监控系统。它在固件层面运行，持续跟踪数十个内部参数：读/写错误率、机械应力指标、NAND 磨损程度、重新分配扇区计数以及温度读数。

大多数指南忽略的关键区别：S.M.A.R.T. 数据是预测性的，而非被动响应的。一个驱动器可以通过文件系统检查并正常提供 I/O 服务，同时以统计上预测在数周内发生故障的速率积累重新分配的扇区。smartctl 可以揭示这种隐藏的退化状态。

S.M.A.R.T. 在三个存储接口系列中运行：

• ATA/SATA — 原始 S.M.A.R.T. 规范，属性最为丰富
• SCSI/SAS — 使用不同的属性模型（信息异常日志页）
• NVMe — 通过 NVMe 健康信息日志（日志页 0x02）暴露健康数据，包含可用备用容量、使用百分比和不安全关机等指标

在 Linux 上安装 smartmontools

smartmontools 软件包在每个主要 Linux 发行版的官方软件仓库中均可获取。根据您的环境安装适当的版本：

Debian / Ubuntu：

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7：

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux：

“`bash

sudo dnf install smartmontools

“`

Fedora：

“`bash

sudo dnf install smartmontools

“`

Arch Linux：

“`bash

sudo pacman -S smartmontools

“`

openSUSE：

“`bash

sudo zypper install smartmontools

“`

安装后，验证版本并确认已编译 NVMe 支持：

“`bash

smartctl –version

“`

在支持的设备类型列表中查找 `NVMe`。6.6 之前的版本对 NVMe 的支持不完整——在运行 NVMe SSD 的现代服务器上，请确保运行 smartmontools 7.x 或更高版本。

识别您的存储设备

在运行任何 smartctl 命令之前，请先确认正确的设备节点。在多磁盘系统上混淆设备标识符是一个常见且代价高昂的错误。

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

此命令输出设备名称及传输类型（sata、nvme、usb），这直接决定了您需要使用哪些 smartctl 标志。对于 NVMe 设备，节点将显示为 `/dev/nvme0`、`/dev/nvme1` 等——而非 `/dev/sdX`。

对于硬件 RAID 控制器（LSI MegaRAID、Adaptec、HP Smart Array），驱动器隐藏在控制器后面，需要使用显式直通标志，详见下方高级部分。

核心 smartctl 命令

查看设备标识信息

“`bash

sudo smartctl -i /dev/sda

“`

此命令查询设备的 IDENTIFY DATA 页，返回型号、序列号、固件版本、容量、扇区大小（512 字节逻辑扇区与 4096 字节物理扇区——对对齐很重要）以及 S.M.A.R.T. 能力标志。对于 NVMe 设备：

“`bash

sudo smartctl -i /dev/nvme0

“`

运行完整健康评估

“`bash

sudo smartctl -H /dev/sda

“`

返回单行结论：`PASSED` 或 `FAILED`。`FAILED` 结果意味着驱动器自身的固件已确定一个或多个关键阈值已被突破。报告 FAILED 的驱动器应被视为已故障——不要等待进一步确认。

然而，`PASSED` 结果并不意味着驱动器是健康的。它只意味着没有正式突破任何阈值。这就是为什么原始属性分析至关重要。

显示所有 S.M.A.R.T. 属性

“`bash

sudo smartctl -A /dev/sda

“`

这是日常使用中信息密度最高的命令。输出表格包含几列需要精确解读的内容：

RAW_VALUE 是您应主要分析的内容。归一化的 VALUE/WORST/THRESH 系统对于自动阈值检测很有用，但可能会产生误导——某些制造商使用非标准的归一化曲线。

综合输出：组合标志

要在单个命令中获得完整信息，请组合信息、健康和属性标志：

“`bash

sudo smartctl -a /dev/sda

“`

小写 `-a` 标志等同于 `-H -i -c -A -l error -l selftest`。这是诊断不熟悉的驱动器时运行的标准命令。

要获得包含所有日志页的更详细输出：

“`bash

sudo smartctl -x /dev/sda

“`

关键 S.M.A.R.T. 属性及其解读方法

并非所有 S.M.A.R.T. 属性都具有同等的诊断权重。以下是经验丰富的存储工程师视为主要故障指标的属性：

高优先级故障指标

Reallocated_Sector_Ct（ID 5）

驱动器因读/写/验证错误而重新映射到备用区域的扇区数量。两年以下的驱动器上任何非零值都需要立即关注。持续增加的计数——即使在一个月内从 1 增加到 5——也是即将发生故障的强烈预测指标。对于企业级驱动器，根据制造商规格，少量可能是可以接受的。

Current_Pending_Sector（ID 197）

被标记为不稳定并等待重新映射的扇区。这些扇区在读取过程中产生了错误，但尚未成功重新映射。此处的非零值意味着驱动器正在积极地努力读取数据。如果待处理扇区随后被成功写入，它可能会被重新映射或清除——但底层介质是可疑的。

Uncorrectable_Sector_Count（ID 198）/ Offline_Uncorrectable

无法通过 ECC 纠正且无法重新映射的扇区。这是最严重的属性。此处的非零值意味着这些扇区的数据已经丢失。立即备份和更换驱动器是唯一适当的响应。

Reported_Uncorrect（ID 187）

在现代驱动器上，这计算驱动器内部 ECC 无法纠正的错误。高值表示严重的介质退化。

Spin_Retry_Count（ID 10）

对于 HDD，反复无法将盘片旋转到工作速度。表明主轴电机或轴承上的机械应力。在重度使用的驱动器上任何非零值都是危险信号。

Command_Timeout（ID 188）

因超时而中止的命令计数。较高的值通常表示接口问题（电缆、控制器或电源传输）而非介质故障——但它们也可能预示着驱动器完全故障。

次要监控属性

Raw_Read_Error_Rate（ID 1）

经常被误读：在 Seagate 驱动器上，此属性的原始值设计上非常高，因为它表示编码在 48 位字段中的比率。Seagate 驱动器上数百万的原始值是正常的。在 Western Digital 和其他制造商的驱动器上，原始值应接近零。在对此属性发出警报之前，请务必参考制造商的文档。

Power_On_Hours（ID 9）

总运行小时数。消费级 HDD 通常额定为 20,000–25,000 小时（大约 2–3 年的连续运行）。企业级驱动器额定为 55,000+ 小时。使用此值来为其他属性值提供背景。

Temperature_Celsius（ID 194）

当前驱动器温度。大多数 HDD 的最佳工作范围为 25–45°C。持续高于 55°C 的温度会加速轴承磨损和磁性介质退化。对于 SSD，热耐受性通常更高，但持续高于 70°C 的温度会加速 NAND 磨损。在气流不足的服务器上——这在密集机架部署中是常见问题——热节流可能在温度属性超过任何正式阈值之前将自身伪装成 I/O 延迟。

Wear_Leveling_Count（ID 177）/ Media_Wearout_Indicator（ID 233）

跟踪 NAND 耐久性消耗的 SSD 特定属性。当归一化 VALUE 接近 THRESH 值时，SSD 正在接近其额定写入耐久性。请主动规划更换。

Power_Cycle_Count（ID 12）

频繁的电源循环会对 HDD 造成机械应力（磁头停靠/取消停靠、主轴电机应力），对 SSD 造成较小程度的电气应力。相对于 Power_On_Hours 异常高的计数可能表明电源环境不稳定。

运行诊断自检

S.M.A.R.T. 自检由驱动器自身的固件执行，而非操作系统。驱动器在测试期间继续提供 I/O 服务（有轻微的性能影响），使这些测试可以安全地在生产系统上运行。

短自检

“`bash

sudo smartctl -t short /dev/sda

“`

持续时间：通常 1–5 分钟。测试电气和机械组件以及磁盘表面的一小部分。适用于快速健全性检查。完成后查看结果：

“`bash

sudo smartctl -l selftest /dev/sda

“`

长自检（扩展测试）

“`bash

sudo smartctl -t long /dev/sda

“`

持续时间：与驱动器容量成比例——典型的 7200 RPM HDD 每太字节约需 1 小时，大多数 SSD 需 20–60 分钟。对每个扇区执行完整的表面扫描。这是检测整个介质表面坏扇区的权威测试。

无需等待完成即可监控进度：

“`bash

sudo smartctl -c /dev/sda

“`

输出包括完成百分比和预计完成时间。

运输自检

“`bash

sudo smartctl -t conveyance /dev/sda

“`

在大多数 ATA 驱动器上可用。旨在检测运输或物理处理过程中造成的损坏。检查由机械冲击引起的问题。持续时间通常为 5 分钟。此测试使用不足——在调试新硬件或服务器被物理移动后特别有价值。

选择性自检

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

允许测试特定的 LBA 范围而非整个驱动器。当文件系统检查在特定区域标记了错误，而您需要确认底层介质是否是原因时，此功能非常宝贵。

NVMe 特定健康监控

NVMe 驱动器使用根本不同的属性模型。主要健康命令：

“`bash

sudo smartctl -a /dev/nvme0

“`

需要监控的关键 NVMe 特定字段：

• Available Spare（可用备用）：剩余备用 NAND 块的百分比。低于 10% 时需要规划更换。
• Available Spare Threshold（可用备用阈值）：制造商定义的阈值，低于此值驱动器可能报告可靠性降低。
• Percentage Used（使用百分比）：已消耗的额定写入耐久性的估计百分比。达到 100% 时，驱动器已达到其额定 TBW（已写入太字节）——它可能继续运行，但可靠性保证不再适用。
• Data Units Read / Written（读取/写入数据单元）：以 512,000 字节单位计的累计 I/O。用于计算实际工作负载与额定 TBW 的比较。
• Media and Data Integrity Errors（介质和数据完整性错误）：NVMe 控制器检测到的未恢复介质错误或数据完整性错误。任何非零值都是严重的。
• Number of Error Information Log Entries（错误信息日志条目数）：错误日志条目的计数。快速增长的计数表明存在持续性问题。
• Power State（电源状态）：当前 NVMe 电源状态——与延迟敏感型工作负载相关，其中驱动器可能处于深度节能状态。

硬件 RAID 和直通访问

当驱动器通过硬件 RAID 控制器连接时，操作系统看到的是控制器的虚拟磁盘，而非物理驱动器。smartctl 需要显式直通才能直接访问驱动器固件。

LSI MegaRAID：

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array（hpsa 驱动程序）：

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID：

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

如果您不确定使用哪种直通类型，smartctl 可以尝试自动检测：

“`bash

sudo smartctl –scan

“`

这将扫描所有可检测的存储设备，并为每个设备输出推荐的设备路径和类型标志。

启用和禁用 S.M.A.R.T.

S.M.A.R.T. 在几乎所有现代驱动器上默认启用。在极少数情况下——通常是较旧的驱动器或某些虚拟化环境——它可能被禁用：

“`bash

sudo smartctl -s on /dev/sda

“`

要禁用（除特定测试场景外不推荐）：

“`bash

sudo smartctl -s off /dev/sda

“`

注意：在 KVM 或 VMware 等虚拟化环境中，S.M.A.R.T. 直通到客户虚拟机取决于虚拟机管理程序配置。在 VPS 托管环境中，虚拟机管理程序通常会抽象物理驱动器，客户机内的 smartctl 可能返回有限数据或无数据。要获得完整的 S.M.A.R.T. 访问权限，需要物理主机级别的监控或独立服务器。

使用 smartd 进行自动化监控

smartd 守护进程是 smartmontools 的生产级组件。它在后台运行，定期轮询驱动器并执行计划测试，然后在阈值被突破或测试失败时向管理员发出警报。

配置 /etc/smartd.conf

默认配置使用基本设置监控所有检测到的驱动器。生产环境加固配置如下所示：

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

关键指令说明：

启用和启动 smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

验证守护进程正在积极监控：

“`bash

sudo journalctl -u smartd -f

“`

电子邮件警报配置

要使 smartd 电子邮件警报正常工作，系统需要一个正常工作的 MTA（邮件传输代理）。在最小化服务器安装上，安装并配置 `postfix` 或 `msmtp` 进行中继。如果您使用专用邮件基础设施，请考虑将 smartd 警报与正确配置的电子邮件托管服务配合使用，以确保警报传递不被垃圾邮件过滤器拦截。

S.M.A.R.T. 属性比较：HDD vs. SSD vs. NVMe

实践工作流程：诊断可疑驱动器

当驱动器出现症状——`dmesg` 中的 I/O 错误、文件系统损坏、异常延迟——请遵循以下诊断序列：

步骤 1：确认 S.M.A.R.T. 可用性

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

步骤 2：检查整体健康结论

“`bash

sudo smartctl -H /dev/sda

“`

步骤 3：检查错误日志

“`bash

sudo smartctl -l error /dev/sda

“`

错误日志记录最后 5 个 ATA 错误及其时间戳和 LBA 地址。使用 `debugfs` 或 `xfs_db` 将 LBA 地址与文件系统块映射交叉参考，以确定错误是否影响关键文件系统结构。

步骤 4：分析关键属性

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

步骤 5：运行短测试以立即确认

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

步骤 6：如果短测试通过且症状持续，在维护窗口期间运行长测试

“`bash

sudo smartctl -t long /dev/sda

“`

步骤 7：查看自检日志以获取 LBA 故障地址

“`bash

sudo smartctl -l selftest /dev/sda

“`

失败的测试报告遇到的第一个错误的 LBA。这精确定位了介质损坏的确切位置。

常见陷阱和边缘情况

USB 连接的驱动器：smartctl 通常无法与通过 USB 转 SATA 适配器连接的驱动器通信，因为 USB 桥接芯片不转发 ATA 命令。使用 `-d sat` 或 `-d usb` 标志，或明确指定桥接类型（例如 `-d usb,0x0bc2,0x2312`）。`–scan` 标志将尝试自动识别正确的类型。

虚拟化环境：在 KVM 或 VMware 客户机内，`/dev/sda` 是虚拟磁盘。smartctl 可能返回 `Device does not support SMART` 或虚拟机管理程序传递的合成数据。不要依赖共享托管基础设施上客户机内的 smartctl 输出来评估物理驱动器健康状况。

Raw_Read_Error_Rate 的误报：如上所述，Seagate 对此属性的编码会导致完全正常的原始值看起来令人担忧。在对此值采取行动之前，请务必对照制造商的属性文档进行验证。

软件 RAID（mdadm）后面的驱动器：smartctl 直接访问组件驱动器（`/dev/sda`、`/dev/sdb`），而非 RAID 设备（`/dev/md0`）。单独监控每个成员驱动器。

NVMe 命名空间与控制器：使用 `/dev/nvme0`（控制器）获取健康数据，而非 `/dev/nvme0n1`（命名空间/块设备）。某些 smartctl 版本两者都接受，但控制器节点对于健康日志访问具有权威性。

说谎的驱动器：某些消费级 SSD，特别是低端 QLC NAND 驱动器，已被记录在完全突然故障之前报告健康的 S.M.A.R.T. 属性。S.M.A.R.T. 是一个强有力的指标，但不是保证——它不能替代定期备份。

在服务器环境中部署 smartmontools

对于管理多台物理服务器的管理员——例如在独立服务器上运行工作负载的管理员——集中化 S.M.A.R.T. 监控至关重要。请考虑以下架构：

• Prometheus + node_exporter：`node_exporter` 包含一个 `smartmon` 文本文件收集器脚本，将 S.M.A.R.T. 属性导出为 Prometheus 指标。这支持通过 Alertmanager 发出警报并在 Grafana 仪表板中可视化。
• Nagios / Icinga2：`check_smart` 插件为传统监控堆栈提供 S.M.A.R.T. 监控集成。
• 自定义 smartd 脚本：smartd.conf 中的 `-M exec` 指令可以在警报时触发任何脚本——适用于与 PagerDuty、Slack webhook 或自定义工单系统集成。
• 日志文件聚合：配置 smartd 写入 syslog，然后转发到集中式日志聚合器（ELK 堆栈、Loki）以进行跨机群的历史趋势分析。

对于使用控制面板的 Web 托管环境，带 cPanel 的 VPS 部署受益于由基础设施提供商配置的主机级 S.M.A.R.T. 监控，因为 cPanel 本身不原生暴露驱动器健康数据。

关键要点清单

将此作为部署前和持续运营参考：

• 安装 smartmontools 7.x 或更高版本以确保完整的 NVMe 和现代 SSD 支持
• 在新硬件上运行 `smartctl –scan`以识别所有驱动器及其所需的接口标志
• 首先检查 `-H` 健康结论——`FAILED` 结果需要立即采取行动，无论其他属性如何
• 将任何非零的 Reallocated_Sector_Ct、Current_Pending_Sector 或 Uncorrectable_Sector_Count 视为故障信号——不要等待计数增长
• 不要仅依赖 Raw_Read_Error_Rate——在发出警报之前对照制造商文档进行验证
• 通过 smartd 在所有生产驱动器上每周安排自动长测试；每天进行短测试
• 配置 smartd 电子邮件警报并在依赖它们之前验证传递
• 对于硬件 RAID，始终使用适当的直通标志——监控虚拟磁盘不等同于监控物理驱动器
• 在虚拟化环境中，在虚拟机管理程序/主机级别执行 S.M.A.R.T. 监控，而非在客户虚拟机内部
• 将 S.M.A.R.T. 监控与备份策略配合使用——S.M.A.R.T. 预测故障，但不能防止数据丢失
• 对于 NVMe 驱动器，除错误计数外还要监控 Available Spare 和 Percentage Used
• 在多驱动器服务器上，将 smartd 与集中式警报平台集成，而非依赖本地电子邮件传递

常见问题解答

smartctl 在 VPS 或云实例内部可以工作吗？

在大多数 VPS 环境中，虚拟机管理程序向客户机呈现虚拟块设备。客户机内的 smartctl 将返回无数据或虚拟机管理程序合成的数据，这不反映物理驱动器的实际健康状况。有意义的 S.M.A.R.T. 监控需要访问物理主机。要获得完整的驱动器级可见性，独立服务器是适当的解决方案。

`smartctl -a` 和 `smartctl -x` 有什么区别？

`-a` 标志输出标准的 S.M.A.R.T. 数据集：设备信息、健康结论、能力标志、所有属性、错误日志和自检日志。`-x` 标志输出 `-a` 提供的所有内容，加上额外的日志页，包括选择性自检日志、设备统计日志、待处理缺陷日志和 ATA 设备统计——提供更完整的驱动器历史记录。使用 `-x` 进行彻底诊断；使用 `-a` 进行常规检查。

长自检需要多长时间，在生产驱动器上运行安全吗？

持续时间取决于驱动器容量和速度：7200 RPM HDD 每太字节约需 1 小时，大多数 SSD 需 20–60 分钟。测试在驱动器固件后台运行，驱动器在测试期间继续提供 I/O 服务。性能影响通常较小（吞吐量降低 5–15%）。在低流量期间在生产系统上运行是安全的，但对于延迟敏感型工作负载，建议在维护窗口期间安排。

当 Current_Pending_Sector 非零但 Reallocated_Sector_Ct 没有增加时意味着什么？

驱动器已识别出在读取过程中产生错误但尚未成功重新映射的扇区。重新映射发生在驱动器可以写入扇区时——通过写操作或离线扫描。如果计数保持静态，扇区可能位于只读区域，或者驱动器可能缺少可用于重新映射的备用扇区。非零且不断增加的 Current_Pending_Sector 计数，而 Reallocated_Sector_Ct 保持不变，通常表明驱动器已耗尽其备用扇区池——这是一个关键故障状态。

smartctl 能在驱动器故障之前检测 SSD 磨损吗？

可以，对于 SATA SSD，Wear_Leveling_Count（ID 177）、Media_Wearout_Indicator（ID 233）和 Available_Reservd_Space（ID 232）属性跟踪 NAND 耐久性消耗。对于 NVMe SSD，NVMe 健康信息日志中的 Percentage Used 和 Available Spare 字段具有相同的用途。当 Available Spare 降至其阈值以下或 Percentage Used 达到 100% 时，驱动器已消耗其额定写入耐久性。与突然的机械故障不同，SSD 磨损退化是渐进的且高度可预测的——使其成为主动 S.M.A.R.T. 监控最强的使用案例之一。