2020/1/13に、AWS Backupの機能がアップデートされ、AMIの定期バックアップとリストアが可能となりました。
早速、この機能を試してみましたので紹介します。
AMIの定期(スケジュール)バックアップを作成
AWS Backupの画面からプランを作成します。
「新しいプランを立てる」を押します。
バックアップスケジュールなどを入力します。
バックアップボールトは、バックアップを保管するグルーピングに応じて作成します。
こちらも新しいアップデートで、新たにバックアップのリージョン間コピーが可能となっています。
必要があれば、ここでコピー先のリージョンを指定します。
「リソースを割り当てる」で、バックアップするEC2を指定します。
この画面で一気に複数台のEC2を登録でき、登録したEC2を同じスケジュールかつ同じボールトでバックアップします。
以上の手順で、AMIの定期(スケジュール)バックアップを設定できます。
AMIバックアップとリストアを試す
オンデマンドバックアップ (手動バックアップ) もできますので、試してみます。
やり方は、画面上でパラメータを指定するだけです。
バックアップが開始されると、ジョブの画面で進捗と結果を確認できます。
完了すると、ボールト内にバックアップができます。
このバックアップからリストアしてみます。
リストアの画面を開くと、バックアップ元のEC2の基礎情報は既に入力されています。
そのままリストアするも良し、別のサブネットにリストアするも良し、リストア先も自由に制御できます。
IAMロールや、シャットダウン動作も指定できます。
テナンシーやユーザーデータも指定できます。
リストアが開始されると、ジョブの画面で進捗と結果を確認できます。
完了すると、新しいEC2が起動します。
よくある質問
Q1: 今までに比べて何が嬉しいのですか?
大きなポイントは以下です。
-
AMIの取得 (バックアップ目的) を自動実行するために、スクリプト等を自作する必要がない
- リージョン間2重バックアップの作り込みも不要
-
他リソースのバックアップと合わせて一元実行・管理が可能
- タグ管理との組み合わせで実現可能
- 作り込みが一切不要
Q2: IPアドレスを指定してリストアできますか?
AWS Backupの機能ではできません。
ここまでの画面から分かるように、AWS Backupのウィザードを使用すると、リストア時に任意のIPアドレスを指定できません。
現時点では、任意のIPアドレスを指定するには、以下の「インスタンス起動ウィザード」のリンクから、通常のEC2インスタンス作成ウィザードに進み、作業する必要があるようです。
Q3: バックアップを削除すると、連動するAMIも削除されますか?
削除されます。
AWS Backupの機能で取得したバックアップ (AMI) は、AMIの一覧画面にも表示されます。
AWS Backupの画面からバックアップを削除すると、AMIの一覧からも、該当するAMIが削除されました。
Q4: バックアップはオンライン? オフライン?
オンライン (静止点なし) です。
従来no reboot
を指定してAMIを取得する時と同じ動きをしているようです。
バックアップ対象のEC2にSSHで接続した状態で、バックアップジョブを実行してみましたが、一度も接続は途切れませんでした。
Q5: バックアップの設定はコードでできますか?
CloudFormationが使えます。
<参考>
AWS CloudFormation テンプレートを使用して AWS Backup の設定を管理する方法を教えてください。
Q6: 今までバックアップスクリプトでAMIを取得していたが、AWS Backupに簡単に切り替えられますか?
状況によります。
単純にno reboot
でAMIを取得しているだけの運用であれば、簡単に切り替えられるでしょう。
AMIを取得する前に何か前処理 (例: mysqldump 等) や後処理 (例: サービス再開 等) があると、前処理からAWS Backupへの連携を考える必要があり、少なくとも連携の方式が変わるので、簡単に切替とはいかないケースがあります。
Q7: 切替前と同じスケジュールで設定したのに動かない
スケジュールやCron式をJSTで書いていませんか?
バックアップスクリプトからの切替で陥りやすいケースです。
タイムゾーンがJSTではなくUTCなので、バックアップスクリプトと同じスケジュールで書くと、想定した時間に実行されません。
JSTから9時間マイナスする必要があります。
Q8: リストアする時にEBSの容量を増やせますか?
AWS Backupの機能ではできません。
Q2と同様ですね。
Q9: AWS Backupで取得したバックアップからAutoScaling Groupを作れますか?
バックアップと紐付いているAMIを指定すれば可能です。
ただし注意点があり、AWS Backupの機能で保管期間を指定している場合、期間が経てばAMIは消えます。
AMIの一覧画面からは、いつそのAMIが消えるか分かりませんので、注意が必要です。
Q10: オンデマンドバックアップって普通にAMI取るのと何が違うの?
管理で楽できる場合があります。
先の画面で分かるように、EC2の基礎情報が最初から入力されているなど、楽できるところがあります。
また、ボールトをうまく使えば、管理面でもシステム単位等、分かりやすくなります。
ただし、先に書いたように静止点は取れませんので、静止点を取る場合は普通にAMIを取る必要があります。
Q11: AWS Backupでリストアすると、既存のEC2が置き換わるのですか?
置き換わりません。
新たにEC2が構築されます。
Q12: AWS Backupでリストアした後、リストアしたEC2のバックアップが取得されない
既存のバックアッププランに、リストアしたEC2を追加しましたか?
元々プランに設定されていたバックアップ対象とは別のEC2が起動しますので、そのEC2をバックアッププランに加える (リソースの割り当てを増やす) 必要があります。
Q13: 別のAWSアカウントにバックアップをコピーできますか?
バックアップ取得後に、バックアップに紐づくAMIだけを共有可能です。
AWS Backupで取得したバックアップのクロスアカウントかつクロスボールトコピーはできないので、単純にAMIをアカウント間で共有するだけとなります。
従来どおり、AMIのアクセス許可を設定する画面で、アカウントIDを追加して共有します。
Q14: 同じリージョンの別のボールトにバックアップをコピーできますか?
コピーできます。
以下は東京リージョンの画面ですが、コピー先に東京リージョンを選ぶことができます。
ここで別のボールトを指定すれば、2重バックアップとなります。
ただし、同一リージョンにおけるコピーは、誤削除のリスクを潰すくらいの意味しかなさそうです。
災害対策という意味では、別のリージョン (遠隔地) にコピーするほうが良いです。
まとめ
今回のアップデートで、AMIも定期的にバックアップできるようになりました。
EC2をリプレースして迅速にリストアしたい場合などのユースケースにも、AWS Backupが使えます。
これで、オフラインバックアップを取りたい時以外は、完全にバックアップ用スクリプトの開発からおさらばできるでしょう!