EC2 のまるごとバックアップを AWS Backup がサポートしたので早速試してみました

AWS バックアップってなんですか？

AWS Backup は、AWS Storage Gateway を使用して、オンプレミスだけでなくクラウド内で AWS のサービス全体のデータのバックアップの集中管理と自動化を簡単に実行できる、完全マネージド型のバックアップサービスです。

EC2 のバックアップ集中管理と自動化に対応しました。

以下の AWS Blog 1月14日号で発表がありました。
https://aws.amazon.com/jp/blogs/aws/aws-backup-ec2-instances-efs-single-file-restore-and-cross-region-backup/

AWS Backup に以下3つの機能が追加されました。

• you can now back up entire Amazon Elastic Compute Cloud (EC2) instances,
• EC2 のバックアップができるようになったよ
• you can now copy your backups to other AWS Regions,
• 取ったバックアップを別の AWS リージョンにコピーできるよ
• and you can now restore a single file from your Elastic File System filesystem instead of the full filesystem.
• Elastic File System(EFS) のファイルシステムのバックアップから、任意のファイルを1ファイルを選んで取り出すことができるよ

というわけで、試してみます。

EC2 の起動と接続

まずはバックアップをとる EC2 を起動します。

設定は以下のとおりです。

インスタンスタイプ：t3a.micro
EBS：8 GiB x2
VPC：デフォルトVPC
サブネット：ap-northeast-1d
Security Group：launch-wizard-10

次に、EC2に接続します。
お手軽に Systems Manager を使います。

そして、EC2 インスタンス内で自分自身(localhost)に対して Ping を打ち続けます。
これは、AWS Backup で EC2 のバックアップを取った際、EC2 インスタンスの再起動が行われるかの確認の意味があります。

sh-4.2$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=255 time=0.017 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=255 time=0.029 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=9 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=10 ttl=255 time=0.029 ms
64 bytes from localhost (127.0.0.1): icmp_seq=11 ttl=255 time=0.030 ms

この状態で、AWS Backup を取ってみます。

AWS Backup の操作

AWS Backup のコンソールを表示し、画面左側のハンバーガーメニュー(≡)をクリックします。
※実際の運用を行う際には、画面右側の「バックアッププランの作成」からプランを作成して、自動化するとよいです。

[ダッシュボード]メニューをクリックし、画面真ん中あたりにある、[オンデマンドバックアップを作成]ボタンをクリックします。

リソースタイプから[EC2]を選択し、インスタンスID から対象の EC2 インスタンスを指定します。
みつからない場合は、ぐるぐるアイコンをクリックしてください。

有効期限切れについては、今回は検証しませんが、ｎ日後とかｎ週間後といった指定をすることで
期限が切れた古いバックアップを自動削除してくれる機能です。

バックアップボールト(Backup Vault)は、バックアップのグループの管理単位です。
初期状態では Default のみ存在しています。必要に応じて、作成しグルーピングを行います。
今回は、Default で試します。

IAM ロールも各環境のポリシーに応じて設定します。今回はデフォルトのロールで試します。
タグは必要に応じて管理用などに使います。未指定でも構いません。
設定ができたら、[オンデマンドバックアップを作成]ボタンをクリックしてバックアップの取得を開始します。

※たまに、[オンデマンドバックアップを作成]ボタンをクリックした際に、IAM ロールのエラーがでます。
※この場合は、デフォルトのロール ⇒ IAMロールを選択してください ⇒ デフォルトのロールとラジオボタンをクリックし、改めて[オンデマンドバックアップを作成]ボタンをクリックすることで続行できます。

バックアップが開始されると、以下の画面に遷移されます。

バックアップジョブIDのリンクをクリックすると、バックアップの詳細情報が確認できます。

バックアップで取得した AMI を確認する

AMI名称は、Nameタグ + インスタンスID + バックアップジョブID で構成される。

バックアップ中の OS 再起動有無を確認する

以下のように、Ping が途切れることなく続いていた。(icmp_seqの値が続いている)

64 bytes from localhost (127.0.0.1): icmp_seq=1805 ttl=255 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1806 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1807 ttl=255 time=0.029 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1808 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1809 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1810 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1811 ttl=255 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1812 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1813 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1814 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1815 ttl=255 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1816 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1817 ttl=255 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1818 ttl=255 time=0.032 ms

合わせて、/var/log/messages内に起動や停止といったログがないかを確認しましたが見当たりませんでした。
OSレベルでの再起動は起こっておらず、また、EC2の停止起動も起きていませんでした。
つまり、AWS Backup による EC2 のバックアップは無停止で行われるようです。

そのため、運用上の必要に応じて以下のような対応が必要です。

• Cloudwatch Events と AWS Lambda を利用して、事前に対象の EC2 インスタンスを停止させておく
• その後、その EC2 インスタンスの起動が必要になる
• いっそのこと、無停止バックアップにしてしまう
• AWS 非推奨でデータの整合性を担保できないので自己責任で・・・

バックアップから復元してみよう

AWS Backup で取得したバックアップから EC2 インスタンスを復元してみましょう。
AWS Backup の EC2 バックアップは定義を含めた丸ごとバックアップのため、復元時もその情報が引き継がれ利用可能なはずです。

では、バックアップボールトを表示し、Defaultの詳細画面を開きます。

対象のバックアップについて、復元ポイントIDから選択して、[復元]ボタンをクリックします。

※復元ポイントIDはimage/ami-idの形式です。

バックアップ取得元の EC2 インスタンスの設定を以下に再掲します。

インスタンスタイプ：t3a.micro
EBS：8 GiB x2
VPC：デフォルトVPC
サブネット：ap-northeast-1d
Security Group：launch-wizard-10

以下はバックアップから復元の画面に表示された情報です。
バックアップ取得元の情報を引き継いでいることがわかります。

そして、復元時に AWS Backup が利用するロールをどうするか選択します。
今回は、デフォルトのロールで試しています。環境のポリシーに応じて設定・選択してください。

必要に応じて、詳細設定を開き、設定を行います。

※ 今回はt3.microで試行していますが、T2/T3 無制限を有効化が無効状態でした。
※ が、復元後に確認してみると「有効化」状態でした。。。

問題がなければ、[バックアップを復元]ボタンをクリックして復元を開始します。

・・・と、デフォルトのロールで実施すると、EC2 インスタンスの復元に失敗しました！
おそらく、デフォルトのロールに EC2 インスタンスを復元するにあたって必要な権限が足りていないのでしょう。

改めて、AWS Backup 用のロールを作成し、権限を付与して実行します。

数分待つと、無事に復元が行われました。

めでたし、めでたし・・・？

復元後の注意点

細かなところでバックアップ取得ともと設定が異なるところがありました。
環境によっては対応しないとならないため、注意が必要です。
以下は本試行で気づいた点ではありますが、記載のないその他のパラメータ(例えば、送信元/送信先チェックなど)の設定を変更している場合も合わせて注意が必要です。

• タグが引き継がれない
• Name タグなしのインスタンスが起動してくる
• 複数、同じ Name タグを持つインスタンスが起動してわかりづらいのを防いでいる？
• プライベート IP アドレス
• 指定するところがない。
• 細かく管理しないのであれば問題はない
• キーペアが埋め込まれない？
• EC2 のコンソールには表示がない。
• Systems Manager - Session Manager では接続が可能
• (前述のとおり)T2/T3 無制限が「無効状態」で復元しても、「有効状態」
• 画面と実際の設定が異なるのが気になる
• 詳細モニタリングの設定箇所がない
• 後から設定ができるので大きな問題ではない

まとめ

リリースされたばかりで痒いところに手が届かなかったり、細かい注意点があったりしますが、
Cloudwatch Events と AWS Lambda を組み合わせて自作実装が必要だった EC2 のバックアップが自動化できるようになったのはアツいです。

また、基本的には何も考えずに同等の EC2 インスタンスを復元できるようになりました。
こちらも細かい注意が必要な点がありますが、それさえ乗り越えて(運用上で問題がないことを確認することで)作業の容易化につなげられるアップデートであると感じました。