ファイルシステム · レッスン 10

ファイルシステム修復

ファイルシステムの損傷を診断し、バックアップを用意して、種類に応じたオフライン修復手順を選ぶ方法を学びます。

ファイルシステムの修復では、内部の整合性を回復するためにメタデータを書き換えます。損傷した参照やデータが破棄されることがあり、ストレージハードウェアが故障している場合は損失を悪化させるおそれもあります。修復は復旧操作として扱い、まず証拠と回収可能なデータを保全してから、正確なファイルシステム向けに文書化されたツールを使ってください。

修復前に診断する

I/O エラー、読み取り専用での再マウント、ファイルの消失、マウント失敗といった症状が、すべてファイルシステムの破損を示すとは限りません。まず読み取り専用の証拠を収集します。

$ findmnt --target /affected/path
$ lsblk -f
$ journalctl -k -b

ストレージスタック、デバイスの健全性、ケーブルまたはネットワーク経路、RAID の状態、暗号化、最近の出来事を確認します。デバイスが故障しつつある場合、スキャンを繰り返すと残りの寿命を消費しかねません。可能であれば復旧用ツールでイメージまたは複製を取得し、そのコピーを対象に作業してください。

ハードウェア障害の可能性がある場合、書き込みを伴うファイルシステム修復より先に何を行うべきですか？

正確なファイルシステムとデバイスを特定する

ファイルシステムが、パーティション、論理ボリューム、RAID デバイス、暗号化マッピング、ディスク全体のどこにあるかを調べます。/dev/sda1 のような子パーティションが影響を受けているという理由で、/dev/sda にチェッカーを実行してはいけません。

lsblk -f、blkid、findmnt、各ストレージ層のツールを使って対象を対応付けます。検出用シグネチャは古い場合があるため、既知の設定やバックアップと照合してください。

ext4 が /dev/sda1 に格納されている場合、通常、その ext4 チェッカーにはどの層を渡しますか？

ファイルシステムをオフラインにする

従来の整合性チェッカーの多くは、ファイルシステムをアンマウントした状態で使う必要があります。マウント済みファイルシステムはチェッカーが読む間にも変化し、修復による書き込みがカーネルのキャッシュ状態と競合して破損を引き起こす可能性があります。

依存サービスを停止し、入れ子になったファイルシステムをアンマウントし、プロセスの作業ディレクトリを移動し、必要に応じて上位層を無効化します。ルートファイルシステムでは、レスキュー環境を起動するか、ディストリビューションで文書化されたオフラインチェックの仕組みを使います。関連する名前空間で対象がマウントされていないことを、findmnt で確認してください。

修復チェッカーが書き込む前に、通常はファイルシステムをアンマウントすべきなのはなぜですか？

ファイルシステム固有のツールを使う

fsck は、ファイルシステム固有のヘルパーを呼び出せるフロントエンドです。万能な修復エンジンが 1 つあるわけではありません。たとえば ext ファイルシステムでは e2fsck、XFS では xfs_repair、Btrfs ではファイルシステム固有の診断および復旧ツールを使うというように、手順が異なります。

似た名前のオプションでも意味は異なることがあります。特に、別のファイルシステム向けガイドから --repair や強制オプションを流用してはいけません。インストール済みのマニュアルと、現在のプロジェクトまたはディストリビューションの復旧文書を読んでください。その実装に信頼できる変更なしモードや診断モードがあれば、そこから始めて出力を保存し、提案される修正を理解します。

Linux の fsck が一般に担う役割は何ですか？

検証してサービスを復旧する

修復ツール、バージョン、オプション、出力、終了状態を記録します。修復後は、デバイスの健全性チェックを繰り返し、適切な場合はまず読み取り専用でマウントし、重要データを調べ、既知のバックアップと比較します。その後、カーネルとアプリケーションのログを監視しながら、通常のマウントとサービスを段階的に復旧してください。

マウントできるようになっても、すべてのファイルが正しいとは証明できません。失われたり損傷したりしたアプリケーションデータはバックアップから復元し、アプリケーション層で検証します。

修復後に正常にマウントできれば、すべてのアプリケーションデータが正しいと証明できますか？

レッスン完了