効果的なLinuxファイルシステムエラーのトラブルシューティングと復旧方法

ファイルシステムエラーは、修復を急ぐと通常のLinux障害をデータ損失インシデントに変える可能性があります。最初の仕事は書き込みを停止し、デバイスを特定し、メタデータを変更するツールを実行する前に適切な復旧パスを選択することです。

このガイドでは、fsckおよびext2/3/4用のe2fsckなどのファイルシステム固有ツールを使用した、実践的なLinuxファイルシステムエラーのトラブルシューティングに焦点を当てます。最も安全なワークフローは退屈です：ログを検査し、可能な限りバックアップし、ファイルシステムをアンマウントし、正しいチェッカーを実行し、結果を確認してからディスクをサービスに戻します。

1. ファイルシステムの破損の認識と特定

ファイルシステムエラーは、しばしばいくつかの明白な兆候を通じて現れます。軽微な破損が完全なデータ損失にエスカレートするのを防ぐために、早期発見が重要です。

破損の一般的な症状

I/Oエラー： ファイルアクセス中に報告されるカーネルエラーで、しばしば「Input/output error」または同様のメッセージが表示されます。
ファイルの欠落または破損： ファイルが消えたり、正常に保存された後でもゴミデータが含まれる。
パフォーマンスの低下： 特にディスク操作中の過度のシステムの遅さは、システムが破損したメタデータを解釈するのに苦労していることを示す可能性があります。
マウントの失敗： システムが起動中に特定のパーティションをマウントできず、ユーザーを緊急シェルにドロップすることがよくあります。
カーネルログメッセージ： カーネルによって記録された重大なエラーで、dmesgコマンドや/var/log/syslog、journalctlで表示可能です。

監視すべき主要領域

ファイルシステムの破損は通常、メタデータ構造、特に以下に影響を与えます：

スーパーブロック： ファイルシステム全体の構造（サイズ、iノード数、ブロック数、状態）に関する重要な情報を含みます。
iノードテーブル： 実際のファイル（所有権、パーミッション、物理ブロックの場所）を記述する構造。
データブロックポインタ： どの物理ブロックがどのファイルに属するかのマッピングエラー。

スーパーブロックが損傷した場合、バックアップスーパーブロックを使用して修復または交換されるまで、ファイルシステム全体にアクセスできなくなります。

# 最近のディスクアクティビティエラーのカーネルログを確認
dmesg | grep -Ei 'error|fail|i/o'

# 持続的な警告やエラーのシステムジャーナルを確認
journalctl -xb

2. 準備：アンマウントされたファイルシステムのルール

絶対に重要： 現在マウントされているアクティブなファイルシステム上でfsckのような復旧ユーティリティを決して実行してはいけません。そうすると即座に取り返しのつかない損傷を引き起こし、完全なデータ損失につながる可能性があります。ファイルシステムはチェックする前にアンマウントするか、読み取り専用（ro）でマウントする必要があります。

データパーティションのアンマウント

非ルートパーティション（例：/home、/data）の場合：

# デバイスパスを特定（例：/dev/sdb1）
df -h

# ターゲットパーティションをアンマウント
sudo umount /dev/sdb1

# アンマウントが成功したことを確認
df -h | grep sdb1

ルートパーティション（`/`）の処理

ルートパーティションはシステムが通常動作中にアンマウントできないため、主に3つのオプションがあります：

シングルユーザー/リカバリモードで再起動： 多くの最新ディストリビューションは、ルートファイルシステムを読み取り専用でマウントするリカバリモードを提供し、fsckを安全に実行できます。
ライブディストリビューションを使用（推奨）： USBまたはISOイメージ（例：Ubuntu Live、CentOS Live）を使用してサーバーを起動し、この別のオペレーティング環境からチェックを実行します。
次回起動時に強制チェック： 一部の古いシステムでは、/forcefsckファイルに触れると、次回の起動サイクル中にシステムがfsckを強制的に実行します。（この方法は、ext4のような最新のジャーナリングファイルシステムでは信頼性が低いです）。

3. ファイルシステム復旧のための`fsck`の活用

fsckは、パーティションタイプに基づいて適切なファイルシステムチェッカーツール（例：ext4用のe2fsck、XFS用のfsck.xfs）を自動的に呼び出すラッパーコマンドです。

基本的な`fsck`の使用法

fsckを実行するときは、マウントポイントではなく、常に完全なデバイスパスを指定します。

# /dev/sdb1をチェックする基本コマンド
sudo fsck /dev/sdb1

必須の`fsck`オプション

オプション	説明	警告/注意
`-f`	ファイルシステムがクリーンに見えても強制的にチェックします。（強く推奨）
`-y`	すべての質問に「はい」と仮定し、自動的にエラーを修正します。	注意して使用：データを回復できない場合、削除または隔離する可能性があります。
`-n`	すべての質問に「いいえ」と仮定し、変更を加えずにドライランを実行します。	評価のみに有用。
`-p`	ユーザーにプロンプトを表示せずに安全な問題を自動的に修復します。	定期的なチェックに使用し、大きな破損には使用しないでください。

例：自動修復で強制チェック

# パーティションがアンマウントされていることを確認してください！
sudo fsck -f -y /dev/sdb1

fsckが実行されると、ブロック、iノードリスト、ディレクトリ接続、参照カウント、グループ記述子を検証する5つの主要なフェーズを経ます。

ヒント： ファイルシステムタイプ（例：ext4）がわかっている場合は、ラッパーをバイパスして、より細かい制御のために特定のツールを直接使用できます： sudo e2fsck -f -y /dev/sdb1

4. 一般的なエラーメッセージの理解と処理

修復プロセス中に、fsckは構造エラーを修正する許可をユーザーに求めることがあります。これらのプロンプトを理解することで、最善の行動方針を決定するのに役立ちます。

iノードエラー

エラー： Inode X has invalid block(s). Clear?

意味： iノードXによって記述されたファイルが、無効、未割り当て、または別のファイルに属するブロックを指しています。
アクション： 通常、「はい」を選択するのが正しいアプローチです。そのiノードが表すファイルは失われますが、ファイルシステム構造は維持されます。

ブロックカウントエラー

エラー： Block count for inode X is Y, should be Z. Fix?

意味： メタデータはファイルがYブロックを使用していると信じていますが、物理カウントではZブロックが実際に割り当てられていることが示されています。これは一般的な不整合の形式です。
アクション： カウントの不整合を修正するために常に「はい」を選択します。

ディレクトリエラーと`lost+found`

fsckが存在するが、どのディレクトリエントリにもリンクされていないファイル（iノード）を見つけた場合、それらは孤立していると見なされます。fsckはこれらのファイルを、パーティションのルートにあるlost+foundという特別なディレクトリに自動的に移動します。

`lost+found`からの復旧

fsckが完了したら、パーティションを再マウントし、lost+foundディレクトリに移動します。
ファイルはiノード番号に名前が変更されます（例：#12345）。
これらのファイルを手動で調べて、元の内容を特定し、名前を変更する必要があります。

sudo mount /dev/sdb1 /mnt/data
cd /mnt/data/lost+found
sudo file ./#12345
# テキストの場合は、'cat'または'less'を使用して内容を表示します。

5. 高度な復旧：破損したスーパーブロックへの対処

プライマリスーパーブロックが深刻に破損している場合、fsckは即座に失敗し、構造を読み取れないと報告します。幸いなことに、ext2/3/4ファイルシステムはスーパーブロックのバックアップコピーを保存しています。

バックアップスーパーブロックの検索

バックアップスーパーブロックは、ファイルシステムに依存した場所に保存されています。ファイルシステムの作成時に使用されたのと同じブロックサイズオプションを使用してmke2fs -nでリスト表示できることがよくあります。または、十分なメタデータが読み取り可能なまま残っている場合はdumpe2fsを使用します。-nなしでmke2fsを実行しないでください。新しいファイルシステムが作成されます。

# ファイルシステムを作成せずにバックアップスーパーブロックの場所を表示
sudo mke2fs -n /dev/sdb1

# または、メタデータが十分に読み取り可能な場合、既存のextファイルシステムを検査
sudo dumpe2fs /dev/sdb1 | grep -i 'superblock'

バックアップスーパーブロックからの復元

fsckが失敗した場合、-bオプションを使用して、特定のバックアップスーパーブロックの場所を使用するようにe2fsckを強制できます。

例：ブロック8193にあるバックアップスーパーブロックを使用。

# 注意：パーティションはアンマウントされている必要があります
sudo e2fsck -b 8193 /dev/sdb1

成功した場合、バックアップコピーを使用してファイルシステムメタデータが再構築され、多くの場合完全な復旧につながりますが、最後のクリーンな同期以降に行われた最新の変更が失われる可能性があります。

6. 予防策とベストプラクティス

ファイルシステムの破損を防ぐことは、常に復旧よりも望ましいです。

クリーンなシャットダウン

システムが正常にシャットダウンされることを常に確認してください。突然の電力損失は、カーネルが保留中の書き込みをディスクにフラッシュしていない可能性があるため、メタデータ破損の主な原因です。

定期的な監視

ツールを使用して物理ドライブ（HDD/SSD）の健全性を監視します。smartctlはS.M.A.R.T.データを読み取ることができ、差し迫ったハードウェア障害を示し、これはしばしばファイルシステムの破損に先行します。

# sdaの基本的なSMART健全性データを確認
sudo smartctl -H /dev/sda

ジャーナリングとバックアップ

ext4やXFSのような最新のファイルシステムはジャーナリングを使用して、クラッシュ後に迅速に整合性を回復し、軽微な破損を軽減します。ただし、ジャーナリングは定期的で信頼性の高いバックアップの代わりにはなりません。深刻なハードウェア障害や人為的エラーは、最も堅牢な復旧ツールでさえ回避する可能性があるため、重要なデータの最新のオフサイトバックアップを常に維持してください。

安全な復旧の要点

ファイルシステムの破損が疑われる場合は、まず書き込みを停止し、次に修復します。ログを取得し、データが重要な場合はブロックレベルのバックアップを作成し、ファイルシステムをアンマウントし、ファイルシステムタイプに一致するチェッカーを使用します。修復後、lost+foundを検査し、SMARTデータを確認し、同じ故障ディスクを繰り返し修復する代わりに、疑わしいストレージを交換します。