この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
これまで EFS としては標準機能でのバックアップというものはなく、EFS-to-EFS のような仕組みが必要でした。ただバックアップを取得したいだけなのに手間やコストが掛かるという点で、「ちょっと使いにくいなぁ・・・」という印象がありましたが、先日リリースされた AWS Backup によって、超簡単に EFS のバックアップ/リストアが出来るようになりましたので紹介いたします。
AWS Backup についてはコチラの記事も参考にどうぞ。
AWS Backup は、まだ東京リージョンで使えませんので、ご注意を。来る日のために予習ということで読んでいただければと思います。
やってみる
検証環境
- オレゴンリージョン(us-west-2)
- EFS
- 汎用パフォーマンスモードで作成しました
- EC2
- Amazon Linux 2(Amazon Linux 2 AMI (HVM), SSD Volume Type - ami-032509850cf9ee54e)
- t3.nano
- amazon-efs-utils で /efs に mount しました
EFS にテストファイルの配置
EFS の作成および、mount は完了している前提からはじめます。EFS のファイルシステムである /efs に以下のようなテストファイルを配置しました。
$ ls -ltr
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile1
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile2AWS Backup
今回は Backup plans を作成せず、on-demand backup で検証したいと思いますので、AWS Backup の管理ページから Protected resources を開き、Create on-demand backupをクリックします。
Create on-demand backup 画面が開きますので、各パラメータを指定します。
- Resource
- Resource type は
EFSを選択 - File system ID は該当の
EFS IDを選択 - Backup window
- 検証のためすぐに取得したかったので
Create backup nowを選択 - Lifecycle
- いずれも
Never（デフォルト） のまま - cold storage を指定される場合、一度、cold storage に移行されたバックアップは最短で
90日の保存期間があります。うっかり cold storage に移行されてしまってから削除しても90日までの残り日数は課金されますので、ご利用は計画的に。
Backup vault は default を使わずに Create new Backup vault をクリックし作成。ひとまず、Backup vault name のみを指定し、その他はデフォルト値のまま Create Backup vault をクリック。
先の画面にもどり、残りのパラメータを指定し、Create on-demand backup をクリックします。
- Backup vault
- 先ほど作成したものを指定
- IAM role
- 検証のため
Default roleのまま
Create backup now で作成していますので、直ちにバックアップが実行されます。
しばらく待ってステータスが Completed になれば EFS のバックアップは完了です。簡単過ぎる！！
リストアしてみる
バックアップが取得できたので、次にリストアを試してみます。/efs はmount 状態のままやってみました。リストアを実行するため、Backup vaults をクリック、さきほど作成した test-vault を開きます。リストア対象のバックアップを選択し、Restore をクリックします。
Restore backup 画面が開きますので、各パラメータを指定し、Restore backup をクリックし実行します。
- Settings
- リストアタイプは
Restore to directory in source file systemを指定し、mount したままの EFS にリストアするように指定 Restore to a new file systemの場合は、新規に EFS が作成されます- Restore role
- 検証のため
Default roleのまま
対象サイズとしては数十 MB の小さなものでしたが、10分ほど待って Completed になりました。EBS のようなスナップショットではなく、何らかのバックアップ用のリソースを準備しているのかもしれませんね。
リストアが完了したので mount したままの /efs を確認します。
$ ls -ltr /efs
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile1
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile2
drwxr-xr-x 3 root root 6144 1月 17 16:18 aws-backup-restore_2019-01-17T16-18-24-972Z
$ ls -ltr /efs/aws-backup-restore_2019-01-17T16-18-24-972Z/
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile1
-rw-r--r-- 1 root root 10485760 1月 17 15:21 testfile2
drw--w---- 2 root root 38912 1月 17 16:18 aws-backup-lost+found_2019-01-17T16-18-09-774Zファイルシステムの中身がごっそり置き換わるのではなく、aws-backup-restore_ というディレクトリが作成されています。その配下にファイルがリストアされる動作であることが確認できました。aws-backup-lost+found_には、リストアが完了しなかったものが含まれるようですので、リストア後は確認しておいたほうが良さそうですね。
なお、Restore to a new file system を指定して、新規 EFS を作成しても、aws-backup-restore_ という形でリストアされる形式は同じでした。
クレジット消費
公式ガイドによれば、AWS Backup を使ったバックアップでは、EFS のバーストクレジットを消費せず、また汎用パフォーマンスモードの制限である 7000ファイル/秒 の制限にもカウントされない、との記載があります。
Using AWS Backup doesn't consume accumulated burst credits, and it doesn't count against the General Purpose mode limit of 7,000 file system operations per second.
Cloudwatch で BurstCreditBalance のメトリクスを確認すると、確かにテストファイル配置時にクレジットを消費して以降、バックアップおよびリストアの時間帯ではバーストクレジットが減ることはありませんでした。
EFS-to-EFS バックアップ方式の場合、行っていることは通常のファイルコピーと同じであるため、クレジット消費を考慮する必要がありましたが、AWS Backup なら心配無用のようです。
さいごに
これまで EFS-to-EFS によるバックアップ方式では、EFS のコストが二重に掛かるし、バーストクレジットは消費するし、ちょっと使いたいだけにしては手間だし、、などなど、利用するにはやや辛みがあったかと思います。今回のフルマネージドな EFS バックアップ機能のリリースによって、たくさんの人が幸せになれそうな予感がしますね！また、EFS にバックアップ機能がないために、EFS の採用を見送った方も、これを機に EFS を再検討してみてはいかがでしょうか！
あとは東京リージョンに来るのを待つだけですｗ
以上！大阪オフィスの丸毛（@marumo1981）でした！
3
