以前、productionサーバーで4TBのHDDを何の警告もなく失ったことがある。理由は単純で、当時smartdをインストールしていなかったからだ。朝確認しに行くとRAID5がdegradedを報告しており、ログを引っ張り出すと、そのHDDは数週間前からReallocated Sectorsを何百も蓄積していた。S.M.A.R.Tは知っていたのに、誰も確認しなかったのだ。
それ以来、smartctlとsmartdについて真剣に調べ始めた。データセンターのDell PowerEdgeからNVMe搭載のVultr VPSまで、十数台のサーバーで6ヶ月間実際に運用して得た、最も重要な知見をまとめる。
HDDを監視する3つの方法——どれが適切かは状況次第
3つのアプローチがあり、それぞれ異なる状況に適している。間違った選択をすると無駄な手間がかかる。簡単に比較してみよう:
方法1:smartctlを手動実行
最もシンプルな方法——必要なときにコマンドを実行するだけだ。一度だけ素早く確認したいときや、疑わしいディスクをデバッグする際に適している。
# 概要情報を表示
sudo smartctl -a /dev/sda
# ショートself-testを実行(約2分)
sudo smartctl -t short /dev/sda
# self-testの結果を表示
sudo smartctl -l selftest /dev/sda
メリット:設定不要、即座に結果が得られる。
デメリット:能動的に確認しなければならない——sysadminは障害が発生するまでこれを実行することをほとんど忘れてしまう。
方法2:smartdデーモン——自動警告
smartdはバックグラウンドで動作し、スケジュールに従って全ディスクを自動的にポーリングし、異常を検知するとemail/syslogで通知する。物理サーバーすべてにデプロイしている。
メリット:set-and-forgetで確認を忘れても問題なく、完全な障害前に早期警告が得られる。
デメリット:サーバーでメールサーバーが動作している必要があり、VPSやコンテナには少しオーバースペックだ。
方法3:Exporter + Prometheus/Grafana
smartctl_exporterでメトリクスを公開し、Prometheusでスクレイプして、Grafanaでグラフ化する。すでに集中型の監視スタックがある場合に適している。
メリット:履歴の可視化、柔軟なアラートルール、既存の監視システムへの統合が可能。
デメリット:かなり重く、ディスク監視だけが目的なら割に合わない。
分析:S.M.A.R.Tで本当に重要なのは何か?
S.M.A.R.Tは数十の指標を列挙しているが、実際の運用では5〜6個を監視するだけで十分だ。以下の項目は、実際の障害前に現れるのを目撃したものだ:
- ID 5 — Reallocated_Sector_Ct:リマップされた不良セクター数。この数が増え続けているなら、ディスクは徐々に死に向かっている。危険な閾値:古いHDDで> 0なら要注意、> 10なら即交換。
- ID 187 — Reported_Uncorrect:修正不能なセクターエラー。0より大きい値はすべて懸念材料だ。
- ID 197 — Current_Pending_Sector:再チェック待ちのセクター——ディスクに問題が発生しつつあるサイン。
- ID 198 — Offline_Uncorrectable:197と似ているが、オフラインテスト中に検出されたもの。
- ID 190/194 — Temperature:温度。HDDは通常< 50°Cが安全、SSDは< 70°C。
sysadminを始めた頃、このようなエラーのデバッグに午後を丸々費やしたことがある。kernel bugによるfilesystemの破損だと思い込んでdmesgをずっと調べていたが、smartctl -aを実行してようやくReallocated_Sector_Ctが847に達していることに気づいた。
適切なアプローチを選ぶ
- 物理サーバー、NAS、デスクトップPC:smartdを使う。セットアップコストが低く、効果は高い。
- クラウドVPS(AWS、GCP、DigitalOcean):手動でsmartctlを使うか省略する——ハイパーバイザーは通常S.M.A.R.Tを完全に公開しない。
- ホームラボや多数のマシンがあるオフィス:綺麗なダッシュボードが欲しければPrometheus exporterを検討する。
- 中古HDDの売買前の一度限りの確認:
smartctl -aで十分。
デプロイ:smartdのインストールと設定
ステップ1:smartmontoolsのインストール
# Debian/Ubuntu
sudo apt install smartmontools -y
# RHEL/AlmaLinux/Rocky
sudo dnf install smartmontools -y
# Arch Linux
sudo pacman -S smartmontools
ステップ2:ディスクが認識されているか確認
# 全ディスクを一覧表示
lsblk -d -o NAME,SIZE,TYPE,ROTA
# SMARTサポートを確認
sudo smartctl -i /dev/sda
# RAIDコントローラー(LSI、HP Smart Array)配下のディスクの場合
# デバイスタイプを追加する必要がある。例:
sudo smartctl -d megaraid,0 -a /dev/sda
SMART support is: Enabledという行が表示されれば問題ない。Disabledの場合:
sudo smartctl -s on /dev/sda
ステップ3:smartctl -aの結果を読む
sudo smartctl -a /dev/sda
最も重要なのはSMART Attributes Data Structureの部分だ。VALUEカラムが現在値——高いほど良い。THRESHカラムはメーカーが設定した最小閾値。RAW_VALUEカラムが実際の生の数値だ。VALUEがTHRESHを下回ると、メーカーの基準でそのディスクは正式に失敗したことになる。
ステップ4:smartdの設定
メインの設定ファイルは/etc/smartd.confだ。productionではこの設定を使っている:
sudo nano /etc/smartd.conf
# 自動検出したATA/SCSIディスクをすべて監視
DEFAULTS -a -o on -S on -n standby,q \
-s (S/../.././02|L/../../6/03) \
-W 4,45,50 \
-m root \
-M exec /usr/share/smartmontools/smartd-runner
# 全ディスクを自動スキャン
DEVICESCAN
重要なオプションの説明:
-a:デフォルトの全チェックを有効化-o on:Automatic Offline Testingを有効化-S on:Attribute Autosaveを有効化-s (S/../.././02|L/../../6/03):毎日午前2時にショートテスト、土曜日の午前3時にロングテストを実行-W 4,45,50:温度が4°C上昇または45°C超過で警告、50°CでCritical-m root:rootにメールを送信
rootを経由せず直接メールを受け取りたい場合は、-m rootを-m [email protected]に変更する。サーバーから外部にメールを送信できるよう、postfixまたはmsmtpをインストールすることを忘れずに。
ステップ5:smartdの起動
# 起動して自動起動を有効化
sudo systemctl enable --now smartd
# 状態を確認
sudo systemctl status smartd
# ログを表示
sudo journalctl -u smartd -f
ステップ6:smartdが正常に動作していることを手動テストで確認
# テストメールをすぐに送信
sudo smartd -d -q onecheck
# /dev/sdbでショートテストを即時実行
sudo smartctl -t short /dev/sdb
# テスト結果を確認(約2分待機)
sudo smartctl -l selftest /dev/sdb
実際のシナリオへの対応
NVMe SSD
NVMeはHDD/SATA SSDと同じattribute formatを使用しない。-d nvmeを使う必要がある:
sudo smartctl -a -d nvme /dev/nvme0
NVMeではPercentage Used(使用済み寿命の割合)とAvailable Spare(残りのスペアブロック)に注意する。Available SpareがAvailable Spare Thresholdを下回ったら、交換計画を立てる必要がある。
USB接続のHDD(バックアップドライブ)
# USB-SATAブリッジは通常-d satが必要
sudo smartctl -d sat -a /dev/sdb
全ディスクを素早くチェックするスクリプト
このスクリプトは、全ディスクの状態をさっとスナップショットしたいときに使う——10秒で全体像が把握でき、長い出力を1ページずつ読む必要がない:
#!/bin/bash
for disk in $(lsblk -d -n -o NAME,TYPE | awk '$2=="disk"{print $1}'); do
echo "=== /dev/$disk ==="
sudo smartctl -H /dev/$disk 2>/dev/null | grep -E '(overall-health|SMART overall)'
sudo smartctl -A /dev/$disk 2>/dev/null | awk '$1 ~ /^(5|187|197|198|190|194)$/ {printf "ID%-4s %-35s %s\n", $1, $2, $NF}'
echo
done
出力はコンパクト——最も重要な6つのattributeのみ、raw valueつきですぐに比較できる。
まとめ
S.M.A.R.Tはオラクルではない——ディスクがいつ壊れるかを100%予測することはできない。しかし実際の経験では、障害が起きたディスクの約80%はS.M.A.R.Tに数日から数週間前からサインが現れていた。smartdはその貴重な時間を見逃さないようにしてくれる。
システム全体のセットアップにかかるのはわずか約15分だが、午前2時にバックアップをリストアする眠れない夜を避けることができる。これは苦い経験から言っている。
