今回はEC2の「バックアップ」と「復元」について基本的なところを書いていきます。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava1n_face240.jpg)
EC2を誤って終了してしまったり、EC2内のデータ復元等に備えて、バックアップは基本であり重要です。
本記事では「AMI」取得をバックアップとして扱います。
AMI取得はスナップショット取得の上位互換です。AMIを取得すればEBSのスナップショット(バックアップ)に加えて、構成情報も取得出来ます。構成情報とは プラットフォーム、アーキテクチャ、仮想化タイプ、ルートデバイス名、ルートデバイスタイプ…等です。AMIがあれば「EC2インスタンス」自体を消してしまっても、簡単に復元することが出来ます。
![](https://na7log.com/wp-content/uploads/2021/12/image-28.png)
※昔は「AMI」の世代管理は簡単には出来なかったようです(スクリプトを組む必要があった)。現在では「ライフサイクルマネージャ」や「AWS Backup」を使うと簡単に出来ます。取得方法の種類については別記事でまとめます(今回は取得と復元を目的とします)。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava3n_face2.jpg)
事前解説が長くなりましたが、本編いきます!
AMIの作成
![](https://na7log.com/wp-content/uploads/2021/12/image-29.png)
AMIの作成は色々な方法(手動・DLM・AWS Backup)がありますが、今回は任意EC2に対して手動で実施します。公式サイトにも記事があります。
■イメージ作成
任意EC2を選択して右クリックメニューより「イメージとテンプレート」→「イメージの作成」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-26.jpg)
■必要事項の入力
「イメージを作成」の画面が表示されるため、以下を入力してイメージの作成を行います。
- イメージ名:イメージ名を入力。
- イメージの説明:イメージの説明を入力。
- 再起動しない:通常は未チェック。
※未チェック=再起動が発生します。チェックした場合、再起動は発生しませんが、整合性が担保されません。 - タグキー:Name等を付けたほうが管理しやすい。
![](https://na7log.com/wp-content/uploads/2021/12/image-26.png)
![](https://na7log.com/wp-content/uploads/2021/12/image-26-2.jpg)
■イメージ作成後
容量やタイミング依存ですが、数分~10分程度でAMIが完成します。
![](https://na7log.com/wp-content/uploads/2021/12/image-27.png)
また、AMIに関連するスナップショットも作られたことが確認できます。
![](https://na7log.com/wp-content/uploads/2021/12/image-30.png)
AMIからの復元
復元は大きく2ケースあります。
![](https://na7log.com/wp-content/uploads/2021/12/image-41.png)
- Case1:EBSボリュームに障害(起動NGやデータ紛失)が生じたため、過去のバックアップから復元(ボリューム差し替え)したい。
- Case2:EC2に障害発生、またはEC2を終了(削除)してしまったため、過去のバックアップから復元(作り直し)したい。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava1n_face240.jpg)
以降、具体的な手順を書いていきます。
Case1:EBSボリュームの復元
次のステップで進めます。(該当EC2は停止状態とします)
- 任意SnapshotからEBSボリュームを作成する。
- 該当EC2から障害となったEBSボリュームをデタッチする。
- 該当EC2に「1」で作成したEBSボリュームをアタッチする。
![](https://na7log.com/wp-content/uploads/2021/12/image-42.png)
SnapshotからEBSボリュームを作成
該当Snapshotを選択し、右クリックメニューより「スナップショットからボリュームを作成」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-31.png)
次に、ボリュームの設定画面が表示されるため、適切なボリュームタイプやAZを選択してボリュームの作成を確定させます。
![](https://na7log.com/wp-content/uploads/2021/12/image-32.png)
ボリュームメニューより、該当ボリュームのボリュームの状態が「利用可能」となっていればOKです。
![](https://na7log.com/wp-content/uploads/2021/12/image-33.png)
EBSボリュームをデタッチ
該当EC2からデタッチ(取り外す)ボリュームを確認し「デバイス名」をメモしておきます(後でアタッチの際に使います)。次にボリュームIDをクリックしてボリュームメニューに進みます。
![](https://na7log.com/wp-content/uploads/2021/12/image-38.png)
ボリュームメニューが表示された後、該当ボリュームを選択し、右クリックメニューより「ボリュームのデタッチ」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-35.png)
確認が表示されるため「デタッチ」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-36.png)
EBSボリュームをアタッチ
先ほどSnapshotから作成したボリュームを選択し、右クリックメニューより「ボリュームのアタッチ」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-37.png)
ボリュームのアタッチ画面が表示されるため、必要事項を選択/入力してアタッチを行います。
- インスタンス:アタッチ対象のEC2を選択します。
- デバイス名:先ほどデタッチする前にメモしたデバイス名を入力します。
![](https://na7log.com/wp-content/uploads/2021/12/image-39.jpg)
![](https://na7log.com/wp-content/uploads/2021/12/image-39.png)
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava1n_face240.jpg)
以上で完了です。後はECを開始させて問題なく復元できているか確認しましょう。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava3n_face2.jpg)
デタッチした障害ボリュームは不要であれば別途削除しましょう。
Case2:EC2の復元
次のステップで進めます。
- 障害EC2を終了します。
※後でじっくり解析したい場合は現時点をバックアップしてもOKです。またEC2を終了せずに新しいEC2として起動してもOKですがPrivateIP等は別物になります。 - 任意AMIから新規EC2を起動する。
![](https://na7log.com/wp-content/uploads/2021/12/image-43.png)
障害EC2の終了
障害となったEC2を停止させます。
- Private IP等、必要情報はメモしておきます。
- 終了保護をしている場合は、解除しないと終了出来ません。
AMIを新規EC2を起動
復旧時点としたいAMIを選択し、右クリックメニューより「イメージからインスタンスを起動」をクリックします。
![](https://na7log.com/wp-content/uploads/2021/12/image-40.png)
見慣れたインスタンス起動時のメニューになるため、インスタンスタイプや詳細(VPCやサブネット、PrivateIP等)を入力して起動させます。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava1n_face240.jpg)
手順は以上となります。簡単ですね。
補足事項や注意点など
■バックアップ先やコスト
スナップショットのバックアップ先はS3です。S3のためデータが損失する可能性は極めて低いと考えられます。(オンプレの場合は別拠点に転送して災害対策を実施していたが、AWSのS3は強固のため別リージョンへの転送は未実施という判断も方針によってはありえます。)
1GB辺り月額「0.05$」かかります。
初回バックアップはフルバックアップのため、EBS容量×0.05$が毎月かかることになります。2回目以降のバックアップは増分バックアップです。(初回分を後から消しても内部的には保持されている為か、2回目以降のバックアップは消えませんし復元可能です。)
■バックアップの整合性
基本的にAMIを作成する際は、EC2を停止すべきです。バックアップ方法によってはVSSが動作してOS整合までは取ってくれる場合もありますが、アプリ整合までは保証されません(何か作り込みすれば保証出来る方法もある)。
■復元直後はボリュームのパフォーマンスが落ちます
バックアップはS3にあり、順次データを引っ張ってきている状態のため、すぐにはボリュームのパフォーマンスが出ません。
※対処方法としてボリューム全体をOS側で読み込むという手があるようです。さらに別の手段として「高速スナップショット」という機能を有効にしておくと、復元時にすぐに最大パフォーマンスを発揮できるようです。(ただし高速スナップショットを有効にしておくと、結構なコストが日々加算されます。)
■AMI削除とスナップショットの削除
AMIだけを削除しても関連スナップショットは消えません。別途スナップショットの削除操作が必要です。(中にはAMI削除のイベントをトリガにスナップショットを自動削除するlambda関数を作る人もいるようです)
まとめ
EC2バックアック(AMI作成)と復元を紹介しました。
- バックアップとして定期的にAMI(構成+EBSスナップショット)を作成すべきです。
- 復元パターンとしては「ボリューム」「EC2」単位があります。
いざって時に慌てないように、一通り検証しておくことをおすすめします。
![](https://na7log.com/wp-content/uploads/2022/02/sky_ava1u_body_face2.jpg)
最後までご覧いただき、ありがとうございました。
コメント