ScrutinyでNASのHDDをSMART監視する：見るべき5項目と交換を決める基準

先に結論です。NAS の HDD は、Scrutiny を Docker で立てて SMART 値を毎日記録し、次の5項目が「0 から増えたか」を見るのがおすすめです。

• 5（Reallocated Sectors Count：代替処理済みのセクタ数）
• 187（Reported Uncorrectable Errors：訂正できなかったエラー）
• 188（Command Timeout：コマンドのタイムアウト）
• 197（Current Pending Sector Count：代替を待っている不安定なセクタ）
• 198（Offline Uncorrectable：オフライン検査で読めなかったセクタ）

これは、大量の HDD を運用しているクラウドストレージ企業の Backblaze が、故障の予兆として見ている5項目です。交換するかどうかは「値が出たか」より「増え続けているか」で決めます。Scrutiny は値の履歴をグラフで残せるので、この判断がしやすくなります。

Scrutiny は smartd の足りないところを埋めるツール

HDD の SMART は smartctl -a /dev/sda で読めますが、項目が数十個並ぶだけで、どれが重要かは書かれていません。smartd を使えばメール通知もできますが、過去の値と比べる仕組みは持っていません。

Scrutiny は、SMART 値を定期的に集めて InfluxDB に保存し、ディスクごとの状態と履歴をブラウザで見せてくれるオープンソースのツールです。特徴は次の3つです。

• 重要な項目とそうでない項目を分けて扱う
• メーカーの閾値だけでなく、Backblaze が公開している実際の故障率データをもとにした閾値で「passed／warning／failed」を判定する
• Discord・Telegram・ntfy・メールなど、多くの通知先に対応する

2026年9月末に v0.9.5 が出ており、いまも更新が続いています。

Docker Compose で立てる

ディスクが1台のマシンにまとまっているなら、Web 画面・収集役・データベースが1つになった omnibus 版が手軽です。公式の例をもとにすると、次のようになります。

services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:latest-omnibus
    container_name: scrutiny
    restart: unless-stopped
    cap_add:
      - SYS_RAWIO
    ports:
      - "8080:8080"
    volumes:
      - /run/udev:/run/udev:ro
      - ./config:/opt/scrutiny/config
      - ./influxdb:/opt/scrutiny/influxdb
    devices:
      - "/dev/sda"
      - "/dev/sdb"

押さえる点は3つです。

• devices に監視したいディスクをすべて書く。名前は lsblk や sudo smartctl --scan で確認します
• NVMe SSD も見るなら、cap_add に SYS_ADMIN を足し、/dev/nvme0 を devices に加える
• 公式の例には InfluxDB 用の 8086 番も載っていますが、InfluxDB の管理画面を使わないなら公開しなくて構いません

README では、latest ではなくバージョン付きのタグに固定することが勧められています。更新で挙動が変わるのを避けたい場合は、リリースページのタグ名に合わせて書き換えてください。

収集は既定で毎日0時（cron の 0 0 * * *）に動きます。立てた直後は画面が空なので、手動で1回集めます。

docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run

http://<サーバーのIP>:8080 を開き、ディスクが並べば完了です。

Proxmox を使っている場合は、物理ディスクがつながっているホスト側で動かすのが基本です。VM の中から見えるのは仮想ディスクなので、そのままでは本物の SMART は読めません。複数台のマシンを見たいときは、Web 画面と InfluxDB を1か所に置き、各マシンには収集役（collector）だけを置く構成も用意されています。

USB 接続のケースに入れた HDD は、変換チップによって SMART が読めないことがあります。表示されないディスクがあれば、まずホスト側で sudo smartctl -a が通るかを確認します。

見るべき5項目の意味

Backblaze は2016年の記事で、稼働中のドライブのうち5項目のどれかが 0 より大きかったのは 4.2%、故障したドライブでは 76.7% だったと公表しています。逆に言えば、故障したドライブの約4分の1は、この5項目に前兆が出ないまま壊れています。SMART 監視はバックアップの代わりにはならない、という前提で使います。

Backblaze 自身も、5項目のどれかが 0 より大きくなったら「調べる理由ができた」という扱いで、1つの値だけで即交換とはしていません。温度（194）も一緒に見ておくと、夏場の設置場所の見直しに役立ちます。

なお、188 はディスクそのものではなく、SATA ケーブルの接触や電源の不安定さで増えることもあるとされています。似た性質の 199（UDMA CRC Error Count）が増えている場合も、まずケーブルの交換を試すのが順番です。

交換を決める基準と通知の設定

私は次の基準で判断するのがよいと考えています。

1. SMART 自体の判定が FAILED：すぐに交換。先にバックアップが最新かを確認する
2. 197・198 が 0 から増えた：バックアップを確認し、1〜2週間グラフを見る。増え続けるなら交換
3. 5 が短期間に何度も増える：予備領域を使い続けている状態なので交換
4. 数個出たまま止まっている：様子見。ただし RAID を組んでいない1台構成なら早めに替える
5. 188・199 だけが増える：先にケーブル・電源を見直す

Scrutiny の判定（passed／warning／failed）は、SMART 自体の判定とは別物です。設定画面では、状態の判定に SMART・Scrutiny・その両方のどれを使うかを選べるとされています。Scrutiny の閾値は Backblaze の故障率をもとにしているため、機種によっては実際より厳しめに出ることがあるようです。scrutiny.yaml で項目ごとに閾値を上書きする方法も用意されていますが、最初は既定のまま様子を見るほうが安全です。

交換用には、NAS 向けの CMR 方式のモデルとして WD Red Plus や Seagate IronWolf が候補になります。

通知は config/scrutiny.yaml に通知先の URL を書きます。スマホに届けるなら ntfy が手軽です。

version: 1
notify:
  urls:
    - "ntfy://ntfy.sh/<推測されにくいトピック名>"

コンテナを再起動したら、次のコマンドでテスト通知を送れます。

curl -X POST http://localhost:8080/api/health/notify

ntfy.sh の公開サーバーは、トピック名を知っていれば誰でも読めます。トピック名は長く、ランダムな文字列にしておきます。

まとめ

• Scrutiny は SMART 値を毎日記録し、重要な項目と履歴をブラウザで見せてくれる
• Docker Compose の omnibus 版なら、devices にディスクを書いて SYS_RAWIO を付ければ動く
• 見るのは 5・187・188・197・198 の5項目。「出たか」より「増え続けているか」で判断する
• 188・199 は、ケーブルや電源が原因のこともある
• 故障の約4分の1は、5項目に前兆が出ないまま起きる。SMART 監視はバックアップと組み合わせて使う

運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳（無料 Lite 版あり） / IT 資格の学習管理シート