SubversionデータをS3にバックアップする最も費用効果の高い方法は？
SubversionデータベースのオフサイトバックアップリポジトリとしてS3を使用することを検討しています。 SVNデータベースをダンプすると、約10ギガバイトになります。そのデータを繰り返しアップロードするという料金は避けたいと思います。
Subversionへの新しい変更がファイルの末尾を変更し、他のすべては同じままであるような、この大きなファイルの構造。 Amazon S3では変更を加えたファイルに「パッチを適用」することはできないため、Subversionに単純に送信した後、バックアップをインスタンス化するたびに10ギガをアップロードする必要があります。
私が見たオプションは次のとおりです。
オプション1データをメガ単位の量に分割する--volsizeを持つ重複を調べています。これを使用してSubversionダンプを分割し、さらに増分バックアップをメガバイト単位で測定することは可能ですか？
オプション2ホットなSubversionリポジトリをバックアップできますか？提出物を書いている最中の場合、これは悪い考えのように思われます。ただし、深夜から午前4時までの間にレポをオフラインにするオプションがあります。 Berkeley DBの各リビジョンは、ファイルをレコードとして使用します。
BDBの代わりに FSFS形式 を使用するようにリポジトリを変換してみませんか？
そうすれば、各リビジョンは個別のファイルとして保存されるため、増分バックアップは最後のバックアップ以降にコミットされたリビジョンを送信するだけです。
小さなAmazonEC2インスタンスを作成し、rsyncまたは任意のツールを介してElastic Block Store（EBS）ボリュームにバックアップできます。バックアップが完了したら、スナップショットを作成します。スナップショットはS3に保持されます。
これは、いくつかの点でやや複雑なソリューションですが、S3の制限/複雑さのいくつかを補います。
私はこれが本当に答えではないことを知っていますが、SVNプロバイダーを使用してこのことについて心配しないのはなぜですか？
別の解決策は、各ユーザーがすべてのデルタの完全なコピーを持っているgitを使用して、サーバーの障害から回復できるようにすることです（すべてが等しいため）。
最近これをしなければならなかったので、バックアップマネージャーがそのトリックをしたことを付け加えたいと思います。ダンプをbzipで圧縮し、s3で回転させることができます。参考までに this を使用しました。