パーティションがマウントできずシステムがパニックに陥ったとき
昨年、カーネルアップデート後にVPSインスタンスの1つが正常に再起動できなくなった。/dev/sda2上のext4ファイルシステムが破損しているというエラーでカーネルパニックが発生し、起動プロセスが停止した。3年間で10台以上のLinux VPSを管理する中で、本番環境に適用する前にリカバリ手順を徹底的にテストする習慣を身につけていた。その備えがその日を救ってくれた。
ファイルシステムの破損は珍しいケースではない。突然の電源切断、カーネルアップグレードの失敗、ハードウェアの書き込みエラー、あるいはディスクI/O中に突然実行したshutdown -r nowでさえ、ext4パーティションを不整合な状態に陥らせることがある。Linuxにはこれらの問題を検出・修復するためのツールが標準で搭載されている。
このガイドでは、fsckとe2fsckという2つの主要ツールを詳しく解説し、それぞれの使い分けを比較しながら、状況を悪化させずに破損パーティションを復旧する具体的な方法を紹介する。
根本原因：なぜファイルシステムが破損するのか
修復ツールを使う前に、何を修復するのかを理解しておくことが重要だ：
- ダーティアンマウント — 書き込み中に電源が落ちたりカーネルがクラッシュしたりした場合。ジャーナルが正常にフラッシュされなかった。
- 不良セクタ — 物理的なストレージの劣化により書き込みが途中で完了せず、ブロックが未定義状態になる。
- ビットマップの不一致 — inodeやブロック使用量のビットマップが実際のアロケーション状態と一致しなくなる。
- スーパーブロックの破損 — プライマリスーパーブロック（ファイルシステムのメタデータ）が上書きまたはゼロクリアされた。
- 孤立inode — ファイルがオープン中に削除され、inodeを指すディレクトリエントリが存在しない状態になった。
各根本原因によって修復戦略が若干異なるため、fsckとe2fsckの違いを理解することが重要になる。
アプローチの比較：fsck vs e2fsck vs debugfs
ext2/ext3/ext4ファイルシステムの復旧には3つのツールが使われる。それぞれ明確な役割があり、間違ったツールを最初に使うと時間を無駄にし、復旧をより困難にする可能性がある。
fsck（ファイルシステム整合性チェック）
fsckはフロントエンドのディスパッチャーだ。fsck /dev/sda2を実行すると、ファイルシステムタイプを検出して適切なバックエンドに処理を委譲する。ext4の場合はe2fsckに委譲される。複数のパーティションに異なるファイルシステムタイプが混在している場合のスクリプトチェックには最適なエントリーポイントだ。
e2fsck（ext2/ext3/ext4専用）
e2fsckはextファミリーの実際の主力ツールだ。ファイルシステム構造に直接アクセスし、5つのチェックパスを実行する：inode/ブロック/サイズ、ディレクトリ構造、ディレクトリの接続性、参照カウント、グループサマリー情報。fsckラッパーを経由せずにe2fsckを直接実行することで、より詳細なパスごとの出力と修復動作の細かい制御が可能になる。
debugfs（インタラクティブリカバリ）
debugfsは修復ツールではなく、低レベルのファイルシステムデバッガーだ。e2fsckが限界に達したとき、つまり自動修復では対処できないほど深刻な破損が発生したときに使う。この段階では、パーティションが完全に読めなくなる前に、ディレクトリツリーを手動で再構築したり、特定のファイルを取り出したりできる。
各アプローチのメリットとデメリット
fsck
- メリット：シンプルな構文、ファイルシステムタイプを自動検出、シェルスクリプトに便利
- デメリット：e2fsckの詳細を隠蔽、修復動作の制御が限定的、エラーメッセージが汎用的
e2fsck
- メリット：完全な制御が可能、詳細なパスごとの出力、バックアップスーパーブロック復旧をサポート、ジャーナルリプレイに対応
- デメリット：extファミリー専用、事前にファイルシステムタイプを把握している必要がある
debugfs
- メリット：深刻な破損ファイルシステムからファイルを取り出せる、読み取り専用モードが使用可能
- デメリット：手動操作で複雑、内部構造を理解していないと状況を悪化させやすい
日常的なリカバリにはe2fsckを直接使用する。debugfsはe2fsckだけでは対処できない場合にのみ使う。
開始前の推奨準備
マウント中のファイルシステムでfsckを実行するのは危険で、データをさらに破損させる。開始前に確認すべき3つの事項：
- まずディスクイメージを取得する — データが重要な場合は、修復を試みる前にパーティションをクローンする。
- ファイルシステムをアンマウントする — fsckはパーティションがアンマウントされている必要がある。ルートパーティションの場合はライブUSBで起動するか、レスキュー環境を使用する。
- バックアップスーパーブロックの位置をメモする — ext4は既知のオフセットにバックアップスーパーブロックを保存している。プライマリスーパーブロックが破損した場合に必要になる。
パーティションに触れる前にイメージを取得するには：
# パーティションを安全な場所にクローン（外部ディスク、NFSなど）
dd if=/dev/sda2 of=/mnt/backup/sda2.img bs=4M status=progress
# 不良セクタがあるドライブにはddrescueを使用（より良いエラー処理）
apt install gddrescue
ddrescue -d -r3 /dev/sda2 /mnt/backup/sda2.img /mnt/backup/sda2.log問題が発生する前にパーティションのバックアップスーパーブロック位置を確認しておく：
dumpe2fs /dev/sda2 | grep -i "superblock"
# 出力例：32768、98304、163840 ... にバックアップスーパーブロックあり実装ガイド
ステップ1：ファイルシステムの特定とステータス確認
# ファイルシステムタイプを含む全パーティション一覧表示
lsblk -f
# 現在のマウント状態を確認
mount | grep sda2
# 詳細なファイルシステム情報を取得
dumpe2fs -h /dev/sda2 | head -40dumpe2fsの出力でFilesystem state: not cleanを確認する。これはファイルシステムが正常にアンマウントされなかったことを示し、チェックが必要であることを意味する。
ステップ2：ファイルシステムのアンマウント
# ルート以外のパーティションをアンマウント
umount /dev/sda2
# ビジー状態の場合、使用しているプロセスを確認
fuser -km /dev/sda2
lsof | grep sda2ルートパーティションはシステム稼働中にアンマウントできない。ライブのUbuntuまたはDebian USBで起動するか、シングルユーザーモードでシェルにアクセスできる場合は：
# fsck実行前にルートを読み取り専用で再マウント
mount -o remount,ro /ステップ3：e2fsckの実行
# 自動修復付き基本チェック（全プロンプトにyesで回答）
e2fsck -y /dev/sda2
# 各パスの詳細出力
e2fsck -v -y /dev/sda2
# ファイルシステムがクリーンに見えても強制チェック
e2fsck -f /dev/sda2
# チェックしながらプログレスバーを表示
e2fsck -C 0 /dev/sda2-yフラグは無人リカバリに便利だが、実行後の出力を必ず確認すること。すべての修復提案を自動的に受け入れる。通常は問題ないが、深刻な破損の場合、手動介入で回復できたはずのデータを削除してしまう可能性がある。
ステップ4：破損スーパーブロックからの復旧
e2fsckがbad magic number in super-blockを報告した場合、プライマリスーパーブロックが失われている。バックアップを使用する：
# 作成されるスーパーブロック位置を表示（フォーマットはしない）
mke2fs -n /dev/sda2
# 特定のバックアップスーパーブロックでe2fsckを実行
e2fsck -b 32768 /dev/sda2
# 32768が機能しない場合、次のバックアップ位置を試す
e2fsck -b 98304 /dev/sda2
# バックアップからプライマリスーパーブロックを復元することも可能
e2fsck -b 32768 -B 4096 /dev/sda2ステップ5：深刻な破損パーティションからのファイル抽出
e2fsckがパーティションを自動修復できない場合、debugfsを使ってデータが完全に失われる前にファイルを取り出せる。必ず最初に読み取り専用モードで開くこと：
# パーティションを読み取り専用で開く
debugfs -c /dev/sda2
# debugfsインタラクティブシェル内：
debugfs> ls /home/user
debugfs> dump /home/user/important.db /tmp/important.db
debugfs> stat /home/user/important.db
debugfs> quit削除されたファイルを復旧したい場合は？extundeleteの方がdebugfsより優れているが、e2fsckより前に実行すること。fsckがinodeテーブルを変更すると、削除ファイルの復旧可能性が大幅に低下する。
# fsck実行前にextundeleteをインストールして削除ファイルを復旧
apt install extundelete
extundelete /dev/sda2 --restore-all --output-dir /mnt/recoveredステップ6：修復の確認
# e2fsckを再実行 — クリーンな状態に戻るはず
e2fsck -f /dev/sda2
# ファイルシステムの状態を確認
dumpe2fs -h /dev/sda2 | grep "Filesystem state"
# 表示されるはず：Filesystem state: clean
# 再マウントして確認
mount /dev/sda2 /mnt/test
ls /mnt/test
dmesg | tail -20 # マウント後の新しいエラーを確認将来の破損を防ぐために
深夜2時に本番サーバーでこのプロセスを経験した後（おすすめはしない）、標準のVPS設定にこれらを追加した：
# ファイルシステムのチェック間隔を設定（30マウントごとまたは3ヶ月ごと）
tune2fs -c 30 -i 3m /dev/sda2
# 不要な書き込み頻度を減らすためfstabにnoatimeを追加
# /dev/sda2 /data ext4 defaults,noatime 0 2
# ディスクの健全性を週次で監視
apt install smartmontools
systemctl enable smartd
smartctl -a /dev/sda # 完全なSMARTレポート
smartctl -t short /dev/sda # 簡易ヘルステスト目標はファイルシステム復旧の専門家になることではなく、重要なデータにこれらのツールを使わなくて済む状況を作ることだ。定期的なスナップショット、重要データのRAIDまたはレプリケーション、ディスクのSMARTモニタリングを実施すれば、深夜2時のリカバリ作業から解放される。修復コマンドを暗記するよりもはるかに効果的だ。
とはいえ、ファイルシステムが実際に壊れたとき、バックアップスーパーブロックを使ったe2fsck -b 32768に何度もデータを救われた。コマンドを手元に置いておき、何かに触れる前には必ずパーティションのイメージを取得すること。
