S3でバックアップ(メモ: 途中)
いろいろと身軽になりたいので、まずはバックアップ体制を整えてみることにしました。
バックアップの対象は主に以下の4種類(重要度順)。
バックアップ先はなにも考えずツール類が充実してそうなAmazon S3で。How-toはあちこちにあるので書きませんが、使いはじめはだいたい以下のような感じだったはず(だいぶ昔のことなのでわすれた)。
ここまでやった状態です。あ、前提として、Linux(Debian)のことしか考えていません。ちょっとだけSNS(Simple Notification Service)を使ったファイル欠損通知のことも書きました。
計画
バックアップ手段の選定
機能的には s3cmd (http://s3tools.org/s3cmd) のsyncで必要十分なので、これを使うことにしました。Debian squeeze だとaptで入ります。
バックアップ先の選定
tokyo region に以前つくったbucketがあったのですが、やはりちょっとでも安いほうが良かろうというのと、ディザスタリカバリの観点から、singapore regionに作ることにしました。
ディレクトリ単位で信頼性のあげさげができます。今回は手元にあるもののコピーを作る用途なので、reduced redundancy(少ない冗長性) で、99.99% の信頼度を謳っているオプションにしてお金を節約することにします。
バックアップ対象の選定(回復可能なデータをどうするか)
CDとかはある意味手間と金の問題なので、どれぐらいのコストでバックアップできるか見てから方針を決める予定。
作業
s3cmd の設定と起動
s3cmd --configure でinteractiveに設定できます。ここで、AWS の Security Credential (https://aws-portal.amazon.com/gp/aws/securityCredentials で生成・取得) を設定することで認証できるようになります。なお、gpg でファイルを暗号化する機能がついていますが、s3cmd sync ではmd5を比較する都合上利用できないとのことです。
ちなみに、ちょっとわかりにくいですが、s3cmdで言うところのAccess Key = AWSのアクセスキーID, Secret Key = シークレットアクセスキー です。(AWSの設定が日本語の場合)
httpsは使ったほうが良いでしょうね。また、management consoleから「全世界に公開」状態になってないか確認したほうが良いでしょう。デフォルトでは非公開のはずですが。
写真のbackup
優先度はその2なのですが、まずは簡単にできそう&時間がかかりそうだったので。
単純に s3cmd sync /path/to/Photo s3://your-bucket-name/path/to/backup です(現在実行中)。写真の場合は、あくまで手元のRAIDがバックアップその1なので、1月に一回ぐらいバックアップしておけば十分でしょう。
コンベンションとして、僕の場合はbucket nameに自分で持っているドメイン名を入れているのと、pathの最初はbackup元のhost名にしています。
(TBW)
TODO:
- script内容を整理してここに書く
- cron化
repository のbackup
svn-fast-backup (参考: http://d.hatena.ne.jp/pasela/20090206/svn_backup )を利用予定。
(TBW)
さくらのVPSからコピーしているのですが、どうしたわけかよく停まります。2パラで書いてるのが悪い、という可能性もあるので、後日再挑戦予定。
TODO:
- エラー修正
- script内容を整理してここに書く
- cron化
SNSの設定
reduced redundancy storage (RRS) の場合、ファイルがときどき消えてもごめんね、ということになってます。99.99%の信頼性ということは、ものすごくおおざっぱに言って10000ファイルあったら年に1つ消える、ぐらい*1。そこで、ファイルが消えたらメールを送って知らせてもらうように設定できます。
まず、AWSのSNS(Simple Notification Service)でトピックを生成する必要があります。S3はファイルが消えたらSNSのトピックにメッセージを送ってくれます。で、これを何とか受け取れば良い、と。
SNSの受信者は、HTTP(S)/Amazon SQS/E-Mail の3種類です。HTTP(S)は、Web Service Interfaceを作っておいてそこで受け取る、Amazon SQSはAWSの中に存在するメッセージキューサービスで受け取る、ということですが、これは本格的なWeb Service Infrastructureを作る人のためのものであって、今回は関係ありません。ですのでE-Mail で受信することにします。E-Mailも JSON と 平文 の2種類がありますが、JSONでもらってもあまりうれしくないので平文で受け取ることとします。
で、トピックの作成ですが、ストレージを作成したbucketと同じregionに作成する必要があります。作成したトピックに対して 'create new subscription' でE-Mail を追加し、いつもの通り確認メールが送られてくるのでそれに答えると、subscriptionに追加されます。
そこまでできたら、あとはbucketにトピックを追加するだけです。SNSの画面から arn: ではじまるSNS Topic のIDをコピーして、S3 bucketのプロパティのnotification tabから追加しましょう。チェックボックスをonにするのを忘れずに。
TODO:
- httpでSMSを受けて、再同期をかける仕組みの導入
コスト(暫定)
暫定ですが、書き込みは無料なのでまだ値段と言うほどのものにはなっていません。
syncのためのメッセージ(LISTとか)がかなりコストがかかったようです。といっても40centぐらいですが。
一月あたりの利用料は、24GBぐらいをバックアップしたので2ドル23セント+syncに(おおざっぱに)1ドル使うとして、3ドルちょっとというところでしょうか。また月間の運用が安定したらまとめます。
*1:もうちょっとまじめに計算すると、10000ファイル持ってて1年間で1つもファイルが消えない可能性は37%程度
