LinuxのExt4ファイルシステム障害：復旧テクニックと時間

【注意書き】本記事は、LinuxのExt4ファイルシステム障害に関する一般的な情報提供を目的としています。実際の復旧可否や最適手順は、障害原因（論理破損／物理I/O劣化／RAID・LVM等の構成要因）、ディスク状態、ログの内容、停止できる時間、バックアップ有無などで大きく変わります。誤った操作（安易なfsck実行や書き込み継続など）は損傷を拡大し、復旧難度とコストを急増させることがあります。個別案件の判断が必要な場合は、株式会社情報工学研究所のような専門家へご相談ください。

その「fsck一発」は本当に正解？――現場が抱えるExt4障害の“怖さ”から始める

「またストレージか…」「今このタイミングで？」――障害が起きる瞬間って、だいたい最悪の忙しさの中ですよね。Ext4の障害は“直せそうに見える”のが厄介です。ログにEXT4-fs errorが出ている、マウントがread-onlyに落ちた、I/O errorが混じる。こういう状況で、つい「fsckを回して直すか」と考えがちですが、ここが最初の分岐です。

Ext4の障害は大きく分けると、(1)論理破損（メタデータ不整合）、(2)物理I/Oの劣化（読み書きそのものが危険）、(3)構成由来（RAID/LVM/仮想化/コントローラ）の3系統が絡みます。見た目が似ていても“正解の初動”が違います。fsckは強力ですが、強力だからこそ「原因がI/O劣化だった場合」に悪化させることがあります。読めていたものが読めなくなる、再配置や再書き込みで痕跡が消える、ということが現実に起きます。

心の会話：現場の本音は「止めたくない」

「止めたら怒られる」「止めないと壊れる」――この板挟みが、復旧現場の一番しんどいところです。特にレガシー環境だと、サービス停止＝売上・業務停止に直結します。だから“今すぐ直す”方向に寄りやすい。でもExt4障害では、まず「これ以上壊さない」方針が結果的に最短ルートになることが多いです。

この章の結論：最初に決めるのは「修復」ではなく「保全」

いきなり修復に飛び込むのではなく、(a)書き込み停止（または最小化）、(b)ログと状態の確保、(c)影響範囲の切り分け、(d)必要ならディスクイメージ取得――この順に「時間を買う」ことが重要です。復旧は“技術”でありつつ、“判断”でもあります。判断材料がない状態でのfsckは、当たり外れが大きい賭けになります。

以降の章では、Ext4が何をどう守っているのかを押さえた上で、障害タイプ別に初動と復旧テクニックを、時間見積もりまで一本の線でつなげていきます。

Ext4は何を守っているのか――ジャーナリングとメタデータの基本を押さえる

Ext4の復旧を“腹落ち”させる近道は、構造をざっくり掴むことです。Ext4は「データ本体（ファイルの中身）」と「メタデータ（どこに何があるか）」で成り立ちます。メタデータの代表は、スーパーブロック、グループディスクリプタ、inode、ディレクトリエントリ、ビットマップ（ブロック/ inodeの使用状況）などです。障害時に壊れやすいのは、多くの場合このメタデータ側です。

ジャーナリング（JBD2）の意味：壊れにくくするが、万能ではない

Ext4はジャーナリング（JBD2）により、更新途中で電源断やクラッシュが起きても、整合性を取り戻しやすくしています。典型例は「停電後にマウントできる／fsckで直る」系の障害です。ただし、ジャーナルは“更新の記録”であって“バックアップ”ではありません。物理I/Oが不安定なディスク上で、ジャーナルの読み書き自体が失敗すると、整合性回復がうまくいかないことがあります。

スーパーブロックと代替スーパーブロック：復旧の入口になる

Ext4にはファイルシステム全体の情報（サイズ、機能フラグ、inode数など）を持つスーパーブロックがあり、破損するとマウントできません。ただし、Ext系は代替（バックアップ）スーパーブロックを複数持てる設計です。このため「スーパーブロック破損」でも復旧の糸口が残ることがあります。e2fsckで-bを使う“あの手”は、こうした設計に基づきます。

inodeとディレクトリ：ファイルが“消えたように見える”理由

ファイルの中身がディスク上に残っていても、inodeやディレクトリエントリが壊れると「ファイルが消えた」ように見えます。逆に言えば、inode情報やリンク関係を辿れれば、内容を救い出せる可能性があります。extundeleteやdebugfsなどのツールは、ここを突いて“見えなくなったファイル”を拾おうとします。

この章の結論：復旧は「どの層が壊れたか」を当てるゲーム

Ext4復旧の本質は、(1)物理I/Oが安全か、(2)メタデータの整合性が崩れているのか、(3)その崩れはどの層か――を見立てて、最小の変更で最大の情報を回収することです。以降は、障害がどの系統に近いかを“見え方”で切り分ける方法から入ります。

障害の見え方はだいたい3系統――「論理破損」「I/O劣化」「構成由来（RAID/LVM）」

Ext4障害と一口に言っても、現場での“見え方”は大きく3系統に分かれます。ここを外すと、同じコマンドでも結果が真逆になります。とくに怖いのは、I/O劣化を論理破損だと思い込んでfsckを回すケースです。ディスクに追加の負荷と書き込みが発生し、状況が雪崩れることがあります。

ログの見どころ：同じ「エラー」でも意味が違う

たとえばEXT4-fs errorは、Ext4がメタデータ矛盾を検知したサインです。一方でBuffer I/O errorやタイムアウトは、ブロックデバイス層での読み書き失敗を示します。両方が出るケースもありますが、その場合は「論理破損が原因」というより「I/O失敗が引き金でメタデータが壊れていった」と見る方が安全です。つまり、修復より保全が優先になります。

“構成由来”の罠：正しい対象を間違えると復旧が破綻する

RAID（mdadm）やハードウェアRAID、LVM、暗号化（LUKS）などが挟まっている場合、「どのデバイスに対して」診断・修復するかが最重要です。たとえばdegraded状態のRAIDで再同期を走らせると、残っている良データを上書きする方向に進むことがあります（どちらが正しいか確定できない状態での再構築は危険です）。構成が絡むと、Ext4の話の前に“ストレージの正体”を確定させる必要があります。

この章の結論：まず分類、次に手順。逆にすると事故る

「何が壊れているか」を荒くでも分類できると、初動のミスが激減します。以降の章では、最初の10分で取るべき行動（ログ採取、read-only方針、影響範囲の切り分け）を、具体例込みで整理します。

最初の10分で決まる――ログ採取・マウント方針（read-only）・影響範囲の切り分け

Ext4障害対応で最初にやるべきことは、「直す」ではなく「状況を固定して、判断材料を集める」です。ここでのポイントは2つあります。(1)書き込みを止める（損傷拡大の防止）、(2)後から検証できる証拠（ログ・状態）を残す（説明責任と再現性）。この2つが揃うと、復旧の成功率と、復旧時間の見積もり精度が上がります。

まずは“書かない”：read-onlyの徹底

可能ならサービスを止め、該当ファイルシステムをアンマウントします。止められない場合でも、少なくとも対象をread-onlyで扱う設計に寄せます。典型的には、(a)緊急退避用の別領域を用意する、(b)ログ採取とダンプを先に取る、(c)やむを得ずマウントするなら「読み取り専用」で、という順序です。障害中に書き込みが続くと、ジャーナルやビットマップ、inode周りが追加で変化し、復旧対象が動いてしまいます。

ログ採取：dmesg/journalctlで“いつから何が起きたか”を取る

最低限、カーネルログ（dmesg）とsystemd環境ならjournalctl（特に該当期間）を確保します。ストレージ層のエラー（タイムアウト、リトライ、reset）と、Ext4層のエラー（EXT4-fs error/warning）の両方が出ているかが分岐点になります。また、マウントがread-onlyに切り替わったなら、その直前に何が起きたか（I/O errorの連発、ジャーナルエラーなど）を追います。

構成情報：RAID/LVM/暗号化の状態を“文字で残す”

RAID（mdadm）の場合はアレイ状態、degradedか、どのメンバが外れているか、再同期が走っていないかを確認します。LVMがある場合はVG/LVの状態、スナップショットの有無や残量、thin poolの逼迫などを確認します。暗号化（LUKS）がある場合は、マッピング名やUUIDなど、後から同じ構成を再現できる情報が重要です。「目で見た」だけだと、復旧中に状況が変わったときに説明ができなくなります。

切り分けの最短ルート：I/Oエラーがあるかを先に決める

心情的には「マウントできない＝論理破損」と考えたくなりますが、I/O劣化が混ざっていないかを先に見ます。I/O劣化が疑われるなら、復旧テクニックに入る前に“保全（イメージング）”へ舵を切るのが安全です。逆にI/Oが安定していて論理破損が主因なら、検証（変更なし）→限定的修復→回収、という順で進められます。

この章の結論：判断材料が揃えば、復旧は「怖い賭け」から「再現可能な作業」に変わる

最初の10分の動きが、復旧の成功率だけでなく、説明のしやすさ（上司・顧客への報告）と、見積もりの妥当性を左右します。次章では、I/O劣化が疑われるときに“復旧テクニックの前にやるべきこと”――イメージングと保全の考え方に進みます。

I/Oエラーが見えたら“復旧テクニック”の前にやること――イメージングと保全（時間を買う）

Buffer I/O error、timeout、reset、ATA error、NVMeのmedia error、SMARTでReallocated/Pendingが増えている――こうした兆候があるとき、Ext4の修復（fsck）より先に考えるべきは「これ以上読めなくなる前に、読める範囲を確保する」です。ここでいう確保は、ファイルコピーではなく“ブロックレベルの保全（イメージング）”を指します。ファイルコピーは、ディレクトリやinodeが壊れていると失敗しやすく、さらに読み取りが偏ってディスクへ負荷を集中させることがあります。

心の会話：でも、イメージングって時間かかるんでしょ？

「今すぐ復旧しろと言われているのに、丸ごとコピーなんて…」と思うのは自然です。ただ、I/O劣化が絡むと“先に直す”は失敗しやすく、結果的に時間が何倍にも膨らむことがあります。イメージングは遠回りに見えて、実は「ディスクが死ぬまでの残り時間」を“自分の味方につける”作業です。

イメージングの基本方針：読み取り優先、書き込みは絶対にしない

原則として、障害ディスク（または障害領域）には追加の書き込みをしません。やるべきは、別媒体へ読み出せたブロックを順に退避し、読めない箇所は“後回し”にすることです。読めない箇所に粘ると、同じセクタへリトライが集中して状態が悪化し、他の読めたはずの領域まで巻き込むことがあります。

このため、現場では「まずは大きくコピーして穴を残す→次に穴を埋める」方式が一般的です。Linuxではddrescue（GNU ddrescue）が代表的で、ログファイル（mapfile）で進捗と未読領域を管理できます。ポイントは、再試行回数や読み方針を段階的に上げることです。最初から強いリトライをかけると、ディスクが熱やエラーで一気に悪化することがあります。

RAID/LVM環境での注意：どこをイメージするかが難易度を左右する

RAIDやLVMの上にExt4がある場合、「物理ディスク単体を保全する」のか「論理ボリューム（/dev/mdX や /dev/mapper/xxx）を保全する」のかで戦略が変わります。I/O劣化が単一ディスクに偏っている場合、RAIDの論理デバイスを読む行為自体が、問題ディスクへ負荷を集中させることがあります。一方で、RAIDメンバ単体のコピーだけでは、後段で正しく再構成できないこともあります。

ここは一般論だけで決めると事故りやすい領域です。ディスク本数、RAIDレベル、degradedの有無、再同期の状態、LVMの構成、暗号化の有無、そして“止められる時間”で最適解が変わります。たとえば「いまRAIDがdegradedで、残りのディスクに負荷をかけると全滅する」状況なら、無理に論理側を読みにいかず、まず問題ディスクの保全を優先する判断が出ることもあります。

保全が終わったら、初めて“安全に”復旧テクニックへ進める

イメージ（またはクローン）を作れたら、以降のfsckや解析は“コピー側”で行えます。ここが大きい。失敗しても、やり直せます。現場エンジニアが一番欲しいのはこの「やり直し可能性」です。保全があるだけで、復旧はギャンブルから工学になります。

次章では、いよいよe2fsckを“事故らせずに”使うための実践的な考え方（-nから始める、代替スーパーブロック、修復の副作用の見積もり）を整理します。

e2fsckを安全に使い分ける――-nから始める検証、-b（代替スーパーブロック）まで

e2fsck（fsck.ext4）はExt4修復の中核ツールですが、扱いを誤ると状況を悪化させます。特に“原因がI/O劣化”だった場合、修復処理が大量の読み書きを伴い、ディスクの寿命を縮めます。したがって、前提として「I/Oが安定しているか」「保全（イメージ）を取ったか」を確認したうえで、段階的に使うのが基本方針です。

最初は「変更しない」検証：-nの意味

まず推奨されるのが、変更を行わないモードでの検証です。e2fsckには「修復提案はするが、実際には書き込まない」動作があり、これにより“どの程度の不整合があるか”の見立てを作れます。ここで重要なのは、検証結果をそのまま実施して良いとは限らないことです。e2fsckは整合性を取り戻すために、孤児inodeをlost+foundへ移したり、ディレクトリ構造を再構成したりします。これは「整合性回復」には有効ですが、「元どおり」に戻ることを保証しません。

たとえば、ディレクトリエントリが壊れている場合、ファイル自体は残っていても“元のパス”を復元できないことがあります。業務上は「ファイルが読める」だけで十分な場合もあれば、「このパスに、この名前で存在する必要がある」場合もあります。どちらが求められているかで、修復方針が変わります。

よくある分岐：マウントできない原因がスーパーブロックかどうか

「bad superblock」等が出るケースでは、代替スーパーブロックを用いた修復が検討されます。Ext系は複数の場所にスーパーブロック情報を保持できる設計があり、破損が局所的なら復旧の入口になります。ただし、代替スーパーブロックの位置はファイルシステム作成時の設定（機能フラグ、ブロックサイズ等）に依存します。やみくもに値を当てるのではなく、ファイルシステム情報を確認し、整合する候補を選ぶ必要があります。

修復の副作用：lost+foundは“失敗”ではなく仕様だが、業務影響は出る

e2fsckで修復を進めると、リンクを失ったinode（孤児）がlost+foundへ回収されることがあります。これは「ファイル内容を救う」観点では合理的ですが、現場運用では「どれがどれか分からない」「アプリが参照できない」という二次問題になります。たとえばWebアプリやDB、メールサーバなどは、パスや権限、所有者、関連ファイルの整合が重要で、ファイル単体が残ってもサービスが復旧しないことがあります。

このため、e2fsckで整合性を回復させる前に「何をゴールにするか」を決めます。ゴールが“サービス復旧”なのか、“証拠保全”なのか、“ファイル救出”なのかで、最初に取るべき手段は変わります。特にBtoBの現場では、サービス復旧と同時に「説明責任」「再発防止」が求められます。ここを雑にすると、復旧後に炎上します。

安全運用のコツ：修復は「小さく試して、結果を見て、次へ進む」

修復は一気にやり切るのではなく、段階的に進めるのが現実的です。検証結果を読み、影響が小さい修復から着手し、マウントテストや読み取りテストを挟みます。ここで“コピー側（イメージ側）で作業できている”と、試行錯誤が安全になります。逆に本番ディスクへ直接修復を当て続けると、取り返しがつかない局面に入りやすいです。

次章では、Ext4の特徴であるジャーナルをどう扱うか――リプレイの意味、どんな時に味方になるか、どんな時に敵になるか――を整理します。

ジャーナルを味方にする／敵にしない――リプレイの意味と「やって良い局面・悪い局面」

Ext4のジャーナリングは、「更新途中で止まっても整合性を取り戻しやすい」ための仕組みです。一般的には、クリーンにアンマウントされなかったファイルシステムを次回マウントする際、未反映の更新（トランザクション）をリプレイして整合を回復します。ここまでは“良い話”です。しかし障害対応では、ジャーナルのリプレイが必ずしも歓迎されない局面があります。

やって良い局面：停電・クラッシュ後で、I/Oが安定している

典型的には、突然の電源断やカーネルパニック後に「ファイルシステムがdirty扱いになっている」ケースです。物理ディスクが健全で、I/Oエラーが見えず、障害が“未完了の更新”に起因するなら、ジャーナルリプレイやfsckで整合が戻り、通常運用に復帰できることがあります。この場合、復旧時間は比較的短く見積もれます（ただし容量やinode数、サーバ性能によりfsck時間は伸びます）。

注意が必要な局面：I/O劣化が疑われる、または証拠性が重要

I/O劣化が疑われる場合、ジャーナルリプレイはディスクへの書き込みを伴い得ます。書き込みが走ると、(1)劣化部位への負荷で状態が悪化する、(2)残っていた痕跡が上書きされる、というリスクが出ます。また、フォレンジックや監査、紛争対応などで“証拠性”が重要な案件では、障害発生後にファイルシステムへ書き込みが入ること自体が後工程の説明を難しくします。こうした案件では「まずは保全してから解析」が原則になります。

「敵にしない」ための実務：勝手にリプレイさせない

現場でよくある事故が、「とりあえずマウントしたら、裏で処理が進んでしまった」というパターンです。自動マウントや起動時のfsck、自動復旧処理が働く環境では、意図せず状態が変わります。したがって、障害対応では“勝手に進む仕組み”を止める、または対象を切り離して検証環境へ持っていく設計が重要です。ここは運用設計の範囲であり、単なるコマンド知識だけでは安全に進めにくい領域です。

心の会話：結局、何を信じればいいの？

「ジャーナルって直してくれるんじゃないの？」「じゃあ、何も触らない方がいいの？」――この揺れは、判断材料が不足しているときに起きます。答えはシンプルで、“I/Oが安定していて、目的がサービス復旧なら、ジャーナルは味方になりやすい”。逆に、“I/Oが不安定、または証拠性・完全性が重要なら、まず保全してから”です。この二軸で整理すると、迷いが減ります。

この章の結論：ジャーナルは万能薬ではなく、条件付きの強力な道具

Ext4の設計は堅牢ですが、現実の障害は「物理」「構成」「運用」が絡み合います。ジャーナルを活かせる条件を満たしているかを見極め、満たさないなら“先に守る（保全する）”へ寄せる。ここまでができると、次の章で扱う「ファイル単位のサルベージ」も、より確度高く進められます。

ファイル単位のサルベージ手段――extundelete / debugfs / TestDisk・PhotoRecの現実解

ここまでで「壊し方（論理／I/O／構成）」と「最初に守る（保全）」の重要性を押さえました。ここからは“欲しいものを取り出す”フェーズです。ただし、Ext4のサルベージは万能ではありません。目的は大きく2つに分かれます。1つはファイル名やディレクトリ構造をできるだけ保った回収、もう1つは中身だけでも救う（ファイル名は諦める）回収です。どちらが必要かで、選ぶ手段が変わります。

心の会話：「ファイルは残ってるんでしょ？取り出せば終わりでは？」

気持ちはすごく分かります。ただ、業務データは「中身」だけでなく「どのフォルダに」「どんな名前で」「どの権限で」置かれていたかが価値の一部です。アプリはパスで参照しますし、バックアップもパス単位で差分を取ります。つまり、ファイル単体が残っても“業務として復旧した”にならないことがある。ここがBtoBの復旧で難しいところです。

extundelete：条件が合うと強いが、条件がズレると厳しい

extundeleteは、削除されたファイルを回収する目的で知られるツールの一つです。ただし、Ext4の運用状況や障害状況によって成功率が大きく変わります。一般に、削除後にブロックが上書きされていないこと、対象のメタデータが追跡できること、などが重要になります。特に“削除してから時間が経っている”“障害後も書き込みが続いた”“大容量の書き込みが走った”といった条件では、復旧できる範囲が狭くなりがちです。

実務では、extundeleteは「試せるなら試すが、これだけに賭けない」位置づけになります。成功したときのリターンは大きい一方で、失敗した場合に別ルート（debugfsやシグネチャ回収）へすぐ移れるように、最初から二段構えにしておくのが安全です。

debugfs：Ext4を“直接覗く”ための道具（ただし使い方次第）

debugfsはExt系ファイルシステムの内部情報を参照したり、状況によってはデータを取り出したりできる低レベルツールです。復旧の現場では、「マウントできない」「ディレクトリが壊れている」「通常のコピーができない」といった状況で、inodeやブロックの情報を辿って回収を試みる際に使われます。

ただし、ここで注意したいのは、debugfsは“強い”がゆえに、運用を誤ると状態を変えてしまう可能性がある点です。原則は、保全したイメージ（コピー）側で試すこと、そして読み取り中心で使うことです。特に争点になり得る案件（監査、訴訟、社内不正等）では、「いつ、誰が、どの媒体に、何をしたか」を後から説明できる形で進める必要があります。

TestDiskとPhotoRec：メタデータが壊れても“中身”を拾えるが、代償がある

メタデータ（inodeやディレクトリエントリ）が大きく壊れている場合、ファイル名やフォルダ構造を保った復旧は難しくなります。そのとき現実的になるのが、シグネチャ（ファイル形式の特徴）に基づいて中身を回収する手段です。代表例としてTestDisk/PhotoRec系のアプローチが挙げられます。

この方式の強みは、ファイルシステムの整合性が崩れていても、ディスク上にデータの塊が残っていれば拾える可能性があることです。一方で、代償としてファイル名・フォルダ構造・タイムスタンプなどのメタ情報は失われやすいです。結果として「大量のファイルは出てきたが、どれが必要なものか分からない」という二次作業が発生します。業務復旧の観点では、ここが復旧コストを押し上げます。

手段の選び方：目的別の“現実的な落としどころ”

この章の結論：サルベージは「どこまで元に戻したいか」で手段が変わる

Ext4のサルベージには複数の道がありますが、どれも万能ではありません。だからこそ、目的（ファイル救出／証拠性／サービス復旧）を先に固定し、条件（I/Oの安定性、上書き状況、構成）に合わせて手段を組み合わせる必要があります。次章では、現場で必ず聞かれる「で、何時間かかるの？」に答えるための、復旧時間の見積もりロジックを整理します。

復旧に“何時間かかるか”を説明できるようになる――速度・エラー率・手順で見積もる

Ext4障害対応で、技術と同じくらい重要なのが「見積もり」と「説明」です。現場では必ず聞かれます。「いつ直る？」「何時間で復旧できる？」。ここで雑に答えると、復旧作業そのものより、後の信頼を失います。一方で、正確な見積もりは簡単ではありません。だからこそ、見積もりを“分解”して説明できる形にするのが実務的です。

時間が伸びる要因トップ3：I/O劣化、容量、そして「上書き回避」

復旧時間を支配する要因はだいたい次の3つです。

• I/O劣化（読み取りエラー、リトライ、タイムアウト）：ここがあると桁で伸びます。順次読みが100MB/s出るはずが、リトライ地獄で数MB/s以下になることがあります。
• 対象容量（およびファイル数/ inode数）：fsckやメタデータ検査は、単純な容量だけでなく、inodeやディレクトリの数に影響されます。
• “壊さないための手順”を踏むこと：保全（イメージング）を挟む、検証を挟む、試行錯誤を安全側で行う――これは時間を使いますが、失敗を減らし、トータルでは短くなることが多いです。

見積もりは「工程別」に出すと、現場も納得しやすい

復旧の時間は一括で出すより、工程ごとに“幅”を持って提示すると、現実に即した説明になります。

「時間＝容量÷速度」だけでは危険：エラーの“質”が違う

同じ1TBでも、状態によって所要時間は大きく変わります。I/Oエラーが無く順次読みが出るなら、概算は比較的当てやすいです。しかし、タイムアウトやリセットが頻発するディスクは、読み取りが“止まる”時間が長くなります。さらに、読めない領域に粘るほど悪化することもあるため、読み方針（後回し、段階的リトライ）で時間が変動します。

このため、見積もりでは「最短（理想）」「現実（平均）」「最悪（エラー多発）」の3つを用意し、何が起きると最悪側に寄るのかを明確にします。現場や上長が納得するのは、根拠がある“幅”です。断言は危険です。

説明責任を助けるコツ：途中経過を“数値”で示す

復旧作業はブラックボックスに見えがちです。だからこそ、途中経過を数値で示すと安心感が増えます。たとえば、保全なら「何%読めたか」「未読領域はどのくらいか」、回収なら「回収できたファイル数」「重要フォルダの整合が取れたか」、といった具合です。これがあると、顧客や社内の意思決定（どこで打ち切るか、どこまで追加費用を許容するか）が現実的になります。

この章の結論：見積もりは“工程分解”すれば、技術者の言葉で説明できる

復旧時間は運と環境に左右されますが、分解して説明すれば、根拠ある見通しを作れます。そしてこの「説明できる」ことが、BtoBの復旧では技術と同じくらい価値になります。次章では、ここまでの伏線を回収し、Ext4障害対応の帰結――「復旧できる/できない」より重要な設計判断と、一般論の限界――へ進みます。

帰結――「復旧できる/できない」より重要な設計判断（バックアップ、監視、運用ルール）

ここまで、Ext4障害を「論理破損」「I/O劣化」「構成由来」に分け、初動→保全→修復→サルベージ→時間見積もりへ一本の線で繋げてきました。ここで回収したい伏線はひとつです。Ext4障害の現場で本当に難しいのは、ツール選定やコマンドの暗記ではなく、“どこで一般論を捨てて、個別案件として判断するか”です。つまり、復旧そのものより、復旧の前後にある設計・運用の意思決定が、結果（損失額・停止時間・再発率）を大きく左右します。

心の会話：結局「壊れたら直せる」じゃダメなんですか？

「Ext4は堅牢だし、障害が起きてもfsckで戻ることもある。だから大丈夫」――そう言いたくなる気持ちは自然です。でもBtoBの現場では、“戻ることがある”では足りません。必要なのは、戻らないケースの損失を最小化できる設計です。復旧が成功しても、その間に業務が止まり、顧客対応や信用毀損が起きれば、技術的な勝利は経営的には敗北になり得ます。

設計判断1：バックアップは「ある/ない」ではなく「復旧できる形か」

バックアップは“存在”より“復元可能性”が本質です。よくある落とし穴は、(1)バックアップが最新でない、(2)復元手順が未検証、(3)アプリ整合（DB/設定/鍵/依存ファイル）が取れない、(4)復元先の容量や権限、ネットワークが整っていない、です。Ext4障害でファイルを回収できても、アプリ側の整合が崩れていればサービスは戻りません。逆に、復元手順が検証済みなら、ディスク障害は“復旧作業”ではなく“復元作業”に落とし込めます。ここで停止時間の桁が変わります。

設計判断2：監視は「障害検知」ではなく「劣化の早期発見」に寄せる

I/O劣化が絡むと、復旧時間は急増し、成功率も落ちます。だからこそ、SMARTの異常やリトライ増加、I/O待ちの増加、ファイルシステムエラーの兆候を“止められるタイミングで”拾うことが効きます。Ext4のエラーは、突然の論理破損だけでなく、I/O劣化が引き金で増えていくことがあります。「障害になってから通知」では遅いのが現実です。監視のKPIは「落ちたか」ではなく、「落ちる前に止められる兆候が出たか」に寄せる方が、運用として合理的です。

設計判断3：運用ルールは「現場の心理」を前提に作る

障害時、人は焦ります。焦ると“最短に見える道”を選びがちです。Ext4障害で言えば「とりあえずfsck」「とりあえず再起動」「とりあえずRAID再構築」などが典型です。だから運用ルールは、理想論ではなく、焦った人が守れる手順として設計する必要があります。具体的には、最初の10分の行動（書き込み停止、ログ採取、構成情報の確保、保全の判断）をチェックリスト化し、誰が見ても同じ行動が取れる状態にします。ここが整っていると、復旧の質が個人依存になりにくいです。

一般論の限界：RAID/LVM/仮想化/暗号化が絡むと「安全な一手」が変わる

Ext4単体の障害なら、ある程度“型”で語れます。しかし実務では、RAID（ソフト/ハード）、LVM（thin含む）、仮想化基盤、暗号化（LUKS）、分散ストレージ、バックアップ製品などが重なります。このとき、同じ症状でも最適手順が変わります。たとえば、degradedなRAIDでの再同期の扱い、thin poolの逼迫、スナップショットの運用、仮想ディスクの下層障害など、判断を誤ると「復旧可能だったものを壊す」方向に進み得ます。ここが一般論の限界であり、個別案件の設計判断が必要になる理由です。

この章の結論：復旧は“技術”だけでなく“経営リスクの制御”である

Ext4障害の復旧テクニックは重要です。しかしBtoBでは、停止時間、説明責任、再発防止、そして「次に同じ夜勤を繰り返さない」仕組みづくりが同じくらい重要です。もしあなたの環境が、レガシーで止めづらく、構成が複雑で、バックアップや監視が“あるが不安”な状態なら、障害が起きてから考えるのでは遅いことがあります。一般論を踏まえたうえで、個別案件としての最適解を詰めたいと感じたタイミングで、株式会社情報工学研究所のような専門家に相談する価値が出ます。復旧のその場だけでなく、設計・運用まで含めて損失を最小化するためです。

付録：現在のプログラム言語各種で「Ext4障害を増やしやすい落とし穴」と注意点

最後に、アプリケーション側の視点です。Ext4障害そのものはディスク・構成・運用に強く依存しますが、アプリの書き方やI/Oの扱いが、障害時の“被害の見え方”を変えるのも事実です。ここでは、特定言語を批判するのではなく、「データを失いにくい」「障害時に切り分けしやすい」実務上の注意点を、言語・実行環境ごとに整理します（最終的にはOS設定、マウントオプション、ストレージ特性、運用ルールとセットで評価が必要です）。

共通原則：I/Oエラーを“握りつぶさない”、永続化を“思い込みで語らない”

• 書き込みが成功した＝永続化されたとは限りません。OSのページキャッシュやストレージのキャッシュ、ライトバック設定で遅延します。
• 重要データは、要件に応じてfsync / fdatasync 相当の同期や、ジャーナリング/トランザクション設計が必要です。
• I/Oエラー（EIO等）やディスクフル（ENOSPC）、一時エラー（EAGAIN等）をログに残し、上位へ伝播させる設計が切り分けを助けます。

C / C++：自由度が高い分「永続化」と「エラー処理」が自己責任になる

C/C++は低レベルI/Oを直接扱えるため、性能最適化や特殊要件に強い一方、障害耐性は設計・実装の差が大きく出ます。注意点は、(1)戻り値の未確認（write/fsync/rename等）、(2)部分書き込み（partial write）や中断（EINTR）の扱い漏れ、(3)テンポラリ→renameの“原子性”に依存した更新設計でディレクトリ同期を忘れる、(4)独自フォーマットでチェックサムや世代管理が無い、などです。Ext4上での安全な更新は「書く」「同期する」「（必要なら）ディレクトリも同期する」のように、要件に合わせた手当てが必要になります。

Java / JVM系：例外は拾えても「永続化の保証」を誤解しやすい

Javaは例外処理や抽象化が整っていますが、FileOutputStream等でflushしただけで安心してしまう誤解が起きがちです。flushはバッファをOSへ渡すだけで、ストレージへの確定とは別問題になり得ます。重要データはFileChannel.force等、要件に応じた同期が必要です。また、ログ出力も非同期・バッファリングされることがあるため、障害時の痕跡を残したい場合はログのフラッシュ方針、ローテーション、保存先（別ディスク/リモート）を設計します。

Python：手軽さの裏で「例外処理と運用境界」が曖昧になりやすい

Pythonは運用自動化やバッチに強い反面、スクリプトが増えると“誰が責任を持つか”が曖昧になりやすいです。注意点は、(1)例外を大雑把に握りつぶす（except: pass）、(2)一時ファイルや中間ファイルが増え、ディスクフルやinode枯渇を招く、(3)ログが標準出力だけで永続化されず、障害時の切り分けが難しくなる、(4)並列処理（multiprocessing等）で同一ファイル更新の競合が起きる、などです。運用自動化ほど「ログの保全」「失敗時の停止条件」「リトライ方針（過剰リトライでI/Oを悪化させない）」が重要です。

Go：並行処理が書きやすい分、I/Oの集中とログ爆発に注意

Goはgoroutineで並行処理が容易なため、I/Oを並列化しすぎてストレージに負荷を集中させる事故が起きがちです。障害兆候が出ているディスクに対して、並列リトライが走ると状況を悪化させることがあります。注意点は、(1)I/Oの並列度制御、(2)リトライの指数バックオフ、(3)コンテキストキャンセルで“止められる設計”、(4)ログのレート制限、です。障害時に「止められる」ことは、復旧の成功率に直結します。

Rust：安全性は強いが「永続化と運用」は別の問題

Rustはメモリ安全性の面で強みがありますが、ファイルI/Oの永続化保証や障害耐性は言語だけで決まりません。注意点は、(1)Resultの適切な伝播とログ化、(2)原子更新（temp+rename）の設計と同期、(3)データフォーマットのバージョニングやチェックサム設計、です。安全に“壊れない”設計は、型安全だけでなく、ストレージ障害時の破損モデルを前提に作る必要があります。

JavaScript / Node.js：イベントループと非同期I/Oで「順序」と「完了」を誤解しやすい

Node.jsは非同期I/Oが基本のため、「書いたつもり」「閉じたつもり」が起きやすい領域があります。注意点は、(1)コールバック/Promiseの完了を待たずにプロセス終了、(2)ログやファイル書き込みのバッファが残ったまま終了、(3)例外がグローバルで落ちて中途半端に残る、です。運用ではプロセス監視（再起動）だけでなく、「中途半端な状態から再開できる」設計（冪等性、チェックポイント、ジャーナル的ログ）が重要です。

PHP：共有ホスティングや権限制約の中で「容量・inode・権限」の問題が出やすい

PHPはWeb運用で広く使われますが、共有環境ではディスク容量・inode制限・権限・バックアップ運用がボトルネックになりやすいです。注意点は、(1)ログやセッション、キャッシュが肥大化してディスクフル、(2)権限ミスで復旧時に読み出せない、(3)プラグイン等の更新でファイルが増え、inode枯渇、です。特にWordPress運用では、バックアップと復元テスト、ログの退避先、更新手順（メンテナンスモード）を固めることが、障害時の復旧を現実的にします。

シェルスクリプト：小さな自動化が積み重なると「破壊力」が大きくなる

シェルは強力ですが、rmやmv、リダイレクト一つで大事故になります。注意点は、(1)set -e / pipefail等を使わず失敗を見逃す、(2)ワイルドカードや変数展開の想定外、(3)ログが残らない、(4)cronで無限リトライ的に動いてI/Oを悪化させる、です。障害兆候（I/O error等）が出たら自動処理が止まる仕組み（フェイルセーフ）を入れると、Ext4障害の拡大を防げます。

この付録の結論：言語の問題に見えて、実は「I/O要件定義」と「運用設計」の問題

「どの言語が安全か」ではなく、「そのデータはどこまで永続性が必要か」「障害時に何を優先するか（サービス継続／証拠性／整合性）」「失敗を検知して止められるか」という要件が先にあります。ここが曖昧なまま実装・運用が積み上がると、Ext4障害が起きたときに“復旧の難易度”が跳ねます。一般論では語り切れない領域だからこそ、システム構成・運用・復旧手順まで含めて個別最適を詰めたい場合は、株式会社情報工学研究所のような専門家への相談が現実的な選択肢になります。