svnadmin dump
svnadmin dumpに関して、
あとdump内容にリビジョン欠けが発生することがあるらしいので注意が必要。つか怖いなそれ。
こういう無責任な物の書き方は勘弁して欲しい。
技術情報としては、どうやったら問題が起きる、あるいは、起きたと書いておいて欲しい。まぁ、不確定情報だから仕方もないかもしれませんが、無駄に不安をあおっているように見えますよ。
実際問題として、僕のところでは、4年以上、ずっと、
svnadmin dump SVNROOT --deltas --incremental -r NNN:MMM | gzip > svn-NNN-MMM.dump.gz
のような形で差分バックアップを行っているが、何も問題は起きていない。
一応、プラットフォームを書いておくと、CentOS 5.?(ともかく、yumで最新状態)上の標準で入っているsvnコマンドです。
このダンプは、単にファイルの内容と差分が保存されているので、これ以上、確実で安全な方法はないぐらいです。
現在、僕が管理しているリポジトリは、r19332まで行っていて、さらに、ダンプのサイズは、gzip圧縮後で、約5GB程度だが、リストアも特に問題はない。
バイナリファイルをcommitしやがる奴がいて、結構、ダンプ(というか、リポジトリ)が太ってしまっているので、「 Subversionにaddされた同一ファイルを検出してリポジトリをダイエットする」で紹介したようなプログラムで定期的にダンプを掃除して、本体のリポジトリをリストアしなおすという荒療治までやっているが、特に問題は起きていない。むしろ、同一のファイルがcommitされた部分にリンクが張りまくられるのでいろいろと重宝しているぐらい。
遅いことについては、遅いことが致命傷な人には仕方がないですが、とはいえ、週末のincrementalバックアップならば、ものの10分程度です。
incrementalなバックアップだとリストアが・・・という人は、オフラインで、ダンプをcatして合体させればいいです。これは、どっかのバックアップの本作業には関係ないマシンで行えばいいので、バックアップのプロセス自体を制約するような物ではありません。
それに、cat自体はそんなに恐ろしく時間がかかる物ではありません。gzipとかしなければ・・・。
個人的には、svnadmin dumpは十分におすすめできるバックアップ方法です。
