AWS Backupを使ってみた

投稿者: | 2020年5月7日

ページコンテンツ

【概要】

awsを利用するにあたり、以前AWSのトラブル(2019年8月23日)により、EC2インスタンス(サーバ)が起動できず破棄するしかないという状況が発生した。
バックアップが非常に重要になる。

 

【要点】

  • スクリプトでバックアップしたり、ライフサイクルを使うより、以下のメリットがある。
    • バックアップ対象のサービスは停止しないので、その辺を考慮しなくてよい。(EC2インスタンスは。他は詳細調べてません。。。)
    • バックアップデータから、完全なもとのインスタンスのコピーができる。(再起動しないで作ったAMIやライフサイクルマネージャーで作ったvolumeは元のインスタンスの復元を保証してない。)
  • 設定内容はいろいろあるけど、要は以下。
    • 「バックアップホールド」と言われるバックアップ保存先を指定
    • バックアップ実行タイミング、より低コストの保存先に移動させるか(長期間保存の場合はコストが安い)、他リージョン(海外とか)にも保存するか、保存期間などを指定
    • バックアップ対象の指定(EC2などのインスタンスやタグで指定)

 

【経緯】

バックアップについては以下のような経緯で仕組みを検討していた。

  1. サイトのドキュメントルート配下を(圧縮して)丸ごとs3にバックアップ。且つDBも同じようにs3にバックアップ。
    (メリット)
    仕組み自体AWSに依存しないところがほとんどなので、AWSのナレッジがあまりなくても構築できる。
  2. AWS CLIで該当インスタンスのAMIを作成し、サーバ自体をバックアップとする。
    (メリット)
    サーバ自体をバックアップできるので、サーバトラブルがあったときに、丸ごと復旧できる。
  3. EC2の「ライフサイクルマネージャー」を使って、EC2インスタンスのvolumeをバックアップする。
    (メリット)
    コンソール上でタイミングやバックアップデータのコンテンツの管理をすべてできるので、使い方がわかれば、この機能だけでバックアップの仕組みが完結でき、シンプルに管理できる。
  4. AWS Backupを利用
    (メリット)
    バックアップ実行時にEC2インスタンスの停止は発生しない。
    AMI作成やライフサイクルマネージャーでは、作成されたバックアップデータから元のインスタンスを完全に復元することが保証されていなかったが、これは保証されるらしい。(これはAWSサポートから確認した話)

 

【AWS Backupを設定してみる】

AWS BackupについてはEC2、RDSなどいろんなバックアップを作成できる。
今回はEC2インスタンスのバックアップを設定する。

  1. AWS Consoleにログインし、右上のメニューの中から「AWS Backup」を選択する。
  2. AWS Backupのダッシュボード(ホーム画面みたいな?)が表示されるので、左の「バックアッププラン」をクリックして、右に表示される「バックアッププランを作成」をクリックする。
  3. 「バックアッププランを作成」という画面になるので、以下の内容を設定する。

    1. 「開始する方法」は「新しいプランを立てる」を選択。(使い慣れたら他を選択してもよいけど、まずは。)
    2. バックアッププラン名を任意に入力。
    3. バックアップルールの設定の「ルール名」を任意に入力。
    4. 「頻度」はバックアップの頻度はバックアップを実行するタイミングを決定。毎日保存にしたかったので「毎日」と設定した。
    5. 「有効期限切れ」を設定すると、作成したバックアップを設定した時間が経過すると削除する。バックアップを永遠に残すとその分コストがかかるので、「どれだけ必要か?」「バックアップにかけられるコストは?」のバランスして決める。今回はバックアップは1ヶ月とした。よって、「作成後の日数」を選択し、30を入力。
    6. 「コールドストレージへの移行」は、保存したバックアップデータを一定期間たったら、安いストレージに移行するかどうか、という選択。バックアップ自体を1ヶ月程度の保存とするなら、移行時のコストがかかるので、そのままが良いかもと判断し「いいえ」とした。
    7. バックアップホールドは、「バックアップ先のディレクトリ」みたいなもの。既存のものから選択するので、作ってない倍は「Default」のみしかない。バックアップ先をバックアップデータごとに分けたい場合は、「新しいバックアップホールドを作成」をクリックする。

      1. 「バックアップホールド名」を任意に入力。
      2. 「KMS暗号化マスターキー」は、デフォルトの「aws/backup」でよいと思う。(バックアップホールドにコンソールからのみアクセスするのであれば。AWS CLIなどでそとからアクセスするのであればちゃんと考えたほうがいいかも。)
      3. バックアップホールド自体にタグをつけたいなら、「キー」と「値」を入力する。
      4. 右下の「バックアップホールドを作成」をクリック
      5. 元の画面に戻ると、バックアップホールドにて、作ったバックアップホールドが選択された状態になる。
    8. 「送信先リージョン」はリージョンを設定し、もし海外にバックアップデータをコピーしておきたいならこれを設定する。複数追加されるらしい。完全を考えるなら、海外リージョンも設定しておいたほうが良い。でもコストがかかる。
    9. バックアッププラン自体にタグをつけたいなら、「キー」と「値」を入力する。
    10. 「プランを作成する」をクリックする。
  4. AWS backupのダッシュボードに戻るが、バックアップルールが追加されている。次にバックアップ対象のリソースを登録する。
    「リソースを割り当てる」をクリックする。
  5. 「リソースを割り当てる」画面になるので、以下の入力を行う。

    1. 「リソース割り当て名」を任意に入力。
    2. IAMロールは「デフォルトのロール」でいいと思う。権限的なものを厳密に管理したいのであればIAMロールを設定すればよいと思う。
    3. (やっとここで)バックアップ対象のリソースを割り当てる。
      • 今回はEC2インスタンスを対象にしたので、割り当て単位は「リソースID」を選択。「タグ」を選択することもできるので、同じタグを設定しているインスタンスを丸ごと割り当てることも可能だと思われる。(やったことないけど)
      • リソースタイプは「EC2」にした。対象がEC2インスタンスなので。
      • インスタンスIDをクリックすると、今存在するインスタンスIDがリストアップされるので、対象のインスタンスを選択する。
    4. 「リソースを割り当てる」をクリックする。
  6. これで設定完了。

 

【動作確認】

後日、AWS Backupの作成したバックアップホールドを開くと、バックアップされたデータがリスト表示されている。
作成された時間はバラバラだが、設定した時間内(03:00 – 04:00 JST)に作られている。
また、AWS supportより聞いたことだが、バックアップデータは差分バックアップなのでコスト軽減も考慮されている。(EC2のライフサイクルマネージャーと同じだが)

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)