ためには、どうしたらいいの？ということで調査中。
正直なところ私はバックエンドに自信がないのだが、せっかくの機会だということで、Amazon EC2にチャレンジしている。そして調べていくうちに、この環境ってすげぇな、と思うようになった。こんな構成よく思いついたね。天才じゃない？
ということで、EC2を使ってホスティングをする予定なのだが、使用しているAMIのインスタンスを落としてしまう（落ちてしまう）と、データは全部ふっ飛んでしまうので、バックアップを取る必要があるのだ。一般のサーバならハードが残っていればなんとか復旧できたりしそうな気もするが、EC2においては、そんなことはできない。というよりも、問題が起きたときには、ハードをゴニョゴニョして復旧をさせるというアプローチはもうやめようぜ、という立場なのだろう。つまり、ちゃんとしたバックアップ構成を組んでシステムを運用するべきだ、と。
そして、そのバックアップのために（それだけのためではないが）、S3というサービスも展開している。でも、どうやってそのバックアップを取ったらいいのだろう、ということがわからなかったので最近はそれを調べていた。
まだ調査中だが、二つの方法があることがわかった。たぶん。
AMIのインスタンスをそのままイメージ化してS3に退避
環境をすべてバックアップする。Amazon Elastic Compute Cloud Getting Started Guide Creating an Imageに書かれているように、構成をすべてバックアップとるので、EC2で運用しているサーバを落としても、AMIの選択で、バックアップしてあるイメージを指定すれば、復旧できる。
s3syncにてディレクトリを指定してS3に退避
必要なディレクトリのみをバックアップする。Using Amazon S3 from Amazon EC2 with Rubyに書かれているように、s3syncというRubyのスクリプトを使って、指定したディレクトリを指定したバケットにバックアップをする。
私が言っているバックアップというのは、サーバに乗っけた自作のWebアプリ自体やそこで使用しているデータベースのことなので、s3syncの方を採用するのだろうな。しかし、リリース時点のサーバの構成のバックアップは取っておくのはいい考えだと思うので、その際には、イメージ化してS3に退避するという方法を採用する必要がありそうだ。
というわけで、使い分ける必要がありそうだ。間違っていたら指摘よろしこ。
