Subversionリポジトリのバックアップを参考にバックアップについて考察。なんかよくわからないけどSVN構築をまかされた僕には、このページはとても助かっています。感謝です。
考えること
テーマとしては
- 信頼性をあげて故障する期間を短くしたい
- 可用性をあげてユーザから見て壊れにくくしたい
- 保守性をあげて運用しやすくしたい
そのために考慮するのは
- バックアップの対象
- バックアップ先
- バックアップの頻度
- バックアップの手段
ちなみにSVNは第15回 オープンソースのバージョン管理ツールに世代交代の波にあるように、
Subversion は，バイナリ差分アルゴリズムを使ってファイルの差分を表現しており，テキストファイルもバイナリ・ファイルも同じ方法で管理される。よって，CVSよりもバイナリ・ファイルの管理が容易におこなえる。
のだ。cvs2svnスクリプトをつかって、CVSリポジトリと変換したSVNのリポジトリを比較したら、CVSよりもSVNのほうが半分以下の容量になった。（たしか5.5MBが1.5MBだった気が）
バックアップの対象
リポジトリルートとなっているフォルダにあるリポジトリすべてが対象になると思う。
コピーを用いない場合、confやhooksディレクトリはバックアップがとれないので注意。必要であれば、こちらもコピーしないとね。
バックアップ先
ここで書いてもなので、ディスクが違っていればどこでもいいんじゃないかな。
バックアップの頻度
リアルタイムに取るか、1日や1週間に1回取るか。
バックアップの手段
SVNでは以下の3つの方法を検討できる。
- ファイルコピー
- svnadmin hotcopy
- svnadmin dump/load
- svnsync
ファイルコピー
いいところ
・簡単
悪いところ
・リポジトリがでかくなるとリアルタイムに取ることができない。
・コピー中にコミットするとリポジトリが壊れた
svnadmin hotcopy
試しているところ。
いいところ
・SVN稼働中に安全にコピーできる
悪いところ
・特になさそう
svnadmin dump/load
いいところ
・最低限のデータエラー検出をしてくれるが、壊れたリポジトリを直す手段がほとんどないのが微妙
・バックアップデータが小さい。1000リビジョンぐらいでサイズは8.33MBのリポジトリが、dumpファイルのサイズは14MB。tar.gzに圧縮すると218KBだった。
わるいところ
・すげー時間がかかる。1万リビジョン1時間ぐらいかかった。loadにも同じぐらい時間がかかるので、障害時復旧に時間がかかってしまう。
・こちらもdump中にコミットしたらリポジトリが壊れた経験がある。
・rootじゃないと実行できない
svnsync
いいところ
・リアルタイムでバックアップ（複製）ができる
・rootでなくても実行できる
わるいことろ
・いまんところないなー
まとめ
リアルタイムの保存であればsvnsync。
複製したリポジトリへの切り替えが簡単なので、SVN1.4以上なら使えそう。
一番良さそうなのはSubversionベストプラクティスにもあるようにhotcopyがよさげ。Googleさんもhotcopy+rsyncらしい。
hot-backup.pyを使えるので導入が楽ちん。
参考：
旅と子育てとアジャイルコーチのブログ「世界」 