ディスクエラーが原因で起動に失敗した EC2 Linux インスタンスを回復する方法を教えてください？

所要時間2分

カスタム Amazon マシンイメージ (AMI) から起動した Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスにディスクエラーがあります。

簡単な説明

カスタム AMI から作成された Amazon EC2 インスタンスで、fstab ファイル内の次の設定ミスが原因でディスクエラーが発生します:

正しくないデバイス ID
正しくないパス名
正しくないまたは重複した UUID

これらのエラーを解決するには、インスタンスのオペレーティングシステムにアクセスする必要があります。インスタンスにアクセスできない場合は、次の方法のいずれかを使用してアクセスします:

EC2 シリアルコンソール
エラーを手動で修正するためのレスキューインスタンス

解決策

EC2 シリアルコンソールを使用する

Linux インスタンス用 EC2 シリアルコンソールを有効にすると、サポートされている Nitro ベースのインスタンスタイプとベアメタルインスタンスのトラブルシューティングに使用できます。シリアルコンソールは、起動の問題やネットワークおよび SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、稼働中のネットワーク接続を必要とせずにインスタンスに接続します。シリアルコンソールにアクセスするには、Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用します。

EC2 シリアルコンソールを初めて使用する場合は、接続を試みる前に必要条件とアクセスを設定を必ず確認してください。インスタンスにアクセスできず、シリアルコンソールへのアクセスを設定していない場合は、次のセクション「レスキューインスタンスを使用してエラーを手動で修正する」の手順に従ってください。EC2 シリアルコンソールの設定については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

レスキューインスタンスを使用してエラーを手動で修正する

警告: 以下の手順では、インスタンスを停止する必要があります。インスタンスストアボリュームに保存されているデータは、インスタンスが停止されると失われます。インスタンスを停止する前に、必ずデータのバックアップを保存してください。Amazon Elastic Block Store (Amazon EBS) バックアップボリュームとは異なり、インスタンスストアボリュームは一時的なものであり、データの永続性をサポートしていません。

Amazon EC2 が起動時または開始時にインスタンスに自動的に割り当てた静的パブリック IPv4 アドレスは、停止および起動後に変更されます。インスタンスが停止しても変わらないパブリック IPv4 アドレスを維持するには、Elastic IP アドレスを使用してください。

詳細については、「インスタンスを停止するとどうなるか」を参照してください。

1. ディスクエラーが発生したインスタンスと同じ AMI を使用して、仮想プライベートクラウド (VPC) 内で新しい EC2 インスタンスを起動します。障害のあるインスタンスと同じアベイラビリティーゾーンで、新しいインスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。

または、同じ AMI を使用し、障害のあるインスタンスと同じアベイラビリティーゾーンにある既存のインスタンスを使用します。

2. 障害のあるインスタンスを停止します。

3. 障害のあるインスタンスから Amazon EBS ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。ルートボリュームのデバイス名 (/dev/xvda または /dev/sda1) を書き留めておきます。

4. レスキューインスタンスに、セカンダリデバイス (/dev/sdf) としてボリュームをアタッチします。

5. SSH を使用してレスキューインスタンスに接続します。

6. レスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します:

$ sudo mkdir /rescue

7. ディレクトリにボリュームをマウントします:

$ sudo mount /dev/xvdf1 /rescue

注: デバイス (/dev/xvdf1) は別のデバイス名でレスキューインスタンスにアタッチされている可能性があります。正しいデバイス名を確認するには、lsblk コマンドを使用して、使用可能なディスクデバイスとそのマウントポイントを表示します。

7. ボリュームのトラブルシューティング:

次のコマンドを実行して fstab エントリを確認します:

$ cat /rescue/etc/fstab

以下の例では、fstab エントリには 2 つのボリュームがあります:

UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1
UUID=1b75bcf4-ee55-428e-8d68-88dca398da01 /test xfs defaults,nofail 0 2

fstab エントリで、次の設定を確認します:

エントリにデバイス ID が含まれていないかどうかを確認します。デバイス ID が正しくないと、問題や不一致の原因になります。デバイス ID の代わりに UUID を使用するのがベストプラクティスです。デバイス ID がファイルにある場合は、それらをボリュームの UUID で置き換えてください。以下のコマンドを実行して、正しい UUID を見つけてください:
```
lsblk -f
```
マウントポイントのパスが正しく、ボリュームに存在することを確認してください。
重複する UUID がないことを確認します。また、障害が発生しているインスタンス上の追加のボリュームが同じ UUID を使用していないことも確認してください。追加のボリュームの UUID を確認するには、前述の手順に従ってそれらをレスキューインスタンスにアタッチします。UUID が重複している場合、ボリュームをマウントすることができず、以下のようなエラーが表示されます:
```
mount: /rescue: wrong fs type, bad option, bad superblock on /dev/xvdg1, missing codepage or helper program, or other error
```
次のコマンドを実行して、アタッチされているボリュームの UUID を確認します:
```
$ lsblk -f
```
UUID が重複している場合は、次のコマンドを実行して UUID を変更します:

XFS ファイルシステムの場合:
```
$ sudo xfs_admin -U <unique UUID> /dev/xvdb1
```
EXT4 ファイルシステムの場合:
```
$ tune2fs -U random /dev/sdb1
```
また、次の例のように、fstab エントリに nofail オプションを追加します:
```
UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2
```
注: 特定のボリュームをアタッチせずにインスタンスを起動する場合、nofail マウントオプションにより、マウントエラーが発生してもインスタンスは起動できます。例えば、ボリュームを別のインスタンスに移動した後にインスタンスを起動しようとする場合があります。Debian 派生 (16.04 より前のバージョンの Ubuntu を含む) は、nobootwait マウントオプションも追加する必要があります。