実際に遭遇した問題
午前2時頃、ポケベルのアラームが鳴り響き、睡眠を中断させられた。重要な本番サーバーがアクセス不能エラーを報告し、ウェブサービス全体が停止した。心臓が締め付けられるような思いで、寒い夜中に緊急事態に対処するおなじみの感覚が押し寄せた。
SSHでログインすると、真っ黒な画面にI/Oエラーのメッセージが表示され、重要なパーティションでデータの読み書きができない状態だった。ウェブサイトには500 Internal Server Errorが表示される。顧客データ全体が失われたり破損したりする危機に瀕していた。
以前、会社の古いCentOS 7サーバーで、望ましいパフォーマンスを達成するためにかなりの最適化を行ったことがある。しかしある夜、突然の長時間停電により、システムは安全にシャットダウンする時間がなかった。電力が回復しサーバーが起動すると、すべてが正常に見えたが、いくつかのアプリケーションがおかしな動作を始め、画像ファイルがロードできず、ログにはファイル読み取りエラーが継続的に記録されていた。ファイルシステムに何らかの問題があることは明らかだった。
このような状況は、特にLinuxシステムにおいてIT環境では非常によくある。ファイルシステムのエラーは、データ損失、アプリケーションの破損、あるいはシステムが起動できなくなる原因となることもある。
原因分析
ファイルシステムは、OSがHDDやSSDなどのストレージデバイス上でファイルを整理・管理するために使用する構造である。これは、必要な本を見つけるのに役立つ、明確なカテゴリとインデックスを持つ巨大な図書館のようなものだ。この構造が破損すると、データアクセスに問題が発生する。
では、どのような原因がファイルシステムのエラーを引き起こすことが多いのだろうか？
- 突然の停電または不適切なシャットダウン: これが主要な原因だ。システムがデータを書き込んでいる最中に突然電源が切れると、書き込み途中の操作によってファイルシステムの構造が破損し、データの整合性が失われ、重要なデータの損失やシステムへのアクセス不能につながる可能性がある。
- ハードウェアエラー: ハードディスクの不良セクタ、コントローラーの故障、またはケーブルの緩みなどが原因でデータの読み書きエラーが発生し、ファイルシステムの破損につながる。
- ソフトウェアまたはドライバーのエラー: Linuxカーネルのバグやストレージデバイスのドライバーのエラーが、ファイルシステムに深刻な問題を引き起こすことがある。
- ドライブ（USB、パーティション）の安全でない取り外し: USBを抜いたり、パーティションを
umountせずに取り外したりすると、書き込み中のデータが破損する可能性がある。 - ユーザーエラー: 誤ったコマンドの実行や、パーティションへの不適切な介入が、ファイルシステムの構造を破損させることがある。
ファイルシステムが上記の問題に遭遇した場合、深刻な結果を避けるために、できるだけ早くチェックし、修復する必要がある。
解決策
fsckの紹介
Linuxにおいて、fsck (File System Consistency Checkの略) は、ファイルシステムのエラーに対処するための強力なツールである。これは、ファイルシステムの整合性をチェックし、修復するのに役立つ強力なコマンドラインユーティリティだ。ファイルシステムにエラーが発生した場合、fsckは構造をスキャンし、破損したinode、重複して占有されたブロック、無効なディレクトリエントリなどのエラーを見つけて、それらを修復しようと試みる。
簡単に言えば、fsckはファイルシステムの「診察」と「治療」を行い、正常で安定した状態に戻すことができる専門医のようなものだ。
fsckの基本的な使い方
fsckを使用する際の黄金律は、常にチェックするパーティションをunmount（アンマウント）してから実行することだ。読み書き中のマウントされたパーティションでfsckを実行すると、深刻な破損や永久的なデータ損失を引き起こす可能性がある。
fsckの基本的な構文は次のとおりだ。
sudo fsck [tùy chọn] <thiết bị>
ここで、<thiết bị>はチェックしたいパーティションへのパス（例: /dev/sdb1、/dev/sdc2）である。パーティションのリストはlsblkコマンドまたはdf -hコマンドで確認できる。
例: /dataにマウントされているパーティション/dev/sdb1をチェックしたい場合:
# ステップ1: パーティションがどこにマウントされているか確認する
df -h /data
# ステップ2: パーティションをアンマウントする
sudo umount /dev/sdb1
# ステップ3: アンマウントされたパーティションでfsckを実行する
sudo fsck /dev/sdb1
fsckがエラーを発見した場合、修復するかどうかを尋ねる（Yes/No）。特に確信が持てない場合は、誤った修復がデータ損失につながる可能性があるため、回答には注意を払うこと。
一般的なfsckオプション
エラー修復プロセスを効率化し、自動化するために、fsckには多くの便利なオプションがある。
-A:/etc/fstabにリストされているすべてのファイルシステムをチェックする（rootファイルシステムを除く）。-t <ファイルシステムタイプ>: ファイルシステムの種類を指定する（例:ext4,xfs,vfat）。これは、fsckが自動的に認識できない場合に役立つ。-y: すべてのエラー修復に自動的に同意する。このオプションは、リスクを十分に理解し、fsckがファイルシステムの整合性を維持するために一部の深刻に破損したファイルを削除する可能性があることを受け入れる場合にのみ、極めて慎重に使用すること。-p: 対話なしで「安全な」エラーを自動的に修復する。このオプションは、システム起動スクリプトでよく使用される。-f: ファイルシステムが「クリーン」とマークされていても、強制的にfsckにチェックさせる。エラーが疑われるものの、fsckが自動的に実行されない場合に役立つ。
オプションの組み合わせ例:
# /dev/sdb1パーティション（ext4タイプ）がクリーンとマークされていても強制的にチェックする
sudo umount /dev/sdb1
sudo fsck -f -t ext4 /dev/sdb1
# fstab内のすべてのパーティションで、すべての安全なエラーを自動的に修復する
sudo fsck -A -p
# /dev/sdc2上のすべてのエラーを自動的に修復する（極めて慎重に）
sudo umount /dev/sdc2
sudo fsck -y /dev/sdc2
ルートファイルシステムのチェック
ルートファイルシステム（「/」パーティション）のチェックは、システム稼働中にunmountできないため、困難な作業である。この状況に対処する主な方法は2つある。
1. リカバリー/シングルユーザーモードで起動する
これは、Live CD/USBがない場合に一般的な方法だ:
- コンピュータを再起動する。
- GRUB画面で、「Advanced options for Linux」または「Recovery mode」を選択する。
- 「Recovery mode」または「single-user mode」オプションを選択する。システムは、rootファイルシステムがリードオンリーモードでマウントされたシェルに起動する。
- この環境では、必要に応じて
fsckを実行するためにrootファイルシステムをリードライトモードで再マウントできるが、通常はrootファイルシステムが自動的にチェックされる。手動で実行する必要がある場合、コマンドは次のようになる:# ルートファイルシステムをリードオンリーモードで再マウントする（安全を確保するために必要であれば） sudo mount -o remount,ro / # ルートファイルシステムでfsckを実行する # システムによっては、ルートデバイス（例: /dev/sda1）を明示的に指定する必要があるかもしれない # ルートデバイスは/etc/fstabまたはmountコマンドの出力で確認できる sudo fsck -f / # または、デバイスが明確な場合: sudo fsck -f /dev/sda1 - 完了したら、
exitまたはrebootと入力してシステムを再起動する。
2. Live CD/USBを使用する
私は通常、より安全で柔軟なこの方法を使用し、推奨する:
- Linux Liveディストリビューション（例: Ubuntu Live CD, SystemRescueCD）でブータブルUSB/CDを作成する。
- Live CD/USBからサーバーを起動する。
- Live環境でターミナルを開く。
lsblkまたはfdisk -lを使用して、破損したシステムのルートパーティション（例:/dev/sda1）を特定する。- そのパーティションで
fsckを実行する（Live環境でマウントされていないことを確認する）:sudo fsck -f /dev/sda1 - エラー修復プロセスが完了したら、サーバーを再起動し、Live CD/USBを取り外す。
失われたデータの復旧
修復プロセス中、fsckはどのファイルにも属さないが情報を含むデータブロックを見つけた場合、それらを復旧しようと試みる。これらのデータは通常、チェックされたパーティションのルートにある特別なディレクトリlost+foundに移動される。
このディレクトリを参照して、失われたファイルを検索できる。これらは通常、inode番号（例: #123456）で名付けられている。元のファイル名とディレクトリ構造が失われているため、これらのファイルを復旧するのは難しい場合がある。しかし、重要なテキストファイルや設定ファイルを見つけて、その内容から識別することは可能だ。
# lost+foundディレクトリに移動する（パーティションがマウントされた後）
cd /data/lost+found/
# ファイルをリストアップする
ls -l
# ファイルの内容を読んで、必要なデータかどうかを確認する
cat #123456
最善の方法
私の経験では、ファイルシステムのエラーに対処するにはfsckの使い方を知るだけでは不十分だ。より重要なのは、効果的な予防戦略を持つことである。
予防が鍵
- システムを正しくシャットダウンする: サーバーをシャットダウンする際は、常に
sudo shutdown -h nowまたはsudo poweroffコマンドを使用し、すべてのデータ書き込み操作が完了していることを確認する。 - UPS (無停電電源装置) を使用する: これは投資する価値がある。UPSは停電時にシステムが安全にシャットダウンするための十分な時間を与え、ファイルシステムエラーの大部分を防ぐ。
- 定期的にドライブのS.M.A.R.Tチェックを行う:
smartctlなどのツールを使用してハードドライブの健全性をチェックする。早期警告は、問題が発生する前にドライブを交換するのに役立つ。 - 定期的なデータバックアップ: これは最終的で最も重要な保護策だ。
fsckがファイルシステムのエラーを修復できたとしても、物理的に破損したデータや完全に削除されたデータを復旧することはできない。バックアップがあればすべてがある。
fsckを使用する必要がある場合
残念ながらファイルシステムにエラーが発生し、fsckを使用する必要がある場合は、以下の手順を実行する。
- 常にパーティションをアンマウントする: チェックする必要があるパーティションがアクティブでないことを確認する。
- 強制チェック（
-f）から始める:sudo fsck -f /dev/<デバイス>を実行して、クリーンとマークされていてもパーティション全体を強制的にチェックする。 - 安全なエラーの自動修復（
-p）を検討する: エラーが軽微で、システムに質問せずに自動的に修復させたい場合は、sudo fsck -p /dev/<デバイス>を使用する。これは起動スクリプトでよく使われる。 - 十分に理解している場合のみ
-yを使用する:fsckがファイルシステムの全体的な構造を救うために、深刻に破損したデータを削除する可能性があるというリスクを受け入れる場合にのみ、sudo fsck -y /dev/<デバイス>を使用する。常に事前にバックアップを検討すること。 - ルートファイルシステムにはLive CD/USBを使用する: ルートパーティションをチェックする必要がある場合、これが最も安全で効果的な方法だ。
以前、会社の古いCentOS 7サーバーが、電源の故障により真夜中にクラッシュしたことがあった。再起動後、いくつかのサービスが起動せず、ログにはI/Oエラーが報告されていた。その時、データパーティションでfsckを実行したことで、多くの重要な設定ファイルを救い、再インストールにかかる何時間もの時間を節約できた。しかし、そこから得た最大の教訓は、定期的なデータバックアップと安定したUPSシステムが必要であり、決して油断してはいけないということだ！
結論
ファイルシステムのエラーは、ITエンジニアにとって悪夢のようなものだ。幸いなことに、Linuxはfsckのような強力なツールを提供し、これらの問題のチェック、診断、修復を可能にする。しかし、fsckの使用には、特に操作前に常にパーティションをアンマウントするという、特定の注意と理解が必要となる。
何よりも、治療よりも予防が重要だ。適切なシャットダウン、UPSの使用、ディスクの健全性監視、そして特に定期的なデータバックアップといった予防策を講じることで、ファイルシステムエラーのリスクを大幅に軽減できる。これにより、Linuxシステムはより安定し、データはより安全になるだろう。
