EC2をスナップショットでバックアップしていました。バックアップから復旧するときにxfsファイルシステムの破損が発生したので、ファイルの修復を行いました。

1レスキューインスタンスにアタッチする

今回はxfsファイルシステムの破損が発生していたので、xfs_repairコマンドで修復します。xfs_repairコマンドはマウントしているファイルには実行できません。

そのためレスキューインスタンスを起動して破損しているファイル(EBSボリューム)をアタッチします。EBSボリュームをアタッチ、デタッチするときはEC2を停止しておく必要があります。

2ファイルシステムの確認

EBSボリュームを障害復旧のためにレスキュー用のEC2インスタンスにアタッチし、修復が必要なパーティションを確認します。EBSはブロックデバイスであるため、確認にはlsblkコマンドを使用します。lsblkは、システムに認識されているブロックデバイス（SSDやHDDなど）とその構成を表示するためのコマンドです。

sh-5.2$ lsblk
NAME      MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
xvda      202:0    0   8G  0 disk
├─xvda1   202:1    0   8G  0 part /
├─xvda127 259:0    0   1M  0 part
└─xvda128 259:1    0  10M  0 part /boot/efi
xvdb      202:16   0   8G  0 disk
├─xvdb1   202:17   0   8G  0 part
└─xvdb128 259:2    0   1M  0 part

デバイス名はNAME 列のデバイス名は、Linuxカーネルがデバイスを認識した際に割り当てた名前です。ここでは、新たにアタッチしたEBSボリュームがxvdbとして認識され、その中のxvdb1パーティションが修復対象であることがわかります。修復対象のデバイスファイルは/dev/xvdb1となります。

3対象ファイルの修復

2で対象のデバイスファイルがわかったのでxfs_repairコマンドを実行します。

sudo xfs_repair /dev/xvdb1

XFSファイルシステムを修復するプロセスが出力されます。修理が無事に完了したので元のインスタンスへEBSをアタッチします。

4インスタンスが正常に起動しているか確認

インスタンスが正常に起動しているかはステータスチェックや

システムログを確認します。

SSHで接続できればファイルは問題なく修復されたと判断していいと思います。