前回の記事で、本サイト（WordPress）のバックアップをAWSのS3に自動保管することができました。
で、１週間経過してS3を確認すると・・・。
ちゃんとバックアップファイルが入っていました。
しかし、そうです。このままだと日が経つごとにバックアップファイルが作成され、容量を食い潰していきますので、バックアップファイルを自動削除するようにライフサイクルを設定します。
ちなみに前々回でS3を作成する際にバージョニングを有効にしましたが、バックアップファイル名に日付をつけているのでバージョニング関係なかったですね！まぁどっちでもいいんですが、名前に日付をつける運用としちゃったので、アップロードから14日経過したファイルは削除するという設定にしたいと思います。
ちなみに14日とした理由は、このサイトは私が土日に見てメンテしているためです。（実は平日はほとんど見ません。）なので、おかしければ大体１週間以内に気づくことができます。ただ余裕を持って２週間としておくということで14日にしました。壊れたことに気づかずにいたらバックアップが削除されちゃって復旧不可になっちゃうからね。そういう意味ではバージョニングのほうが良かったかな・・・。まぁぱっと見でわかりやすいし、今更なんで！
S3のライフサイクル設定
AWSコンソールにログインし、S3サービスを開きます。
そしてバックアップ用のバケットを選択します。そして「管理」から「ライフサイクルルールを作成する」を選択します。
するとライフサイクルルールを作成する画面が出るので、ライフサイクルルール名、1 つ以上のフィルターを使用してこのルールのスコープを制限する にして、フィルタのプレフィックスをwordpress/にする（最後の”/”は付けないとwordpressって名前がついたもの全てに反応しちゃいますので注意）。
そして、肝心のライフサイクルルールのアクションは「オブジェクトの現行バージョンを有効期限切れにする」にチェックします。これは日付をファイル名に入れていることで、全部が現行バージョンとみなされているから。チェックすると「オブジェクトの現行バージョンの有効期限が切れる」という日数を入力するボックスが表示されるので、14（日）と入力します。これで14日経過すると、現行バージョンではなく有効期限切れ（非現行）とマークされるわけです。
もうひとつ忘れてはいけないのは「オブジェクトの非現行バージョンを完全に削除」にもチェックします。するとまた「オブジェクトの非現行バージョンを完全に削除」が表示されるので、「オブジェクトが現行バージョンでなくなってからの日数」に1（日）を設定。これでルールの作成ボタンを押して作成します。
これにて作成完了です。
これでアップロードから14日で有効期限切れになって、非現行バージョンに移行し、1日で完全削除されます。
【おまけ】S3の利用料金について
S3の料金は主に以下の3つで構成されているようです。
- 保存容量（ストレージ）
- リクエスト数（PUT / GETなど）
- データ転送量
この中で、今回の構成において影響が大きいのは 保存容量 です。
東京リージョンでは、おおよそ以下の料金となります。
- 約 $0.025 / GB / 月
今回のバックアップは、WordPressのファイルとDBで1回あたり約300MB程度でした。これを毎日取得し、30日間保存する場合を想定しますと・・
300MB × 30日 = 約9GBこの場合の月額料金は以下の通りです。
約9GB × $0.025 ≒ $0.23/月（約30円程度）と（チャッピーの試算が正しければ）大したことないですね。
また、その他の料金も
- EC2 → S3 のデータ転送は無料
- PUTリクエスト（アップロード）も少量のためほぼ無視できるレベル
そのため、実質的には ストレージ料金のみを意識すればOK の模様です。