Linux EIO (5) 対策：I/O エラー発生時のハードウェア診断とデータ復旧編

【注意】本記事は、LinuxにおけるEIO（Input/output error）発生時の一般的な考え方と手順を整理した情報提供です。実環境では機器構成・負荷・RAID/仮想化・運用要件によって最適解が変わります。重要データを扱う場合や障害が進行している可能性がある場合は、判断を誤ると復旧難易度が上がることがあります。個別案件の切り分け・復旧方針の設計・作業手順の安全化については、株式会社情報工学研究所のような専門家への相談をご検討ください。

第1章：EIOは「原因」ではなく「症状」──まずやるべき“被害最小化”の一次対応

現場で EIO（errno=5）が出た瞬間、頭の中ってこうなりませんか。

「え、ディスク死んだ？ でも今夜のバッチ…止められない…」「とりあえず再起動で直るやつ？…いや、直ったとしても“何が起きたか”が分からないのが一番怖い」

このモヤモヤは自然です。なぜなら EIO は“原因名”ではなく、“I/O が成立しなかった”という症状のラベルだからです。アプリ層から見ると「読み書きできない」という一点に見えますが、実際にはストレージの物理層、ケーブル、コントローラ、ドライバ、ファイルシステム、RAID、仮想化基盤など複数の層で発生し得ます。ここで最初に狙うべきゴールは、正解の断定ではなく「これ以上状況を悪化させない」こと、つまりダメージコントロールです。

まず守る“3つの原則”

EIOが出たら、一次対応は次の3つに集約されます。派手さはありませんが、この3つを守れるかどうかで復旧ルートが変わります。

• 書き込みを増やさない：原因が物理障害・メディア劣化・コントローラ不調の場合、追加書き込みは症状を加速させます。
• 証拠（ログと状態）を残す：あとで「いつ」「どこで」「どの層が」崩れたかを辿れないと、再発防止も復旧もブレます。
• 切り分けは“安全側”に倒す：不確実なら、まず保全（イメージ取得）を優先できる設計に寄せます。

「でも、現場は止められないんだよ…」という声も分かります。だからこそ“止める/止めない”の二択ではなく、リスクを下げる順番で考えます。

最初にやるチェック：影響範囲と“今も進行しているか”

同じEIOでも、単発の読み取り失敗と、連鎖的に失敗が増えているケースでは緊急度が違います。ここで重要なのは「障害が進行中かどうか」を早めに見極めることです。

この段階では“断定”はしません。代わりに、次章以降で使うための伏線として、ログの採取と作業方針の優先度を固めます。

ログ採取の最低ライン：あとから再現できる形にする

「ログは後で見る」と言っていると、再起動や自動回復で状況が変わってしまいます。最低限、次の情報は早めに確保しておくと、切り分けのスピードが上がります。

• 直近のカーネルログ（dmesg相当）
• systemd環境なら journalctl の該当期間
• どのデバイス（/dev/sdX 等）とマウントポイントが関連しているか
• RAID/LVM/暗号化/仮想ディスクの有無（“層”の把握）

ここでのポイントは「誰が見ても追える形」にしておくことです。属人化していると、引き継ぎ時に判断がブレて、余計な操作（不要なfsckや再構築）に寄りやすくなります。

この章のまとめ：EIO対応の“勝ち筋”は、最初の10分で決まる

EIOは怖いですが、怖さの正体は「症状が同じでも原因が違う」ことです。だから最初は“正解探し”より、被害最小化と証拠の確保を優先します。次章では、現場でやりがちな初動（再起動、fsck、再マウントなど）がなぜ地雷になり得るのかを、技術的に整理します。

第2章：やってはいけない初動──fsck／再起動／再マウントが“歯止め”にならない理由

EIOが出た直後、現場でよく起きる会話があります。

「とりあえず再起動しよう。直ることあるし」「fsck回せば整合性取れて戻るのでは？」「マウントし直したらいけるかも」

この判断、責められるものではありません。平時の運用では、確かに“再起動で直る不調”もあります。ただし、EIOが絡むケースでは、これらが“収束”ではなく悪化に向かうことがある。ここを冷静に分解します。

再起動が危険になり得るパターン

再起動は「状態を初期化して復帰する」手段ですが、ストレージ障害では次のリスクがあります。

• ログと状態の消失：直前のエラー連鎖や、タイムアウトの前兆が追いにくくなる。
• 起動時の追加I/O：ジャーナルリプレイ、サービス起動、キャッシュ再構築などで読み書きが増える。
• 自動修復が走る：環境によっては起動時チェックや、アプリ側の自動再同期が始まり、保全前に書き換えが進む。

つまり再起動は“万能リセット”ではなく、障害が進行している場合は、状況をかき回す操作になり得ます。もちろん、業務継続上どうしても必要な再起動があるのも現実です。その場合は、再起動前にログ確保、そして可能なら影響範囲の縮小（サービス停止・対象ボリュームの切り離し）を先に考えます。

fsckが地雷になり得る理由：整合性修復＝書き込み

fsck（ファイルシステムチェック）は、整合性が崩れたときに強力ですが、基本的にメタデータの修復＝書き込みを伴います。ディスクが不安定な状態で書き込みを増やすと、次の悪循環に入ることがあります。

• 読み取りエラーが出る → 修復のために追加読み取り/書き込みが増える
• 不良セクタやタイムアウトが増える → fsckが長時間化する
• 途中で止まる/再試行が増える → さらにI/Oが増える

「整合性さえ直れば戻るはず」という期待は分かります。しかし、EIOの背景が物理・リンク・コントローラ由来の場合、fsckは根本原因を直さずにI/Oを増やす方向へ振れます。結果として、復旧のために本来取りたかった“安全な読み出し”が難しくなることがあります。

再マウント／rw↔ro切替が危険になり得る理由

LinuxはI/O異常の検知時に、ファイルシステムを保護するために読み取り専用（ro）へ落とす場合があります。ここで「rwで再マウントして書き込みを続ける」判断は、短期的には業務が回るように見えても、長期的には損失・流出（＝データ欠損）が増えやすいです。

現場目線で言うと、こういう独り言が出てきます。

「今だけ書ければ助かるんだけど…この先に地獄が待ってそうで嫌だ」

その勘はだいたい正しいです。I/Oが不安定な状態で“とにかく継続”すると、アプリは成功/失敗を繰り返し、結果的に整合性が崩れた状態が積み上がることがあります。

代わりに何をするべきか：安全側の手順に“ブレーキ”をかける

禁止したいのは「再起動」や「fsck」そのものではなく、保全や切り分けより先にそれを実行してしまう順番です。EIOが出たら、次の順番を基本形にすると判断が安定します。

1. ログ確保（後追い可能な形で残す）
2. 影響範囲の把握（どのボリューム/サービスが該当か）
3. 不要な書き込みの抑え込み（サービス停止・対象分離の検討）
4. 原因層の切り分け（次章：ログから“どこで落ちたか”を見る）
5. 必要なら保全（安全なイメージ取得）を優先して復旧へ

この順番が守れれば、fsckが有効な局面では有効に使えますし、再起動が必要な局面でも“戻し方”を設計できます。逆に順番を誤ると、復旧は運任せになりがちです。

この章のまとめ：焦りが判断を雑にする。順番を固定して“場を整える”

EIO対応で一番の敵は、技術不足よりも「焦りで順番が崩れること」です。再起動・fsck・再マウントは、状況によっては正解にもなりますが、保全と切り分けより先に走ると、歯止めにならないどころか悪化の引き金になります。次章では、dmesg/journalctlから“どの層で落ちているか”を読む具体像を、現場で使える形に落とします。

第3章：dmesg・journalctlで読むI/O失敗点──「どの層で落ちたか」を特定する

EIOが出たとき、最初に見るべきは「アプリの例外ログ」よりも、カーネル側のメッセージです。ここでやることは単純で、“失敗した場所（層）”を当てにいくことです。

現場の心の声としてはこうです。

「アプリが落ちたのは分かった。で、下で何が起きた？ どこから疑えばいい？」

この問いに答える材料が、dmesg（カーネルログ）やjournalctl（systemd環境のログ）です。EIOは最終的にユーザー空間へ返ってきますが、原因の手がかりはその直前にカーネルが喋っていることが多いです。

まず“デバイス名”と“タイムライン”を押さえる

ログでは、/dev/sdX、nvme0n1、dm-0、md0のような表記が出ます。ここで大事なのは「アプリが触っている論理ボリューム」と「実体のブロックデバイス」がズレることがある点です（LVM/暗号化/RAID/仮想化があると特に）。

したがって、ログを読む順序は、

• いつ（時刻：エラーが増え始めたタイミング）
• どれ（デバイス：sdX / nvme / dm / md）
• 何が（reset / timeout / media error / filesystem error）

の3点セットです。特に「reset」「timeout」「I/O error」が連鎖している場合は、障害が進行中のサインになり得ます。

ログの典型パターン：どの層の言葉かで分類する

EIOを引き起こすログは多様ですが、分類の軸はシンプルです。物理/リンク（SATA/SAS/NVMe）→ブロック層→ファイルシステム層のどこで“失敗が確定したか”を見ます。

ここでの注意点は、ファイルシステムのエラーメッセージが出ていても、必ずしも「ファイルシステムが原因」とは限らないことです。下層のI/Oが欠けた結果として、上層が整合性を失っているケースが多いからです。

“誰がI/Oしていたか”を見て、復旧方針に伏線を張る

EIOが出たとき、もう一つ大事なのは「そのI/Oは読取りか書込みか」です。ログにop（READ/WRITE）や、失敗が多いタイミング（夜間バッチ、バックアップ、DBのチェックポイント等）が見えるなら、負荷と障害の相関が疑えます。

現場のあるあるとして、

「昼は平気なのに、深夜のバックアップでだけ落ちる」

というケースがあります。これは“容量が大きい連続読み書き”で初めて症状が出る、つまり平常運転では見えない不安定さがある可能性を示します。ここまで読めると、次章のSMART診断や、第8章の保全（イメージ取得）に自然につながります。

この章のまとめ：ログは「犯人探し」ではなく「層の特定」に使う

EIO対応でログを見る目的は、断定ではなく、疑う範囲を狭めて“次の一手”を安全化することです。どの層で落ちているかが見えれば、ディスク単体を疑うのか、リンク・HBA・電源やバックプレーンまで視野に入れるのか、そして「保全を先にするべきか」が決めやすくなります。次章では、SMART情報を“診断”に変える読み方を整理します。

第4章：SMARTの読み方を“診断”にする──再割当・UNC・温度・履歴の解釈

ログで“怪しい層”の当たりが付いたら、次はストレージの自己診断情報（SMART）を確認します。ただしSMARTは、数値を見ただけで即断できる魔法の指標ではありません。正しい使い方は「単発の良否判定」ではなく「傾向と整合性」を読むことです。

エンジニアの本音としてはこうです。

「SMARTって結局“PASSED”って出ること多くない？ それでも壊れるじゃん」

その疑いは健全です。だからこそ、PASSED/FAILEDだけで終わらせず、“どの種類のエラーが増えているか”を読み、ログと突き合わせて因果の筋を通します。

見るべきは「増えたかどうか」：カウンタ型指標の扱い

HDD/SSD（SATA系）で特に注目されることが多い代表例を、診断観点で整理します（名称はベンダで多少異なります）。

ポイントは、閾値を一発で決めることよりも、「昨日と比べて増えたか」「ログの症状と整合するか」です。例えば、EIOが増えていて Pending/Uncorrectable も増えているなら、媒体側の読み出し困難が疑われます。一方で、EIOが出ているのにCRCだけが増えているなら、リンク側（ケーブル等）が疑わしい、というように次の打ち手が変わります。

NVMe/SSDでは“別の指標”も見る

NVMeは表現がSATAのSMART属性と違うため、見方がズレやすいです。代表的には、メディアエラー数やエラーログのエントリ数、コントローラのリセット/タイムアウトの痕跡などを確認し、カーネルログ（nvme resetやtimeout）と合わせて読みます。

ここでも重要なのは「単発の値」より「増加」「再現性」です。たとえば、負荷をかけたときだけタイムアウトが出るなら、熱、電源、PCIe経路、ファームウェア要因など“ディスク以外”の可能性も残ります。

SMARTが取れない・信頼しにくいケースもある

RAIDコントローラ配下や、特定の外付けケースなどではSMARTが素直に見えない場合があります。また、SMARTは“未来予知”ではないため、明確な異常値が出ないまま故障が顕在化することもあります。

だからこそSMARTは「唯一の判決」ではなく、ログ・症状・構成と組み合わせる部品です。この組み合わせができると、次の章で扱う「ケーブルやHBAが犯人」のケースも早めに気づけます。

この章のまとめ：SMARTは“判定”ではなく“状況説明”の材料

SMARTは、EIOの背景を説明する強い材料になり得ますが、単独で万能ではありません。増加傾向とログの整合性を見ることで、媒体劣化なのか、リンク不良なのか、別要因なのかを絞り込めます。次章では「ディスクを交換しても直らない」典型として、ケーブル/ポート/電源/HBAなど“周辺要因”を整理します。

第5章：ケーブル／ポート／電源／HBAの落とし穴──「ディスク以外」が犯人のケース

現場で本当にやっかいなのは、「ディスクを交換したのにEIOが再発する」パターンです。ここで空気が悪くなります。

「交換したよね？ なんでまた…」「次は何を疑えばいいの？」

この状況で必要なのは、誰かの責任探しではなく、原因の候補を体系的に並べて“収束”へ持っていくことです。EIOはI/O失敗の結果なので、媒体以外にも犯人がいます。

リンク系トラブルの代表：ケーブル・ポート・バックプレーン

ケーブルやポートの不良、バックプレーン（ホットスワップベイ）やエキスパンダの不調は、症状が「ディスク障害っぽく」見えます。特にSATA/SASでは、リンクが不安定になるとタイムアウト→リセット→再試行→I/O失敗、という流れになりやすいです。

第4章で触れたCRC系のカウンタ増加が見える場合、媒体よりもリンク品質（配線・接触・振動・劣化）に寄ります。ここでの現実的な対処は、原因を“理屈で完全に証明する”より、交換・差し替えで再現性を潰すことです（ただし作業は計画的に。ホットスワップや再認識でI/Oが増え、悪化するケースもあるためです）。

電源・瞬断・電圧降下：ログに出にくいのに破壊力がある

ストレージ周りで見落とされがちなのが電源です。電源ユニットやケーブル、電源冗長の片系不調、ラックのPDU、UPSの劣化などが絡むと、一瞬の不安定がI/Oタイムアウトとして現れます。しかも、この手の問題は「その瞬間」のログが薄いことがあります。

「夜間だけ起きる」「特定の負荷（バックアップ/スナップショット）で起きる」場合、電源や熱の余裕がない可能性も疑います。ここでのポイントは、アプリやOSだけではなく、筐体・ラック・電源系の運用情報も含めて時系列を作ることです。役員説明が難しいときも、時系列があると“説明可能性”が上がります。

HBA/RAIDコントローラ/ファームウェア：交換しても残る“共通因子”

ディスク交換で直らないとき、共通因子として残るのがHBAやRAIDコントローラ、ドライバ、ファームウェアです。ここが不安定だと、複数ディスクにまたがってタイムアウトやリセットが見えることがあります。

ただし、ここで注意したいのは「闇雲な更新」です。ファーム更新は有効な手段になり得ますが、業務影響が大きい環境では検証計画が必要です。

• 現象の再現条件（負荷・時間帯・I/Oパターン）
• ログ上の特徴（resetが誰を起点に起きるか）
• 構成（RAIDレベル、キュー深度、キャッシュ設定、BBU/フラッシュバック）

これらが揃っていないと、更新して良くなったのか、偶然落ち着いたのか判断できません。つまり“場を整える”ことが、結局いちばん速いです。

この章のまとめ：交換で直らないなら、原因は「共通部分」に寄っている

ディスク交換で改善しないEIOは、リンク・電源・バックプレーン・HBA/コントローラといった“共通部分”が疑わしいことが多いです。ここまで来ると、現場だけで抱えるのがしんどくなります。ログ・SMART・構成・負荷条件を整理できているほど、次の章以降（ファイルシステムの見え方、保全、復旧計画）を安全に進められます。次は、ext4/XFSなどファイルシステム側の視点で「何が起きているように見えるか」を整理します。

第6章：ファイルシステム視点の切り分け──ext4／XFSと「読み取り専用化」が意味すること

EIOが表に出ると、アプリはもちろん、ファイルシステムも“異常”として反応します。ここで現場が困るのが、ログに出てくるメッセージが「原因」に見えてしまうことです。

「EXT4-fs error って書いてある…じゃあ ext4 が壊れた？」「XFS metadata error…メタデータが壊れたなら復旧無理？」

その不安は自然ですが、ファイルシステムのエラーは下層I/O失敗の“結果”として出ていることが少なくありません。第3章で触れた通り、層を分けて読むと判断が安定します。

ext4とXFSの“守り方”の違いを理解する

ext4もXFSもジャーナリングや整合性維持の仕組みを持ちますが、異常I/O時の見え方や挙動は同じではありません。重要なのは「どちらが優れているか」ではなく、異常時に何が起きたように見えるかを理解しておくことです。

どちらにしても、ファイルシステムは「これ以上書くと危ない」という局面で、読み取り専用化やエラー連発としてサインを出します。これは邪魔ではなく、被害最小化のためのブレーキです。

「読み取り専用化（ro）」は“負け”ではなく、状況整理のチャンス

現場だと、roに落ちると一気に緊張感が上がります。

「書けない＝サービス停止じゃん…」「とりあえずrwに戻したい」

ただ、roへの遷移は“守り”として働いている可能性があります。rwに戻すこと自体が常に悪ではありませんが、戻す前に次の確認をしておくと、後工程（保全・復旧・再発防止）が現実的になります。

• なぜroに落ちたか：直前のI/Oエラーやタイムアウト、リセットの連鎖があるか
• 対象が単一ボリュームか：RAID/LVM/仮想ディスクなど“下に何がいるか”
• 書き込みを止めた場合の業務影響：止める範囲を狭められないか（特定サービスのみ停止など）

この章のまとめ：ファイルシステムのエラーは“原因の確定”ではなく“層の観察”

ext4/XFSのエラーは、下層のI/O欠損が上層に波及した結果として出ていることが多いです。読み取り専用化やエラー連発は、復旧を遠ざける邪魔ではなく、状況を整える合図になり得ます。次章では、ここまでの情報を使って「どこまで壊れているか」を定量化し、復旧方針を決めやすくします。

第7章：影響範囲を定量化する──「進行中障害」を見抜く読み取り検証の考え方

EIO対応でつらいのは、「直ったのか、たまたま静かになっただけなのか」が分からないことです。ここで必要なのは、気合ではなく定量化です。

「交換したし、ログも落ち着いた。…でも、明日また出たら説明できない」

この不安に答えるのが、影響範囲の把握と読み取り検証です。目的は“完全診断”ではありません。リスクの濃淡を見える化して、次の一手に歯止めをかけることです。

定量化の軸は2つ：「局所」か「広域」か／「再現」するか

EIOが局所（特定ファイル、特定ディレクトリ、特定LBA付近）に偏っているのか、広域（全体的に遅い、各所で失敗）なのかで、復旧の戦略が変わります。また、再現性があるなら原因層の特定が進みます。

読み取り検証は「安全な範囲」から：書き込みを増やさない設計

検証でやりがちなのが、「ついでに修復」「ついでに整理」「ついでにバックアップ」です。これが状況を悪化させることがあります。検証はあくまで、読み取り中心・最小限の負荷で行い、「何がどれだけ怪しいか」を見るのが主眼です。

• 時間帯を選ぶ：業務ピークを避け、追加負荷による誤判定を減らす
• 範囲を限定する：全領域スキャンに飛びつかず、代表領域や重要データ周辺から
• エラー率・遅延：失敗の件数だけでなく、極端な遅延（タイムアウト寸前）が増えていないか

ここで「検証でエラーが増える」なら、障害が進行している可能性が上がります。逆に「検証は通るが、特定の負荷で落ちる」なら、電源や温度、リンク不安定のような“条件依存”が疑えます。

この章のまとめ：定量化は、説明責任と復旧戦略の両方を楽にする

EIO対応は、技術だけでなく「説明」が難しい領域です。影響範囲と再現性を定量化できると、上司・役員への報告も、復旧の優先順位付けも、急に現実的になります。次章では、ここまでの伏線を回収する形で、データ復旧で最も重要になりやすい“保全（イメージ取得）”の設計を整理します。

第8章：復旧の伏線は“保全”にある──イメージ取得を先にやる設計（ddrescue等）

EIOが絡む復旧で、最終的に差が付くのは「復旧ツールの腕前」よりも、保全の設計であることが多いです。ここで言う保全とは、現物に対して試行錯誤を繰り返すのではなく、まず安全に読み出せる範囲を複製（イメージ化）し、作業を“コピー側”で進める考え方です。

現場の本音はこうです。

「結局、触れば触るほど壊れそう。じゃあどうすればいいの？」

その答えが、保全です。これはフォレンジックでもデータ復旧でも基本で、理由はシンプルです。現物は一つ、やり直しが利かないからです。

なぜイメージ取得が効くのか：現物へのアクセス回数を“抑え込み”できる

障害ディスクは、読み取りに成功したり失敗したりします。現物に対して「何度も同じファイルを読み直す」「復旧ツールを変えて何回も走らせる」と、そのぶんI/Oが増え、症状が進むことがあります。

一方、イメージ（複製）が作れてしまえば、試行錯誤はコピー側で行えます。現物に対するアクセスは、一回（または最小回数）に近づけることができます。これが被害最小化に直結します。

「速く全部読む」ではなく「読めるところから確保する」

ここで重要なのは、完璧主義を捨てることです。EIOのある媒体は、全領域を均等に読めるとは限りません。読みやすい領域を先に確保し、難所は後回しにする、という発想が現実的です。

• 先に“取れるデータ”を確保：重要データの喪失リスクを下げる
• 難所は後で戦う：エラーの多い領域に突っ込み続けない
• 進行度を記録：どこが読めた/読めないのかを後で説明できる

この「読めるところから確保する」思想は、専用ツール（例：ddrescueのように、読めた範囲と未読範囲を記録しながら進めるタイプ）と相性が良いです。ただし、環境や構成によっては単純ではありません。RAIDや暗号化、仮想ディスクの上に乗っている場合、イメージの取り方そのものが設計課題になります（この点は次章で扱います）。

保全で“必ず一緒に残すもの”：構成情報と時点情報

イメージだけ取っても、構成が分からなければ復元できないケースがあります。したがって保全では「データ」と同じくらい「情報」を残します。

• 構成情報：RAIDレベル、ディスク順序、LVM構成、暗号化の有無、仮想化ストレージの種別
• 時点情報：いつ取得したか、取得時のログの状況、エラーの頻度
• 整合確認：可能な範囲でハッシュ等により“同一性”を説明できる形にする

このあたりから、「一般論だけでは決められない」領域が増えてきます。業務を止められない制約、構成の複雑さ、保全先ストレージの容量、取り外し可否など、現場ごとの条件で最適解が変わるからです。だからこそ、後半で“専門家に相談すべき理由”が自然につながってきます。

この章のまとめ：復旧の成否は、保全で“軟着陸”できるかにかかる

EIOのある復旧は、現物に試行錯誤を積むほど苦しくなることがあります。まず保全して、現物へのアクセスを抑え込み、コピー側で判断と作業を進める。これが復旧を軟着陸させる基本戦略です。次章では、RAID/LVM/仮想化が絡むと保全と復旧がどう難しくなるのか、そして「再構築より先に確認すべきこと」を整理します。

第9章：RAID／LVM／仮想化で複雑化するEIO──再構築より先に確認すべき依存関係

EIOが出ている環境が、単体ディスクとは限りません。むしろ現場では、RAID（ハード/ソフト）、LVM、暗号化、仮想化ストレージの上にアプリが載っていて、「見えている/devが“本体”ではない」ことが普通です。

ここで空気が過熱しやすいのが、次の場面です。

「RAIDがdegradedになってる。とりあえず再構築（rebuild）回す？」「とにかく冗長性を戻したい」

気持ちは分かります。ただ、EIOが絡むときに再構築を急ぐと、状況が収束せずに悪化することがあります。理由は単純で、再構築や再同期は大量の読み書きを発生させ、もともと不安定な層に強い負荷を掛けるからです。

“見えているエラー”がどの層のものかを整理する

複合構成では、同じEIOでも「どの層でI/Oが欠けたか」によって、打つ手が変わります。まずは依存関係を言語化します。

• 物理ディスク（HDD/SSD/NVMe）
• コントローラ（HBA/RAIDカード/バックプレーン）
• RAID層（mdadmやハードRAID）
• 暗号化（dm-crypt等）
• LVM（PV/VG/LV、thin等）
• ファイルシステム（ext4/XFS等）
• 仮想ディスク（VMのvmdk等、コンテナの永続ボリューム等）

この“積み上げ”があると、/dev/dm-0でEIOが出たときに、下層のどこへ降りて確認すべきかが見えます。逆に、この整理がないまま作業を始めると、復旧したいデータの土台を自分で揺らしてしまうことがあります。

再構築（rebuild）や再同期（resync）を急ぐと危ない理由

冗長性を戻す行為は、本来は正しいです。しかし“障害が進行中”のときは、再構築が引き金になり得ます。

• 負荷が跳ね上がる：全ディスクを横断して読み、再計算し、書き込むため、I/Oが増える。
• 潜在不良が露見する：普段読まない領域を読むことで、別ディスクの読み取り困難が表面化しやすい。
• タイムアウトが連鎖する：リンクや電源、コントローラが不安定だと、再試行が増えて全体が遅くなる。

要するに、再構築は“健康診断と筋トレを同時にやる”ようなもので、体調が悪いときにやると倒れます。ここで必要なのは、再構築の是非そのものより、再構築の前に保全や切り分けで歯止めを掛けられているかです。

保全の単位を間違えない：ディスク単体か、RAIDの論理単位か

保全（イメージ取得）も、複合構成では設計が要ります。単体ディスクをそのまま複製すべきか、RAIDの論理ボリューム（アレイとして見えているデバイス）を複製すべきかは、構成と障害点で変わります。

例えば、RAIDカード配下で個別ディスクへ素直にアクセスできない場合や、論理ボリュームとしての読み出しが比較的安定している場合、まずは論理側で安全に確保する判断が現実的なことがあります。一方で、RAID自体が不安定なら、個別ディスク側の状態を押さえないと復旧が難しくなることもあります。

ここは一般論で「これが正解」と言い切れません。構成（RAIDレベル、故障ディスク数、ホットスペアの有無、キャッシュ設定）と、ログの挙動（タイムアウトの起点）が絡むからです。だからこそ、次章の“帰結”で、専門家相談の必然性につながっていきます。

この章のまとめ：複合構成では「手当て」より先に「地図」を作る

RAID/LVM/仮想化が絡むEIOでは、早く直そうとするほど迷路に入ります。まず依存関係（どの層が何に載っているか）を整理し、再構築など高負荷な操作は、状況が落ち着くまでブレーキを掛ける。その上で保全の単位を設計する。ここまでできると、復旧と再発防止が“収束”に向かいます。次章では、EIO対応の帰結として、運用と設計をどうコード化して再発を防ぐか、そして一般論の限界を整理します。

第10章：帰結：EIO対応は「交換」で終わらない──復旧計画と再発防止を“設計”として固定する

EIO対応の現場って、最後にこういう感情が残りがちです。

「結局、何が原因だったんだっけ…」「また同じことが起きたら、今回の学びは活きるのかな」

ここが最大の分かれ目です。EIOを“部品交換のイベント”として終えると、次の障害でまた同じ議論が過熱します。一方で、EIOを運用と設計の改善トリガーとして扱えると、次は被害最小化が早くなります。つまり、帰結は「交換」ではなく「仕組み化」です。

再発防止の要点は「観測」「抑え込み」「復旧ルートの事前設計」

EIOは突然出たように見えて、実は前兆（遅延、タイムアウト、再試行増加、SMARTの増加傾向）があることも多いです。そこで、次の3点を“運用要件”として固定します。

ポイントは、ここを“気合”ではなく“設計”として固定することです。担当者が変わっても同じ判断ができる状態にする。これがBtoBの現場では効きます。

一般論の限界：最適解は「構成・業務制約・復旧優先度」で変わる

ここまでの記事は、EIO対応の一般形を整理しました。ただ、現実の最適解は、次の条件で大きく変わります。

• 構成：RAID/LVM/暗号化/仮想化、ストレージ種類、バックアップ方式
• 業務制約：止められない、夜間しか触れない、保全先がない、運用人員が限られる
• 優先度：完全復旧が最優先か、早期復旧が最優先か、証拠保全が必要か

つまり「この手順が正しい」というより、「この条件ならこの手順が安全」という話になります。ここを誤ると、復旧の難易度が上がり、結果として損失が増えます。

自然な次の一歩：個別案件は“専門家と一緒に設計”した方が速い

「また新しい相談先？どうせ手続きが増えるだけじゃないの」──そう思うのも分かります。現場はこれ以上、面倒を増やしたくないですよね。

ただ、EIOは“現場の努力”だけで片付けるには、関係する層が多すぎます。構成の把握、ログの読み解き、保全の設計、復旧ルートの選択、再発防止の仕組み化までを、限られた時間でやるのは重い。

株式会社情報工学研究所では、データ復旧だけでなく、障害時の被害最小化（ダメージコントロール）から、構成・運用に合わせた復旧計画の整理、再発防止の設計（監視・運用手順・バックアップの見直し）まで、個別事情に合わせて一緒に組み立てる支援が可能です。

「今この瞬間の復旧が必要」「再発が怖い」「役員説明に耐える資料が欲しい」など、状況は様々です。一般論のテンプレではなく、あなたの環境に合わせた“現実的な手順”に落とし込むために、まずは無料相談で状況を共有していただくのが、最も小さな一歩になります。

付録：主要プログラミング言語ごとのI/Oエラー（EIO）取り扱い注意点（現場での落とし穴）

最後に、EIOがアプリ側に見えたときに「言語ごとに何が起きがちか」を整理します。EIOはOSのI/O失敗が起点で、言語はそれを例外や戻り値として受け取ります。したがって注意点は「言語の違い」よりも、バッファリング、例外処理、リトライ、書き込みの確定（fsync相当）の扱いに集中します。

C / C++

• 戻り値の取りこぼし：read/writeの戻り値・errno確認を漏らすと、失敗を成功扱いしやすい。
• 部分書き込み：writeが全量を書かないケースを前提にしないと、破損や欠落が起きる。
• fsyncの設計：確定（永続化）をどこで保証するかが曖昧だと、障害時に“書けたはず”問題が発生する。

Rust

• Resultの扱いは強いが、設計は別：unwrap/expectで落としてしまうと復旧不能な停止になる。
• リトライの境界：EIOは一時的障害とは限らないため、無限リトライは状況悪化（I/O増加）につながることがある。

Go

• エラーのラップで原因が見えにくい：errors.Is/Unwrapを使って根のエラー（syscall）に辿れる設計にする。
• 並行処理で障害が増幅：ゴルーチンで同時I/Oが増えると、障害ディスクに負荷を掛けてしまうことがある（抑え込みが必要）。

Java / Kotlin（JVM）

• 例外は上がるが、トランザクション境界が重要：DB/キュー/ファイルの整合性をどこで保証するかを設計していないと、EIOで中途半端な状態が残る。
• バッファリングとflush：ストリームのflush/close時に初めてエラーが出ることがある（“最後に落ちる”を前提にする）。

Python

• 例外発生位置が遅れることがある：書き込みがバッファされ、close時に例外が出るケースを想定する。
• 安易な再試行：EIOを握りつぶしてリトライすると、障害が進行している場合にI/Oを増やしてしまう。

JavaScript / Node.js

• 非同期I/Oのエラー伝播：callback/Promiseのどこで捕捉するかが曖昧だと、エラーがログに出ずに静かに欠損する。
• ストリームの扱い：'error'イベントを購読しないとプロセスが落ちたり、失敗が見逃されることがある。

PHP

• エラーが警告止まりになる：ファイルI/OがWarningで流れ、処理が継続して“壊れた成果物”を残す場合がある。ログと例外化の方針を決める。
• 共有ホスティング特有の制約：I/O遅延や制限によりタイムアウトが先に出ることがある（OS側EIOと混ざる）。

Ruby

• 例外処理の粒度：rescueでまとめて握ると、EIOも一時的失敗も同列に扱われやすい。分類して扱う。
• ジョブ/バッチの冪等性：途中で落ちたときに再実行で整合が取れるように設計しておくと被害最小化につながる。

C# / .NET

• 例外階層が深い：IOExceptionの内側（InnerException）にOS由来の情報が入ることがあるため、原因を辿れるログ設計が重要。
• ファイル共有とロック：EIOと競合（共有違反）を混同しないように、例外と環境情報を併記する。

Shell（bash等）

• コマンドの終了コード依存：パイプで失敗が隠れることがある（pipefail等の運用設計が必要）。
• ログの欠落：標準出力/標準エラーの扱いが雑だと、EIOの手がかりが残らない。

付録まとめ：言語の差より「失敗を見逃さない設計」と「抑え込み」が重要

EIOは“アプリのバグ”というより、ストレージI/Oが成立しない状態がアプリに伝播したものです。言語ごとの注意点はありますが、本質は共通で、（1）失敗を確実に検知する（2）壊れた状態を拡大しない（3）復旧可能な形で記録するに尽きます。個別案件では、構成・運用・業務制約で最適解が変わるため、迷った時点で株式会社情報工学研究所のような専門家に相談し、最短で“収束”へ向かうルートを確定させるのが現実的です。