この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
SE3年目の秋のことです。そのひと言から調べ始めて、初めてLinuxサーバーのHDD障害に向き合うことになりました。「まさか自分の担当サーバーで起きるとは」という驚きと、気づくのがもう少し遅かったらどうなっていたかという恐怖は、今でも鮮明に覚えています。
この記事では、その体験をもとに、20年以上Linuxサーバーを運用してきた経験から、ディスク障害の予兆をどう掴むか、そして今も続けている定期点検の習慣をお伝えします。
この記事のポイント
・ディスク障害は「壊れた瞬間」ではなく、予兆の段階で気づける
・dmesgのI/Oエラーが最初の警告サインになる
・S.M.A.R.T.の数値を「正常時」から記録しておくことが鍵
・「動いている」と「健全に動いている」は全く別物と心得ること
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「なんとなく遅い」という苦情が来た朝
あれはSE3年目の秋でした。ファイルサーバーの管理を任されて半年が経ったころ、別の部署の担当者からこう言われました。「ファイルサーバーへのアクセスが、最近なんとなく遅い気がする」
「なんとなく」という言葉が気になりました。「繋がらない」ではない。しかしその曖昧な一言が、何かを知らせているような気がして、私はすぐに確認に向かいました。
セミナーで3,100名以上を指導してきた中で、こうした「なんとなくおかしい」という感覚を大切にできる人は、ディスク障害を早期に発見できることが多いと気づきました。明確なエラーではないからこそ見過ごしがちですが、その曖昧さの正体が物理障害の予兆であることは決して珍しくありません。
初めてHDDの「限界」に向き合うまで
1. dmesgに現れていた無数の警告
ターミナルを開いて、まず確認したのは dmesg の出力でした。見慣れた画面のはずが、その日は今まで見たことのない行が大量に流れていました。# dmesg | grep -i error | tail -20 end_request: I/O error, dev sdb, sector 1085344 Buffer I/O error on device sdb2, logical block 2034 end_request: I/O error, dev sdb, sector 1085348 end_request: I/O error, dev sdb, sector 1085360 EXT3-fs error (device sdb2): ext3_get_inode_loc: ...
同時に、もう少し気づくのが遅かったらどうなっていたか、という恐怖も湧いてきました。ディスクが完全に応答しなくなってから気づいていたら、データのリカバリは格段に難しくなっていたはずです。
2. smartctlが示した限界間際の数値
次に smartctl コマンドで S.M.A.R.T. の情報を確認しました。当時初めてその出力を見て、特定の数値に目が止まりました。# smartctl -a /dev/sdb | grep -E "Reallocated|Pending|Uncorrectable" 5 Reallocated_Sector_Ct 0x0033 082 082 036 Pre-fail Always - 182 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 14 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 3
一人で数値を眺めながら、「今日気づいてよかった」と心から思いました。
3. 先輩から言われた一言が、その後の習慣を作った
状況を先輩に報告すると、こう言われました。「毎日確認してたら、1週間前には気づけてたな」
責める口調ではありませんでしたが、その言葉は刺さりました。障害が起きてから対応するのではなく、予兆の段階で把握しておくことが、サーバー管理者の仕事だと気づいた瞬間でした。
幸いにもデータのバックアップは別のディスクに取れていたため、ハードウェア担当と連携してディスク交換を行い、無事に復旧できました。ただ「バックアップがなかったら」と考えるだけで、今でも背筋が冷たくなります。
あの日以来20年間続けている定期点検の3つの習慣
20年以上サーバーを運用してきた経験から言うと、ディスク障害は「いつか来るもの」ではなく「必ず来るもの」です。問題は、それがいつかを予測できるかどうかです。以下の3つの習慣が、私が今も欠かさずに続けているものです。1. 週次でdmesgのエラーを確認する
週に1回、担当サーバーの dmesg を確認することを習慣にしています。確認するのは I/O error、SCSI error、disk error など、ディスク関連のキーワードです。・正常時は該当行がゼロ
・数件程度でも出ていたら「要注意」として記録しておく
・10件以上、または繰り返し出る場合はすぐにアクションを取る
エラー件数そのものより、「先週より増えているかどうか」の変化に敏感になることが大切です。
2. S.M.A.R.T.の主要値を「正常時」から記録しておく
ディスク導入直後に smartctl で主要な属性値を記録しておきます。特に Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable の3項目は、0 からどれだけ増加したかを追うことが重要です。これらが増加し始めたら、「そろそろ交換を準備する」判断基準にします。障害が起きてから交換するのでは遅い。予兆を掴んで先手を打つことが、サーバー管理者として当然の責任です。
3. 「動いている」で安心しない目を持つ
サーバーは、限界が近づいても「一見正常に動いている」ように見えることがあります。I/Oエラーが出始めても、処理が若干遅くなるだけで、ユーザーには「なんとなく遅い」としか伝わらないことも多い。「サービスが動いている = 健全に動いている」ではありません。この二つを区別できる目を持つことが、障害を未然に防ぐエンジニアになる第一歩です。
ディスク障害とバックアップの重要性についての関連記事も、ぜひあわせてご覧ください。
・Linuxでバックアップから初めてリストアした日の話
・Linuxの本番サーバー作業でヒヤリハットした経験談
まとめ
・ディスク障害は「壊れた瞬間」ではなく予兆の段階で気づける・dmesg の I/Oエラーを週次で確認することが早期発見の鍵
・S.M.A.R.T.の主要3項目を正常時から記録しておくことが重要
・「動いている」と「健全に動いている」は全く別物と心得ること
「なんとなく遅い」という一言を侮らなかったあの日の判断が、大きな障害を未然に防げた理由でした。サーバー管理者として長く現場に立ってきた中で、ディスク障害の予兆を掴む習慣ほど、地味で確実に役立つものはないと実感しています。
今担当しているサーバーで、dmesg を最後に確認したのはいつですか。まずその一歩から始めてみてください。
ディスク障害を未然に防ぐ「サーバー管理の基礎」を体系的に身につけませんか？
サーバー運用で本当に怖いのは、予兆に気づかないまま障害当日を迎えることです。dmesgの読み方、S.M.A.R.T.の確認手順、バックアップ設計の考え方。こうした「現場で使える判断力」を体系的に学ぶことが、長期間サーバーを安全に運用し続けるエンジニアへの最短経路です。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます