【Laravel & AWS】BackupでEFSやRDSのバックアップとリストアを素振りする【５日目】

by

AWSのサービス縛りでコスト最適で弾力性のあるLaravelアプリケーションのインフラを作ろうという企画の５日目です。
今回は、AWS Backupというサービスを活用して、EFSとRDSのバックアップを取得してリストアする所までやってみたいと思います。
ちなみにやりたい事の一覧は以下の通り（破線は完了した物）

  • アプリケーションサーバの構築 (１日目)
  • ビルド・デプロイの自動化 (１日目)
  • RDBに接続できる (２日目)
  • cronを使える様にする（Laravelのタスクスケジュールのトリガー） (２日目)
  • HTTPS対応 (３日目)
  • storageフォルダにシンボリックリンクを作成する (３日目)
  • storageをEFSに置き換える (３日目)
  • フロントのリソースの自動ビルド(node, npm)に対応 (4日目)
  • アプリケーションサーバのオートスケール (4日目)
  • ストレージ(EFS)のバックアップ／リストア
  • RDSのバックアップ／リストア
  • テストの自動化
  • Redisに接続できる
  • リソースをCDNから配信する
  • RDSの容量のオートスケール
  • ビルド完了時のslack通知
  • System Managerでシステムを可視化してみたい
  • Inspectorで脆弱性チェックを受けてみたい

EFSのバックアップ／リストア

EC2のインスタンスはBeanstalkによって作成&破棄されるのでEBSのバックアップについては触れません。
第３回で/storageフォルダのみEFSに逃したので、EFSのバックアップ／リストアをやってみます。
AWS Backupというサービスを利用してバックアップできるらしい

バックアッププランを作成する

分からない言葉がいくつかあるので意味を調べる🧐

  • バックアップウィンドウ
    • バックアップが開始される時間帯。
    • バックアップに時間が掛かる場合、バックアップウィンドウに割り当てられた時間を超えてバックアップが継続するケースもある。
  • ライフサイクル
    • 作成から経過した日数に応じて、低コストのストレージに移したり削除したりする機能
  • バックアップボールト
    • バックアップボールトはバックアップを整理するためのコンテナ
    • バックアップボールト単位で暗号化キーやアクセスポリシーを付与できる

バックアッププランが作成できた。

リソースを割り当てる

１つのバックアッププランで複数のリソース（EBSやRDS、EFS）のバックアップができるらしい。
ここではEFSのインスタンスを対象にする

任意のタイミングでトリガーできないのか？

「バックアッププラン」と「オンデマンドバックアップ」があり、後者が任意のタイミングでのバックアップらしい
さっそく試してみる

バックアップの履歴を確認する方法は？

「ジョブ」ページで確認できる。
バックアップが取得できている事がわかる🤘

試しにリストアしてみる

EFS上に適当にデータを作成する。
リストアしてtest.txtが消えていればリストアが成功している

「保護されたリソース」からリストアを実行する

リストアの進捗は「ジョブ」の「ジョブを復元」タブで確認できる

リストアが終わったので/storageフォルダを確認してみる👀
新しいフォルダが作成されて、その中にバックアップしたファイルが展開されていた。
今あるファイルがまるっと入れ替わる訳ではないらしい。
なのでtest.txtファイルは消えずに残っている

フォルダの中にリストアされるらしい。

「新しいファイルシステムに復元する」とは？

バックアップをリストアする時のオプションで「新しいファイルシステムに復元する」という選択肢がある
これを試してみる

EFSに新しくインスタンスが作成された。

新しいEFSインスタンスをマウントしてみる。
.ebextensions/storage-efs-mountfilesystem.configのファイルシステムIDを書き換えてプッシュする

option_settings:
  aws:elasticbeanstalk:application:environment:
    FILE_SYSTEM_ID: '[ファイルシステムID]'
    MOUNT_DIRECTORY: '/efs/storage'

EFSのマウントに関してはBeanstalkのインスタンスを再起動しないと反映されないので再起動する

マウントされたEFSインスタンスの内容を見てみる。
あぁ、新規インスタンスを作成した場合もフォルダに入っちゃうんですね・・・。
新規インスタンスの場合は、フォルダに入れずに直接展開してくれた方がマウントを切り替えるだけでリストアできるので復旧の手間が減るのだが・・・🤔

ところで、リストアされたフォルダの中にあるaws-backup-lost+found_...というフォルダは何なのだろう？
調べてみた所、ドキュメントに以下の記述があった。
適切なディレクトリに復元できないファイルと、バックアップ中に変更されたファイルがここに入るという事だろうか・・・？

適切なディレクトリに復元できないデータフラグメントは、aws-backup-lost+found ディレクトリに配置されます。バックアップの実行中にファイルシステムに変更が加えられると、フラグメントがこのディレクトリに移動される場合があります。

https://docs.aws.amazon.com/ja_jp/efs/latest/ug/awsbackup.html#restoring-backup-efs

EFSのバックアップ＆リストアはこんなもんかなー。

RDSのバックアップ／リストア

RDSの場合も前章と同じようにAWS Backupを活用する

RDSのバックアップを取得してみる

RDS特有の設定などは特にないらしい。

バックアップが取得できた。

リストアしてみる

RDSの場合、インスタンスが新規作成されて、そこにリストアされるらしい
実際にやってみる

インスタンスが作成された

リストアが成功しているか確認するためにアプリケーション上から画像を差し替えた（犬→人）
正しくリストアできていれば犬の画像が表示されるはず。

Beanstalkの環境変数を変更する（参照先のDBインスタンスを切り替える）
DB_HOSTを新しいRDSインスタンスのホスト名に変更した

アプリケーションを開いてリストア出来ているか確認する
ちゃんと犬の画像が表示された

以上！

所感

AWS Backupを使えば、バックアップを一括管理できるのが最高にクールですね〜〜！🙆
リストアも簡単なのが嬉しすぎますね！
欲を言えばEFSを新規インスタンスとしてリストアした時にファイルを展開しておいて欲しいぐらいですかね〜
まぁでもEFSを全リストアする事はあまりなさそうだから問題ないのかも。

コメントする