smartmontools で予測するディスク障害｜SMART 閾値設計・systemd タイマー監視・交換判断フロー

SMART 監視が実務で重要な理由

ストレージ障害は突然発生するように見えて、多くの場合は数日〜数週間前から予兆が現れています。Self-Monitoring, Analysis and Reporting Technology（SMART）はドライブ自身が蓄積する診断データであり、smartmontools はそれを Linux 上で読み取る事実上の標準ツールです。

クラウド移行が進んだ現在でも、オンプレミスの NAS・ベアメタルサーバ・エッジ環境ではドライブ管理を自前で行う必要があります。運用担当者が「ディスクが壊れてから交換する」受動的な姿勢から「予兆を検知して計画交換する」能動的な姿勢へ転換するための道具として、smartmontools は依然として第一選択肢です。

本記事では smartd の設定・SMART 属性の閾値設計・systemd タイマーによる定期スキャン・交換判断フローを一本のシナリオとして整理します。

smartmontools の導入と基本確認

主要ディストリビューションのパッケージ名は smartmontools で統一されています。2026年現在の安定版は 7.4 系で、NVMe のサポートが大幅に改善されています。

インストール後、まず smartctl -i /dev/sda でドライブのデバイス情報を確認します。SMART support is: Enabled と表示されていれば準備完了です。無効の場合は smartctl -s on /dev/sda で有効化できます。ただし一部の仮想ディスクや USB 変換アダプタ経由の接続では SMART が利用できないため、事前確認は必須です。

現在の属性一覧を取得するには smartctl -A /dev/sda を実行します。出力の各行には属性 ID・属性名・現在値（Value）・最悪値（Worst）・閾値（Thresh）・生の値（Raw_Value）が並びます。現在値が閾値を下回ると SMART はその属性を「障害」と判定します。

NVMe の場合は smartctl -a /dev/nvme0 を使います。SAS/SCSI ドライブでは -d scsi オプションが必要になる場合があります。

SMART 属性の閾値設計と監視対象の選定

SMART 属性は 200 を超えますが、障害予測に有効と実証されている属性はそれほど多くありません。Backblaze 社の長期データや各ベンダの公開情報を参考にすると、以下の属性が特に重要視されています。

• ID 5 – Reallocated Sectors Count：代替セクタ数。ゼロ以外になったら要注意、増加傾向があれば交換を検討します。
• ID 187 – Reported Uncorrectable Errors：訂正不能エラーの累積数。増加は即座に警戒水準です。
• ID 188 – Command Timeout：コマンドタイムアウト数。ファームウェアの問題や接続不良との区別が必要です。
• ID 197 – Current Pending Sector Count：再読み取り待ちセクタ数。ゼロであることが正常です。
• ID 198 – Offline Uncorrectable Sector Count：オフラインスキャンで検出された訂正不能セクタ数。増加傾向は物理的劣化のサインです。
• ID 190 / 194 – Temperature：動作温度。HDD は 55℃ 以上、SSD は 70℃ 以上が継続すると寿命短縮の要因になります。

SSD 固有の属性としては ID 177（Wear Leveling Count）や ID 231（SSD Life Left）が重要です。NVMe では Percentage Used フィールドがメーカー定義の寿命消費率を示します。

閾値設計の基本方針は「ゼロであるべき値がゼロ以外になった時点でアラート」です。ID 5・197・198 は 1 以上でアラート、温度は環境に合わせた上限値を設定します。これらを /etc/smartd.conf に記述することで smartd デーモンによる継続監視が可能になります。

systemd タイマーによる定期スキャンの設計

smartd 自体も定期スキャン機能を持ちますが、systemd タイマーと組み合わせることでジャーナルへの統合・依存関係の管理・失敗時の再試行制御がより柔軟に行えます。特に複数台のサーバを Ansible 等で管理している現場では、Unit ファイルをテンプレートとして展開する運用が定着しています。

スキャン用スクリプト（例：/usr/local/bin/smart-check.sh）の中では smartctl -H /dev/sda で全体ヘルス判定を取得し、終了コードが 0 以外の場合に systemd の OnFailure= ハンドラや外部の通知スクリプトを呼び出すパターンが多く使われます。

タイマーの設計で検討すべき点は実行頻度とディスク負荷のバランスです。短時間テスト（-t short）は 1〜2 分で完了しほぼ影響がないため、毎日夜間に実行するのが現実的です。長時間テスト（-t long）はドライブ全面を読み取るため数時間かかり、業務時間外かつ I/O 負荷の少ない週次での実施が一般的です。

タイマーの RandomizedDelaySec を設定しておくと、複数台同時実行による I/O 集中を避けられます。また Persistent=true を指定すると、電源断によりスキャンが実行されなかった場合に次回起動時に補完実行されます。

アラートの通知先は smartd.conf の -m オプションによるメール送信が古典的な方法ですが、現場ではスクリプト内で curl を使って Slack Webhook や PagerDuty API を叩く構成に移行しているケースが増えています。

交換判断フローと切り戻し手順

SMART のアラートが発生した際に即座に交換するかどうかは、属性の種類・増加速度・システムの冗長性によって判断が変わります。以下のフローが現場での標準的な考え方に近いものです。

第1段階：初回検出 — ID 5・197・198 が 0 以外になったらフラグを立てます。増加していない単発値であれば、翌週のスキャンまで継続監視します。一方、ID 187 の発生や短時間での急増はより緊急度が高く、次のステップに進みます。

第2段階：長時間テストの実施 — smartctl -t long /dev/sda を手動実行し、完了後に smartctl -l selftest /dev/sda で結果を確認します。Completed without error 以外の結果は物理障害の可能性を示します。

第3段階：データの保護と交換準備 — RAID 環境であれば該当ドライブをデグレード状態のまま運用しつつ交換ドライブを調達します。単体ドライブの場合は直ちにバックアップを取得してから交換作業に入ります。LVM を使用している環境では pvmove でデータを退避してからドライブを除去する手順が安全です。

切り戻しの考え方 — 新ドライブへの交換後、badblocks -w による全面書き込みテストを実施してから本番復帰させる運用が確実です。ただし -w はデータを破壊するため、フォーマット前の空ドライブに対してのみ実行します。交換後も 1 週間程度は SMART の値を重点監視し、初期不良がないことを確認します。

2026年現在の環境差分と注意点

smartmontools 7.4 では NVMe の PCIe 5.0 対応デバイスへのサポートが改善されており、以前は正しく取得できなかった属性が読み取れるケースが増えています。ただし一部の OEM ドライブではベンダ固有の属性が標準の ID にマッピングされていないため、-v オプションで属性定義を上書きする必要があります。

RHEL 9 / AlmaLinux 9 / Rocky Linux 9 系では smartd が systemd のサービスとしてあらかじめ統合されており、旧来の /etc/init.d/smartd による管理は推奨されません。Ubuntu 24.04 LTS でも同様に systemd ベースの管理が標準です。

クラウド上の仮想インスタンスでは SMART が利用できないことが多いため、ハイパーバイザや各クラウドプロバイダが提供するディスクヘルス API（AWS の EBS Volume Status Checks、GCP の Disk Health Metrics 等）を代替として使用します。smartmontools はあくまで物理ドライブへの直接アクセスが可能な環境向けのツールです。

SSD の寿命管理については、TBW（Terabytes Written）の実績値を smartctl -A の Raw_Value から定期的に記録し、メーカー保証 TBW に対する消費率をトレンドとして追うことで、残り寿命の見積もりが可能です。この値を時系列データベース（Prometheus + Grafana 等）に蓄積する構成は、中規模以上の現場で広く採用されています。

SMART 監視はあくまで確率的な予測手段であり、100% の障害検知を保証するものではありません。SMART が正常値を示したまま突然障害が発生する事例も存在します。そのため、SMART 監視はバックアップ・RAID・定期的なファイルシステム検証といった多層防御の一要素として位置づけることが重要です。単独のセーフティネットとして過信しない運用方針が、長期的な可用性維持につながります。