はじめに
AWSのバックアップのもろもろについて、触れる機会があったので備忘録として書き残してみます。
参考にしていただけたら幸いです。
AWS Backup について
AWSでバックアップを取るにあたって知っておくと便利なサービスが「AWSBackup」となります。
AWSBackupは完全マネージドバックアップサービスです。
現在サポートされているリソースが以下となります。
- EC2
- Amazon RDS(aurora も最近対応)
- Amazon DynamoDB
- Amazon EFS
- AWS Storage Gateway ボリューム
※本記事では「EC2」と「Amazon AuroraPostgreSQL」についてのみ記載しています。
「バックアッププラン」という、【どのくらいの頻度】で【どういった時間内】に【どのくらいの期間保持】するのかという細かいプランニングを行うと、その設定に応じて自動的にバックアップを取ってくれます。
また、スナップショットの保存先なども勝手に用意してくれ、自分で管理する必要がないのも楽で非常に助かります。
リソースにも自動バックアップを行ってくれる機能はあるので、うまいこと使い分けを行うのがいいのかなと思います。
なお、料金はバックアップの保管料のみかかりますが、使用リージョン毎に異なりますので適宜確認をする必要があります。
(参考)AWS Backup の料金
バックアップデータをマルチリージョンに保管しておくということもできるみたいですが....相当バックアップデータの安全性が上がりそうですね..
バックアッププランについて
バックアッププランとは、その名の通り定期バックアップをプランニングできる機能です。
バックアッププランには3種類あり、それぞれ
| バックアップテンプレート | 自作のプランニング | Json でプランを定義 | |
|---|---|---|---|
| プランニング方法 | デフォルトで用意されたプランから選択 | 自分でマネジメントコンソールからプランを選びカスタマイズ | Json で書いたプランを適用 |
| 頻度設定方法 | 用意されたプランにそって実行 | 12 時間ごと、毎日、毎週、毎月、カスタム cron 式から選択 | Json で記述 |
となっています。
BackupWindowについて【どういった時間内】
AWSにはバックアップウィンドウという、【どういった時間内にバックアップを取るか】ということを決めるものがあります。
例) 午前4時から1時間以内に開始し、2時間以内に完了
などとします。なお、指定時間はUTC時間なのでJTCに直すには+9時間する必要があります。
バックアップを取るリソースによっては、ダウンタイムが生じる可能性があるので、I/Oが少ない時間帯など適切な時間設定が必要となってきます。
また、自動バックアップが存在しているリソースに対してバックアップウィンドウを設定する場合はリソースの自動バックアップのバックアップウィンドウと被らない時間設定が必要となってきます。
カスタムCron式について【どのくらいの頻度】
AWSBackupのカスタムルールを作成する場合、頻度の欄でCron式を選ぶことができます。
Cron式を用いることでより詳細なBackupの頻度を設定することができるので、使ってみることをお勧めします。
初めて使う方でもそれっぽいものを書いておけば、間違っていてもスケジュール作成時にエラーが出て直せますし、仮に間違えたスケジュールを登録してもスケジュールプランからCron式を解釈してわかりやすい形で頻度を書いてくれますので、確認は容易にできます。
こちらの公式記事を参考に作成してみてください。
バックアップ保持期間について【どのくらいの期間保持】
バックアップの保持期間はプラン立ち上げ時の「有効期限切れ」欄で決定します。
なので、仮に1週間としておくと、バックアップ取得から1週間後に自動的に削除されます。
なお、保持期間の最大は100年(36500日)みたいなので、半永久的にバックアップが保持できることがわかります。
バックアップデータの暗号化について
AWSBackupで行われるバックアップの暗号化はリソースによって異なります。
特にEBSなどは注意が必要で、バックアップを暗号化するには、元のリソースのEBSを暗号化します。
デフォルトではEC2立ち上げ時にEBSの暗号化は行わないことになっているので、暗号化の欄にチェックしてください。
その他リソースの暗号化については以下の公式の記事を参考にして下さい。
(参考)AWSでのバックアップの暗号化
EC2のバックアップ
AWSBackupを用いると、EC2インスタンスをEBSごと丸ごとバックアップが取れます。
なお、このバックアップにおいてEC2インスタンスを停止させる必要もありません。
が、EC2を動かしながらバックアップを取るとデータの不整合が起こる可能性があり、注意が必要となります。
リストアする際にはAWSBackupの保護されたリソースから復元したいものを選択し、復元させます。
復元されたEC2は全く同じものが立ち上がるわけではなく、同じ設定の新しいインスタンスとして立ち上がります。
なので、また新たにバックアッププランに対象のリソースとして選択する必要があります。
タグを使えば立ち上がったリソースもバックアッププランに自動的に登録とかできそうですが...どうなんでしょう。
Amazon Aurara PostgreSQLのバックアップ
こちらのバックアップもEC2とほとんど同じです。
各々にあったバックアッププランを作成し、リソースをアタッチする形となります。
なお、Amazon Aurora PostgreSQLの場合は、バックアップ時にレイテンシが生じます。
しかし、マルチAZ構成をしている場合はバックアップはスタンバイから取得するため、レイテンシを生じさせずに実現が可能となります。
Amazon Aurora PostgreSQLの自動バックアップとの使い分けについて
Amazon Aurora PostgreSQLには、自動バックアップ機能というものがついています。
AWSBackupとの使い分けについて気になったので軽く調べてみました。
公式ドキュメントを見ると(Amazon RDSですが)
また、AWS Backup を使用して、Amazon RDS DB インスタンスとAurora DB クラスターのバックアップを管理することもできます。
AWS Backup によって管理されているバックアップは、手動のスナップショット制限の手動スナップショットと見なされます。
AWS Backup で作成されたバックアップの名前は awsbackup:AWS-Backup-job-number で終わります。
AWS Backup については、「AWS バックアップ開発者ガイド」を参照してください。
(参照)：[RDS バックアップの使用][link-4]
[link-4]:https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html
ということなので、リソースから見たら「リソースの自動アップデートを行いつつ、AWSBackup も行われる。ただし AWSBackup の定期バックアップはオンデマンドバックアップと同じ扱い」となるようです。
したがって、自動バックアップを行わずにAWSBackupのスケジューリングに頼っているとポイントインタイムリカバリは使えなさそうです。
ですが、自動バックアップの保持期間は0-35日間なので、長期的にバックアップを保持しておきたい場合は、AWSBackupのスケジューリングは有効であるといえます。
なお、Amazon Aurora PostgreSQLもリストア時には新規インスタンスとして立ち上がるのでエンドポイントあたりは意識しておいたほうがいい気がしました。
まとめ
以上、AWSBackupの概要とEC2,Amazon Aurora PostgreSQLのスケジューリングバックアップ方法をまとめてみました。
複数リソースにあたってバックアップをスケジューリングして管理したい場合には便利な機能だなと感じてます。