subversionのバックアップはhotcopyのがイイ
自宅サーバーのHDDがクラッシュして、subversionのリポジトリ等を復帰していて感じた事を( ..)φメモメモ。以前「subversionのバックアップ、リストア | jigen studylog」や「subversionのバックアップ(更に軽く) | jigen studylog」等で紹介していたのですが、色々問題があったのが発端。
svn dump の問題
結論を先に言ってしまうと、「svn dump」より「svn hotcopy」のが早いという事実。日毎のcron(cron.daily)とかで回してsubversionのバックアップを取る場合に、リビジョンが大きいとdumpの場合は以下のような問題がある。
- 上記にも書いたけどdumpは「遅い」
- dumpで行う場合、なぜかリビジョン欠け(一部欠損)が出る事がある。リストアの時にヒドイ目に合う
事実私の所でも何回か現象は見たのだけれど、どうしようもないのでリストア時にリビジョン毎にしたりして対応しなきゃいけない。ちなみにここを参考にさせて貰った→「WeekBuildのHACK日記 ディスククラッシュ」。
あと、1.の遅さは特にバイナリの物を入れている時は顕著で、私の環境だとバックアップとるだけで2時間とかかかってしまうので、中々日毎の処理に入れるのは怖い状況。
んで、svn hotcopy だそうな
と、言うわけでHDDクラッシュも二回目なのでちゃんと日毎にsvnバックアップしましょうという事になり、svn dumpを使っての処理はあきらめ、svn hotcopyにてやる事にした。利点は以下。
- copyするだけなのでdumpよりは圧倒的に「早い」
- リストアもそのままのフォルダを利用できるので簡単。(conf等の設定は注意必要だけど)
以前、hotcopyとdumpの違いが分からんとか言っていたけど、ちゃんと調べておけばよかった。hotcopyのが超簡単だよママン；；
ちなみに以下のような感じに使う。この後圧縮とかかけてsftpで転送かけた。これで、、、少しは安心度は増したかな～。
svnadmin hotcopy /path/to/repo /path/to/backup
Tracでmysqlを使う
subversionのバージョン管理機能と、Wikiを組み合わせたTracというプロジェクト管理ソフトを良く使ってます。
pythonで動いていて、バックエンドデータベースははsqliteがデフォルトなんですが、纏めてバックアップを取りたいなと思ったのでmysqlを使いたくなったので( ..)φメモメモ。
mysqlでTracを利用するためには初期化の時点で行う必要があると思う(テーブル作成が必要なため)。なのでinitenvでプロジェクトを新規作り直しをすると良いと思います。
ちなみに、Tracのバックエンドでmysqlを利用するためにはTrac 0.10以上じゃないと駄目みたいです。
このオフィシャルドキュメント「DatabaseBackend」で解説している通りで大丈夫なんですが、一つだけハマった事としてmysqlソケットファイルの場所が無いという事で色々Tracに文句を言われたこと。
TracではPythonのmysqlライブラリのMysqlDBがあるんですが、これをyumとかでインストールしたりするともれなく/var/lib/mysql/mysql.sockとかに設定されるので、リンクとか貼っちゃうと楽だと思います。
ln -s /path/to/mysql.sock /var/lib/mysql/mysql.sock
subversionのバックアップ(更に軽く)
以前「subversionのバックアップ、リストア」というエントリーで、リポジトリ系のエントリを書きましたが、ちょっと気が付いた事があるので、ちょっと追記エントリー。
なにかというと、リポジトリが大きくなってくるとどうしてもバックアップに時間がかかったり、リストアでも一箇所ファイルが壊れていたりするとリストアするのが非常～～～に面倒臭いという事に気が付いた。
んで、ちょっと調べてみた結果、バックアップ時にファイル分割や、ファイルを軽くする事がが出来る事が分かったので( ..)φメモメモ。
svnadmin dump の –deltasオプション
まずは引用。–deltasオプションは差分のみの出力になる。更に–incrementalオプションも付けると良い感じ。
もう一つの有用なオプションは –deltas です。このスイッチは、ファイルの内容と属性についての完全なテキスト表現を出力するかわりに、それぞれのリビジョンの直前のリビジョンとの差分だけを出力するよう svnadmin dump に指示します。これは svnadmin dump が生成するダンプファイルのサイズを (場合によっては劇的に)減らします。
このオプションつけるだけでダンプファイルが60%位に減った。
問題のリビジョンが分かるように分割
更に、–revision x:y というオプションを付けてダンプファイルを分割すると問題が起こったダンプファイルが分かりやすいのとファイル移動とかも楽なので有利。x:y の部分は 「xがスタートリビジョン」「yが終了リビジョン」。
んで、コレも含めて、バックアップリストアをやると以下のような感じ。
svnadmin dump myrepos --revision 0:1000 > dumpfile1 svnadmin dump myrepos --revision 1001:2000 --incremental > dumpfile2 svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3 svnadmin load newrepos <dumpfile1 svnadmin load newrepos <dumpfile2 svnadmin load newrepos <dumpfile3
いんや～。楽になりました。
