前回「AWS動作検証【2】（SystemsManagerパッチ配信設定）」の続きとなります。
■■ 筆者情報 ■■
・AWSの資格試験はプロフェッショナルまで取得済。
・AWSの操作経験は初心者並み。
・理論は解っていても操作は解っていない状況。
※資格試験取得に興味のある方は「AWS認定試験の勉強方法」を参照ください。
■■ この記事を読んでほしい対象 ■■
・AWSの知識はある程度ついたので、AWS操作を一通り実施したい人。
・AWS公式ドキュメントをベースに手順を確認したい人。
※手順を簡単にまとめてくれているサイトも多々ありますが、可能な限りAWSの公式ドキュメントを読み解きながら確認を実施しています。その為、この記事のリンクの多くは公式ドキュメントに対して貼られており、どうしても公式ドキュメントのみだと解らない場合に、個人のHPを頼っています。
■■ AWSのEC2バックアップの方法 ■■
まずバックアップの動作確認を実施する前に前提を整理しました。AWSのバックアップは「AWSを使用したバックアップと復元の手法」に整理されています。その中でサーバのバックアップに関しては「EBSのスナップショット」と「AMIイメージ」でバックアップが必要なことが記載されています。「EBSのスナップショット」と「AMIイメージ」の違いは「AWSトレーニングでよくいただくご質問シリーズ - 第一回 Amazon Machine Image (AMI) とスナップショットの違い」というAWS公式ブログに以下のように記載されています。
スナップショット = 「EBS ボリュームの中のデータ」を特定のタイミングで取得しS3に保存したもの
AMI = 「EBS ボリュームの中のデータ(スナップショット) とインスタンスを構成する管理情報」を含む起動テンプレート
上記の条件だとAMIイメージだけ取得すればすべて包括されていると考えると思いますが、AMIイメージのバックアップ取得はAWSの標準機能だけでは自動化できないのがネックです。
しかし、AWSは2020年1月に新機能を発表しました。AWS BackupでAMIイメージも含めたバックアップの取得及び自動化が可能になったのです。ですので、私の理解は以下の通りとなります。
| バックアップ機能 | バックアップ対象 | スケジュール自動化 |
|---|---|---|
| AMIイメージ | 構成情報＋EBSスナップショット | × |
| EBSスナップショット | EBSスナップショット | 〇 |
| AWS Backup | 構成情報＋EBSスナップショット | 〇 |
今だとAWS Backupを利用するのがよいと思ったので、そのテストを実施することにしました。
■AWS BackupによるEC2バックアップ実施（スケジュール実行）
バックアップ方法にはスケジュール実行できるものと、即時実行できるものがあります。まずはスケジュール実行できるものを実施しました。
バックアッププランの作成（AWS Backup）
まずプランを作成します。今回は既存ルールから「Daily-Monthry-1yr-Retention」を選択しました。これは、日次と月次のバックアッププランがセットになったものです。
「Daily-Monthry-1yr-Retention」のバックアップルールは以下の通りです。
バックアップがすぐに開始されるように「DailyBackups」のスケジュールで「バックアップウィンドウをカスタマイズ」を選択して、現在時刻の少し後に時間を設定しました。ただし、この設定時間でバックアップ処理がはじまるのではなく、実際には「次の時間以内に開始」の範囲内で処理が始まるようです。
バックアッププランへのリソースの割当（AWS Backup）
リソースの選択では、バックアップ対象のEC2を指定します。サーバ単位でも設定できますが、今回はタグで対象サーバを設定しました。この設定のおかげで同じタグ設定しているサーバは、同時にバックアップを取得することができます。
バックアップ結果の確認（AWS Backup）
しばらく時間を置いて確認するとAWS Backupダッシュボード画面に以下のように表示されました。
登録していたバックアップが正常に完了したようです。
「バックアップジョブ」の詳細を確認すると「2020年4月20日23：48」(UTC+09:00=日本時間)に開始されていました。バックアップ設定では「PM02:45」(UTC)に設定しており日本時間では「PM11:45」なので、概ね設定どおりに開始されていることが解ります。
「バックアップジョブID」から結果の詳細を確認します。処理時間は36分でした。OS環境はWindows2016のAMIから起動させてほとんど触っていない状況でのバックアップでした。
バックアップ対象であったOS環境のシステムログを確認するとバックアップ取得時間帯にOS停止した形跡がありません。その為、バックアップはOS起動状態で取得されたことが解ります。業務によっては事前にサービスを停止しておく等、何らかの事前処理が必要になりそうです。
保護されたリソースには取得したバックアップ情報が表示されます。
保護されたリソースの詳細情報は以下の通りです。
また、EC2のAMI画面に新規のAMIが作成されています。
EBSスナップショットにも新規のスナップショットが作成されています。
これを見る限り、AWS Backupは結果的にはAMI作成とEBSスナップショットを操作や管理を一元的に実施できるツールであることが解ります。特段問題が内容ならAWSのEC2バックアップはAWS backup一択でよいのかと思いました。
■AWS BackupによるEC2復元実施
先ほど取得したバックアップを復元します。
復元（AWS Backup）
復元では以下の設定画面が表示されます。VPCやサブネット、セキュリティグループ等を設定して復元を開始します。
■AWS BackupによるEC2復元後の問題
問題が2つ発生しました。１つはキーペアが設定されていない状況になっていること。2つ目はパブリックIPが設定されていない状況になっていること。
2つ目のパブリックIPが設定されていない状況になっているのは、サブネットの問題でした。サブネットの「パブリックのIPv4アドレスの自動設定」が「いいえ」になっていたのが原因です。その為、この設定を「はい」にした上で、再度バックアップからの復元を実施しました。この結果、パブリックIPの表示は問題なく実施されるようになりました。
もう一つの問題であるキーペアが表示されなくなった点ですが、これは現状における仕様のようです。色々調べた結果、バックアップ前のキーペアがそのまま使用できるとのことだったので、実際にそれでRDP接続を実施した結果、問題なく接続できました。ただ、キーペアを覚えておく必要がでてくるので、管理上は懸念が生じる仕様です。
OS接続後に下記のメッセージが出力されていました。バックアップを実施する際にシャットダウンは実施されていないのですが、予期せぬシャットダウンがされていたとOS側では受け取っていたようです。
OS上のシステムログでは、バックアップを取得した23:50頃でログが止まっており、次のログは復元後に起動したタイミングでの出力となっています。
■AWS BackupによるEC2バックアップ実施（手動）
スケジュール設定ではなく手動での即時バックアップ手順も実施しました。
バックアップの作成（AWS Backup）
手動での作成手順ですが、基本的には手順通り実施すれば簡単に実施できました。ただし、バックアップは即時で始まるわけではなく、画面上に表示される1時間以内のどこかで始まる仕様のようでした。その為、急ぎでバックアップを取得する必要があるときには、EBSスナップショットも併用したほうがいいのかと思いました。
■■ まとめ ■■
今回はバックアップ・復元のテストを実施しました。操作自体は簡単ですが、スケジューリングしたりタグを付けたりして運用負荷軽減する方法を考えると、もう一段階掘り下げて知識を整理する必要がありそうだと感じました。
次回は「AWS動作検証【4】（サーバ自動停止・自動起動）」です。
以 上