Linuxでファイルシステムを
検査・修復する

結論：修復より先に停止・記録・バックアップ

1. 書き込みを止め、エラーと現在構成を記録する
2. SMARTとOSログで物理障害の可能性を確認する
3. 重要データを別の正常な媒体へバックアップする
4. 対象デバイスとファイルシステム形式を特定する
5. アンマウントして読み取り専用の検査を行う
6. 結果を確認してから形式別の修復を実行する
7. 再マウント後にデータとログを検証する

SMART検査とfsckは目的が違う

I/Oエラーが続くドライブへ修復処理を繰り返すと、状態を悪化させる可能性があります。物理障害が疑われる場合は、先にsmartctl・nvme-cliによるディスク検査とバックアップを行います。

対象とファイルシステム形式を特定する

findmnt --target /data
lsblk -f
df -hT /data

findmntで、マウントポイント、実デバイス、形式を対応させます。LVMでは/dev/mapper/...や/dev/volume-group/logical-volumeが対象になるため、下層の物理ディスクへ直接ファイルシステム検査を実行してはいけません。

発生したエラーも、再起動前に別媒体へ保存します。

sudo journalctl -k -b | grep -Ei 'I/O error|EXT4-fs|XFS|corrupt|reset|timeout'
sudo dmesg --level=err,warn

アンマウントできる状態を作る

findmnt --target /data
sudo fuser -vm /data
sudo umount /data

利用中なら、表示されたプロセスやサービスを確認して正常な手順で停止します。/、/var、/homeなど稼働中に外せない領域は、レスキューモードやLive環境から検査します。

マウント中のファイルシステムへ修復を実行しないでください。ext4では-nを付けても検査結果が有効とは限らず、XFSも修復対象をアンマウントする必要があります。

fsckはファイルシステム別ツールの入口

fsckは、対象形式に応じてfsck.ext4などを呼び出すフロントエンドです。形式ごとの挙動が同じになるわけではありません。

lsblk -f
sudo fsck -N /dev/vg_data/lv_data

-Nは実行せず、呼び出す予定のコマンドを表示します。対象確認には使えますが、実際の検査結果を返すオプションではありません。

ext4をe2fsckで検査する

アンマウント済みのext2、ext3、ext4を変更せず検査する例です。

sudo e2fsck -n /dev/vg_data/lv_data
echo $?

-nは質問へ「no」と答え、ファイルシステムを変更しません。ただし本来なら前段階で修復される不整合が残るため、後半で追加エラーが表示される場合があります。出力と終了コードを保存します。

調査用のメタデータイメージを、対象とは別の正常なファイルシステムへ保存する方法もあります。

sudo e2image -Q /dev/vg_data/lv_data /mnt/backup/lv_data.e2i

バックアップと検査結果を確認し、自動的に安全な修復だけを行う場合は次の方法があります。

sudo e2fsck -p /dev/vg_data/lv_data

未修復の問題や再起動要求は終了コードへ反映されます。-yですべてに無条件で同意する前に、データの重要性と復元手段を確認します。

XFSをxfs_repairで検査する

XFSではfsck.xfsが実質的な検査を行うわけではありません。アンマウント済みの対象をxfs_repair -nで変更せず確認します。

sudo xfs_repair -n /dev/vg_data/lv_data
echo $?

XFSのログがdirtyな場合、通常は同じCPUアーキテクチャのカーネルで一度マウントし、ログを再生してからアンマウントします。マウントが失敗する場合は作業を止め、エラーとバックアップ状況を確認します。

修復前のメタデータを調査用に保存する例です。

sudo xfs_metadump /dev/vg_data/lv_data /mnt/backup/lv_data.metadump

バックアップと読み取り検査を確認した後、アンマウント済みのXFSを修復します。

sudo xfs_repair /dev/vg_data/lv_data

修復後に確認する

sudo mount /data
findmnt --target /data
df -hT /data
sudo journalctl -k -b | tail -100

重要ファイルを開けるか、アプリケーションがデータを読めるか、所有者と権限が期待どおりかを確認します。可能なら既知のチェックサムやバックアップと比較します。修復後もI/Oエラーが発生するなら、媒体や接続経路の問題として扱います。

修復より交換を優先する場合

• SMARTの重大警告、media error、回復不能エラーがある
• OSログでI/Oエラーやデバイスリセットが繰り返される
• 修復後に同じ破損が再発する
• ドライブを安定して読み出せず、バックアップも完了していない

物理ドライブの信頼性を回復するためにfsckを繰り返してはいけません。交換が必要なら、Linux用SSDの選び方で接続方式、容量、耐久性を確認します。

実行前チェックリスト

参考資料

• Red Hat：ファイルシステムの検査と修復
• Linux manual page：fsck(8)
• Linux manual page：e2fsck(8)
• Linux manual page：xfs_repair(8)