ファイルシステムの破損（？）とfsckの適切な使用
先週の仕事で、Linuxサーバー（CentOS 5.5）がログイン試行に応答しなかったため、ハードシャットダウンする必要がありました。いくつかのディスクを引き出した後、起動時にRAIDアレイの劣化が報告され、fsck-pが手動のfsckの実行を求めるプロンプトに失敗しました。サーバーには、ハードウェアRAID5アレイに5x2TBディスクがあります。ソフトウェア側では、これは/ boot /と/ homeを含む1つの大きな論理ボリュームと、スワップ用の2番目の論理ボリュームに配置されていると思います。
取り外したディスクにRAID構成を再インポートしましたが、その時点でもRAIDアレイは劣化状態を示しており、マシンは起動時にfsckエラーを返します。 5番目のディスクは自動再構築を開始しましたが、おそらくファイルシステムの破損が原因で失敗しました。幸い、レスキューモードを使用してサーバーからデータの2+ TB）を回復することができました（whew！）。次に、論理ボリュームでfsck -yfを実行し、いくつかの変更を加えました。 fsckは起動時にクリーンに戻りますが、Cent OSのログイン画面が表示されると、すべてのフォントが置き換えられたボックスが表示されます。さまざまなエラーが表示され、ログインできませんが、を読むことができません。すべてのボックスであるため、エラーが発生します。テキスト端末（ログインで継続的に再プロンプトが表示されます：、パスワードを入力する機会がありません）またはSSH（サーバーは応答しますが、間違ったパスワードを報告します）を介してログインすることもできません。
この時点で、fsckを実行しようとしましたが、ファイルシステムがクリーンであることがわかります。インストールDVDからレスキューモードでファイルシステムにアクセスすることはできますが、確認したファイルはすべて問題ないようです。完全な再インストールは避けたいと思います。これには、多くの再インストールが必要になり、データをコピーして戻し、レスキューモードからファイルをコピーしても問題がないように見えるためです。論理ボリュームでfsckを実行するか、RAIDを自動再構築することで、完全に失敗しましたか？続行する方法についてのあなたの推奨事項は何ですか？
RAIDシステム（MD）はファイルシステムについて何も認識していないため、再構築に失敗した場合は、ファイルシステムの破損ではなく、ハードウェアエラーが原因である可能性が高くなります。おそらく、ディスクの1つに障害が発生しています。 smartmontoolsを使用してS.M.A.R.T.エラーを確認し、セルフテストを実行します。
Fsck -yfを実行すると、ファイルシステムを修正するために最善を尽くし、その過程で問題のあるiノード（ファイル）が削除される場合があります（一部のファイルはlost + foundフォルダーに移動される場合があります）。グラフィカルログインで表示されたボックスは、fsckによって削除された必要なファイルが原因である可能性があります。コンソールまたはSSH経由でログインできない場合も、ファイルが見つからない可能性があります。リカバリモードで起動した場合、シェルアクセスを取得できますか？バックアップからOSファイルを復元するか、ソフトウェアパッケージを強制的に再インストールすることで、問題の修正を試みることができます。
ただし、この時点で、ディスクを変更してクリーンな再インストールを行う方がよい場合があります。