ディスクに異常が疑われるときのファイルシステム検査と修復手順

ディスクエラーが疑われる状況や、突然の電源断が起きたあと、まず試すべきツールが fsck です。ext4・XFS・Btrfs など主要なファイルシステムに対応しており、整合性のチェックと自動修復を一括して行えます。ただし「マウントしたままでは実行しない」というルールを守らないと、逆にデータ破損を引き起こします。この記事ではその前提から順を追って説明します。

大前提：対象デバイスはアンマウントしてから実行する

マウントしたままのファイルシステムに fsck を実行すると、OS が書き込みを行いながら整合性を修正しようとし、深刻なデータ破損につながります。実行前に lsblk でデバイス名を確認し、対象が何にマウントされているかを確認してから umount を行ってください。

# ブロックデバイスとマウントポイントを確認する
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTS

# 対象をアンマウントする（例: /dev/sdb1 が /data にマウントされている場合）
umount /data

# アンマウントできたかを確認する
lsblk -o NAME,MOUNTPOINTS /dev/sdb1

「デバイスが使用中でアンマウントできない」と表示される場合は、lsof /data でそのマウントポイントを開いているプロセスを特定し、停止してから再試行してください。

データパーティションを検査する（基本パターン）

アンマウント済みであれば、以下のコマンドで検査できます。-n はドライランオプションで、修復を行わず確認だけを行います。まず -n で状況を把握し、修復が必要であれば改めて実行するのが安全です。

# 読み取り専用で確認のみ行う（修復はしない）
fsck -n /dev/sdb1

# 異常を自動修復する（確認プロンプトにすべて yes と答える）
fsck -y /dev/sdb1

# 強制的に全ブロックを検査する（時間はかかるが徹底的）
fsck -f /dev/sdb1

問題が検出されなかった場合は clean と表示されます。XFS ファイルシステムの場合は fsck.xfs ではなく xfs_repair を使用してください（fsck.xfs は実質的に何もしません）。Btrfs の場合は btrfs check です。

# XFS の修復（アンマウント必須）
xfs_repair /dev/sdb1

# Btrfs のチェック（読み取り専用）
btrfs check /dev/sdb1

ルートパーティションを検査する場合はレスキューモードで

稼働中のシステムではルートパーティション（/）をアンマウントできません。ルートを含むパーティションを検査するには、systemd のレスキューモードを使います。シングルユーザーモードより安全に最小構成で起動でき、/ が読み取り専用でマウントされた状態になります。

# レスキューモードへ移行する
systemctl rescue

# レスキューモード内でルートパーティションを再マウント（読み取り専用にする）
mount -o remount,ro /

# ルートパーティションのデバイス名を確認してから検査する
findmnt /
fsck -y /dev/sda1

GRUB 画面が表示される環境では、カーネルオプションに systemd.unit=rescue.target を追記してブートすることでも同じ状態に移行できます。検査が終わったら systemctl default または reboot で通常起動に戻します。

なお、ある運用現場ではライブ USB（AlmaLinux や Ubuntu のインストールメディア）から起動してルートパーティションを検査する方法も標準手順として採用しています。このアプローチだと対象の / が完全にアンマウントされた状態でアクセスできるため、より確実です。

終了コードで結果を正確に読む

fsck はスクリプトや監視ツールから呼び出すことも多いため、終了コードの意味を把握しておくことが重要です。複数の状態が同時に発生した場合は、対応するコードの論理和（ビット OR）が返ります。

fsck -y /dev/sdb1
echo "終了コード: $?"

終了コードの意味は以下のとおりです。

0   : 異常なし（clean）
1   : ファイルシステムの異常が修復された
2   : システムを再起動する必要がある
4   : 異常が修復されずに残っている（手動対応が必要）
8   : 操作エラー
16  : 使用法または文法エラー
32  : ユーザー操作によりキャンセルされた
128 : 共有ライブラリエラー

終了コード 4 が返った場合は自動修復に失敗しており、データ損傷が残っている可能性があります。この場合はバックアップの確認を最優先にしたうえで、e2fsck -c による不良ブロック検査や、より詳細なオプションでの再実行を検討してください。

起動時の自動チェックを制御する（fstab の pass フィールド）

systemd 環境では起動時に systemd-fsck が自動実行されます。どのパーティションをチェックするかは /etc/fstab の第6フィールド（pass）で制御されています。

# /etc/fstab の例
# デバイス          マウントポイント FS種別 オプション dump pass
/dev/sda1            /boot           ext4   defaults   0    2
/dev/mapper/rl-root  /               xfs    defaults   0    0
/dev/sdb1            /data           ext4   defaults   0    2

pass フィールドの値の意味は次のとおりです。0 はチェックをスキップ、1 はルートパーティション（最初にチェック）、2 はその他のパーティション（並行してチェック）。XFS や Btrfs は起動時の fsck チェックが不要または非対応のため 0 にします。

作業前に確認したいチェックリスト

実務で fsck を実行する前に、以下の点を確認しておくと安全です。

# 1. デバイス名の確認（/dev/hda は古い表記。現在は /dev/sda や /dev/nvme0n1）
lsblk
ls /dev/disk/by-id/

# 2. ファイルシステムの種類を確認（ext4 と XFS では使うコマンドが異なる）
blkid /dev/sdb1

# 3. 直近のカーネルエラーを確認（ハードウェア障害との切り分け）
journalctl -k --since "1 hour ago" | grep -i "error\|fail\|bad sector"

# 4. S.M.A.R.T. でディスクの健康状態を確認（ハードウェア障害が先にある場合）
smartctl -a /dev/sdb

journalctl -k でハードウェアレベルの I/O エラーが多発している場合は、fsck よりもディスク交換を先に検討してください。ファイルシステムを修復しても物理的な障害がある状態では、すぐに再発します。バックアップからのリストアと並行してディスクの S.M.A.R.T. 値を確認するのが、現場での定石です。