Posted inMonitoring

smartmontools ガイド：データが「昇天」する前に Linux ストレージの異常を検知する

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

ストレージが「突然死」してからデータ復旧に慌てないために

システム管理の仕事を始めたばかりの頃、忘れられない苦い経験があります。当時、私は Grafana で CPU や RAM の青々と輝くグラフを眺めることに夢中で、その下の物理レイヤーのことをすっかり忘れていました。ある晴れた朝、データベースサーバーがいきなり I/O エラー を吐き出し、そのまま動かなくなりました。結果は？ ハードディスクに深刻なバッドセクタが発生し、事前のハードウェア監視システムがなかったために、データはすべて壊れてしまいました。

実際、ストレージがいきなり壊れることは稀です。多くの場合、本当にダメになる前に S.M.A.R.T 指標を通じて「予兆」を出しています。IDC の物理サーバーであれ、ホームラボの古いマシンであれ、Linux サーバーを運用しているなら smartmontools のインストールは必須です。異音が聞こえ始めてから古いバックアップを探し回るような事態は避けましょう。

S.M.A.R.T と 2 つの強力なツール

S.M.A.R.T (Self-Monitoring, Analysis, and Reporting Technology) は、HDD/SSD 内部のブラックボックスのようなものです。動作温度から故障したセクタの数まで、あらゆる出来事を静かに記録しています。smartmontools パッケージは、主に 2 つの武器を提供してくれます：

  • smartctl: 能動的に「診察」を行い、情報の確認や即時のテスト実行に使用します。
  • smartd: バックグラウンドで動作するデーモンで、常に指標を監視し、異常の兆候があれば即座にアラートを飛ばします。

Netdata や Zabbix は非常に優秀ですが、smartmontools は依然として最もコアとなる基盤です。軽量で信頼性が高く、多くの中間レイヤーを通さずにディスクコントローラーと直接対話します。

インストールと smartctl の基本コマンド

インストールは、ほとんどの公式リポジトリに含まれているため、数秒で完了します：

# Ubuntu/Debian の場合
sudo apt update && sudo apt install smartmontools -y

# CentOS/RHEL/AlmaLinux の場合
sudo dnf install smartmontools -y

完了したら、システムがどのドライブを認識しているかスキャンしてみましょう：

sudo smartctl --scan

次に、S.M.A.R.T 機能が有効になっているか確認します：

sudo smartctl -i /dev/sda

SMART support is: Enabled と表示されれば OK です。もし Disabled になっていたら、sudo smartctl -s on /dev/sda コマンドですぐに有効化しましょう。

S.M.A.R.T「診断書」の読み方

健康状態の詳細なパラメータを確認するには、次のコマンドを使用します：

sudo smartctl -A /dev/sda

数字の羅列に圧倒されないでください。私の経験上、以下の 4 つの「致命的」な指標を重点的にチェックすれば十分です：

  • ID 5 (Reallocated_Sector_Ct): 代替処理済みのセクタ数。この数値が 1 週間で 0 から 10 に跳ね上がったら、新しいドライブを買う準備をしたほうがいいでしょう。
  • ID 187 (Reported_Uncorrect): ハードウェアで訂正不能なエラー数。この数値が 0 より大きくなった時点で、そのドライブの信頼性は失われ始めています。
  • ID 194 (Temperature_Celsius): HDD は通常 35-45°C で動作するのが理想です。頻繁に 55°C を超えるようだと、寿命が急激に縮まります。
  • ID 9 (Power_On_Hours): 総通電時間。エンタープライズ向けドライブでも、通常 30,000 から 50,000 時間を超えると「高齢」と見なされます。

能動的な健康診断テストの実行

数値を眺めるだけでなく、定期的にセルフテストを強制実行しましょう：

  • Short test: 約 2 分間実行され、電気系統と機械系統を迅速にチェックします。
  • Long test: ディスク表面全体をスキャンします。数 TB の容量がある場合、数時間かかることがあります。
# ショートテストを実行
sudo smartctl -t short /dev/sda

# テスト結果を確認
sudo smartctl -l selftest /dev/sda

smartd による自動化：毎晩安心して眠るために

毎日 SSH でログインして手動でチェックする暇な人はいません。smartd にその作業を任せましょう。自動スキャンを行い、メールやチャットアプリに通知するように設定します。

/etc/smartd.conf ファイルを開き、DEVICESCAN の行をコメントアウトしてから、各ドライブ固有の設定を追加します：

# 設定ファイルを編集
sudo nano /etc/smartd.conf

# sda の設定：毎日午前2時にショートテスト、日曜午前3時にロングテストを実行し、メール通知
/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m [email protected]

ここで、-s (S/../.././02|L/../../6/03) は、毎日午前 2 時に Short test を、毎週日曜日の午前 3 時に Long test を実行することを意味します。

修正後は、サービスを再起動するのを忘れないでください：

sudo systemctl restart smartd
sudo systemctl enable smartd

アラート疲れ（Alert Fatigue）を避けるコツ

最初は通知感度を高くしすぎて、バックアップ中のわずかな温度上昇でもメールが鳴り止まなくなってしまいました。そこから得た教訓は 2 つです：

  1. アラートの絞り込み: セクタエラーと訂正不能エラー（Uncorrectable Errors）のみに集中する。
  2. Telegram で通知を受け取る: メールは埋もれたりスパム扱いされたりしやすいです。スクリプトを使ってスマートフォンの Telegram に直接飛ばすのが最も効果的です。

参考までに、簡単な Telegram 通知スクリプトの例を紹介します：

#!/bin/bash
TOKEN="YOUR_BOT_TOKEN"
CHAT_ID="YOUR_CHAT_ID"
MESSAGE="$(hostname) の S.M.A.R.T アラート: $SMARTD_MESSAGE"

curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT_ID -d text="$MESSAGE"

おわりに

システム監視は、必ずしも高度なものである必要はありません。smartmontools のような質実剛健なツールひとつで、あなたの資産と労力を守ることができます。サーバーを管理しているなら、今すぐ SSH して適切なテストスケジュールを設定しましょう。データが消えてから後悔しても、大抵の場合は手遅れなのですから。

Share:
Tags: