AWS EC2インスタンスのバックアップとして、AMIを作成する

AWSのバックアップを取ることを考える場合に、まずはデータのバックアップと環境のバックアップを考えると思います。
そして、日々アップデートされる開発段階や特に運用が活発なブログのWebサイトなどは、環境のバックアップが取りたくなると思います。
私の場合は、AWS環境のバックアップとして、VPCやサブネットなどのネットワークやELB、AutoScaling、ジョブ管理については、CloudFormation関係のツールからコンフィグとして、バックアップを取っています。
これを外見のバックアップと考えると中身のバックアップは、プログラムを動かしているEC2インスタンスを考えます。

EC2のバックアップの取り方は、スナップショットを取っておく方法とAMIとして取っておく方法があると思います。
そして、私の場合、どうもスナップショットとして取っておくとバージョン的にわけがわからなくなることが多いので、データを変えたとか、構成するプログラムを追加したとかの環境が変わったタイミングでAMIとしてバックアップ取るのがすっきりすると考えています。
良くやるのは、環境の構成を変更する前と変更した後で、「_before」「_after」をバックアップ名に含めたり、日付を含めたりしてバックアップしています。
そして、システムが動かなくなった場合や、環境として過去に戻りたいときに、AMIを選んでEC2をリカバリします。

今回はEC2を運用しているときに、切りの良いタイミングを見つけて、AMIをバックアップするやり方です。

この方法でバックアップしておけば、EC2がこわれてしまったときなどに、作成したAMIを指定して新しいEC2を１から稼働することができます。

この場合、初めて、EC2ダッシュボードのインスタンス画面から、「インスタンスを起動」をクリックして、AWSで用意されたAMIを選んで、１から生成する場合と同じような手順を踏むので、インスタンスのタイプを変えたり、メモリを増やしたり、CPUコア数を増やしたり、ディスク容量を増やしたり、と環境のグレードを変更することもできます。

また、AMIを作成した時点でEC2がリカバリされるので、AWSとして用意されたAMIから行った初期設定や、その後の運用で変化していったEC2内のデータもAMI作成時点に復旧されます。

それでは、EC2を運用していて、なんらかでバックアップする必要が発生した時点からバックアップしていきます。
（ちなみに、画面イメージのインスタンスは削除してしまったので、現在は存在しませんので、ある程度そのままの画面キャプチャーです）

AWSのバックアップ

AMI作成やスナップショット作成では、EC2インスタンスまたはファイルを更新するサービスを停めておくことが推奨されています。
作成時にファイルシステムが更新されると整合性の取れていない状態になるので、復元時に問題が発生する可能性があるようです。
一応、AWSでは、EC2インスタンスを停止しなくても、AMIやスナップショットは取得することができると謳っており、実際に停止せずに操作を行うと、自動でシャットダウンとリスタートが走って、オペレーション的にはなにもしないでも良いのですが、新しく動かすときには「動作確認はして下さい」とのことなので、インスタンスは停止して行うことにしておいた方がベターかと思います。