午前2時の本番環境クライシス重大な監視アラートを受信しました。データベースやアプリケーションがオフラインになっています。サーバーにログインしてデータディレクトリを確認しようとすると、ターミナルに謎めいたメッセージが表示されます。
ls: cannot access '/data/mysql': Structure needs cleaning
このエラー（技術的には EUCLEAN）は保護機能の一種です。ファイルシステムが深刻なメタデータの破損を検出し、さらなるデータ損失を防ぐために自身をロックしたことを意味します。通常、突然の停電、SANの接続トラブル、または最悪のタイミングでのハードドライブの故障によって発生します。
ステップ 1: 破損したパーティションを特定するどのディスクが故障しているか推測で判断しないでください。カーネルログを確認して、実際に何が起きたのかを正確に把握する必要があります。以下のコマンドを実行して、直近のシステムイベントを確認してください。
dmesg | grep -Ei 'xfs|ext4|error' | tail -n 20
特定のハードウェアアドレスやマウントポイントを探します。典型的なエラーは次のようになります：XFS (sdb1): Internal error xfs_trans_cancel at line 984。デバイス名（例：/dev/sdb1）が判明したら、そのマウントポイントを確認します。
df -h | grep /dev/sdb1
ステップ 2: 対象パーティションをアンマウントするマウントされた状態のファイルシステムを修復しようとするのは、データを完全に破壊する行為です。まずパーティションをオフラインにする必要があります。データ用ドライブの場合は、関連するサービス（NginxやMySQLなど）を停止してからアンマウントしてください。
sudo umount /dev/sdb1
デバイスが使用中（busy）と表示される場合は、lsof または fuser を使用して原因となっているプロセスを特定します。
sudo fuser -mv /mnt/data_folder
それらのプロセスを終了させ、再度アンマウントを試行します。ドライブがルートパーティション（/）の場合は、Live ISOから起動するか、レスキューモードに入る必要があります。
ステップ 3: Repairing XFS (最も一般的なケース)XFSはRHEL、Rocky、CentOSのデフォルトです。ディスクがXFSを使用している場合、xfs_repair が主要なツールになります。まずは標準的な修復を試みてください。
sudo xfs_repair /dev/sdb1
ログが「ダーティ（Dirty）」な場合システムが最近クラッシュした場合、xfs_repair の実行が拒否されることがあります。ログに未書き込みのデータが含まれているというメッセージが表示され、ドライブをマウントしてログを「リプレイ」するように促されます。マウントに失敗して手詰まりになった場合、この特定のシナリオでは「最終手段」のフラグが必要になることがあります。
sudo xfs_repair -L /dev/sdb1
-L フラグ（Force Log Zeroing）は、ファイルシステムのログを消去します。これによりパーティションはオンラインに戻りますが、クラッシュ直前の数秒間に書き込まれたデータが失われる可能性があります。標準の修復が失敗した場合にのみ使用してください。
ステップ 4: ext4ファイルシステムの修復UbuntuやDebianシステムでext4を使用している場合は、代わりに fsck ユーティリティを使用します。ファイルシステムが「clean」とマークされていても、-f フラグを使用して強制的にチェックを行う必要があります。
sudo fsck.ext4 -fy /dev/sdb1
-y フラグは、すべての修復プロンプトに対して自動的に「yes」と回答します。ひどく破損したext4ドライブでは、何百もの修正プロンプトが表示されることがあるため、このフラグが役立ちます。
ステップ 5: 確認と再マウント修復ツールが成功を報告したら、ドライブを再度マウントしてみます。ディレクトリの内容を確認し、ファイルが見えることを確認してください。
sudo mount /dev/sdb1 /mnt/data_folder
ls -la /mnt/data_folder
その後数分間は dmesg を注視してください。エラーがすぐに再発する場合は、基盤となるハードウェアが故障している可能性があります。