Subversionリポジトリのバックアップ方法いろいろ

開発ツール

Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。

ただのファイルコピー

普通にファイルシステム上でディレクトリをコピー（あるいはアーカイブ）する方法。非推奨。
誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。
リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。

長所
  • 簡単。
  • 速い。
短所
  • バックアップデータの可搬性に乏しい（アーキテクチャ依存）。
  • リポジトリをロックしないので壊す可能性がある。
  • データエラーが検出できない。

svnadmin dump/load

svnadminのdumpとloadを使う方法。
誰かがアクセス中でも一貫性が保たれる。
あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。
差分バックアップ(--incremental)は指定リビジョン間のバックアップ。バックアップ処理がインクリメンタルというよりはデータがインクリメンタル。復元が面倒くさい。前回のバックアップの続きを処理してくれるわけではない。
あとdump内容にリビジョン欠けが発生することがあるらしいので注意が必要。つか怖いなそれ。


リビジョン欠けについて - 2009年2月9日追記
dumpのリビジョン欠けについてトラックバックやメッセンジャー等でいくつか指摘を頂きました。
指摘はほぼ二点で「長いことdumpで運用しているが問題は起きていない」「不確定な情報で不安を煽るな」ということです。

リビジョン欠けについては確かに自分自身も問題を目の当たりにしたことはなく、調べていて見かけた情報をそのまま書いただけです。なので、本当はリビジョン欠けなんて発生しないのかもしれません。
そもそも問題のある機能をいつまでも放置しているとは考えにくいので、単に運用者のミスだったか、まったく別の要因で壊れたのか、あるいは実際に過去にあったバグなのかもしれないけど今は修正されているという可能性もあります。
ただ、複数の人が書かれていることや問題が明らかでない以上、用心するに越したことはないかと思います。最終的な判断は各自でお願いします。

長所
短所
  • テキスト形式に落とすので時間がかかる（特にフルバックアップ）。
  • ダンプファイルが壊れると復旧が困難。
  • 設定ファイルやフックスクリプトはバックアップされない。
  • 差分バックアップが段階的に複数ある場合、復元に手間がかかる。

svnadmin hotcopy

svnadminのhotcopyサブコマンドを使う方法。
安全にリポジトリのコピーを行う。誰かがアクセス中でも大丈夫。
一貫性を保ったコピーが出来る以外は普通のコピーと変わらない。
リストアに特別な作業も必要ない。バックアップデータはリポジトリそのものなので、そのまま書き戻すだけ。

長所
短所

hot-backup.py(svn-hot-backup)

Subversionに同梱されているバックアップツール。svnadmin hotcopyをラッピングしたスクリプトで、圧縮や世代保存が出来る。
この世代保存は単に古いバックアップを残しておくだけで、差分データになるわけではない。
RedHat系の場合は/usr/share/doc/subversion-x.x.x/tools以下に格納されている。
Debian系の場合はsubversion-toolsという別パッケージをインストールするとsvn-hot-backupコマンドとして使えるようになる。
ソースの場合はtools/backupに入っている。

長所
  • リポジトリアクセス中でも一貫性が保たれる。
  • バックアップを圧縮して保存できる。
  • バックアップを世代保存できる（サイクリック可）。
短所

svn-fast-backup

FSFS形式のリポジトリをrsyncベースの実装で高速にインクリメンタルバックアップするためのスクリプト。BDBには使えない。
svn-hot-backupのrsync --link-dest版（変更がないファイルは前の世代のハードリンクになる）と考えるとよい。ハードリンクを使うので圧縮はできない。
RedHat系の場合は……見あたらなかった。
Debian系はsubversion-toolsパッケージにsvn-fast-backupコマンドとして入っている。
ソースの場合はtoolsではなくcontrib/server-sideに入っている。

長所
  • リポジトリアクセス中でも一貫性が保たれる。
  • バックアップを世代別に保存できる（サイクリック可）。
  • 高速にインクリメンタルバックアップが行える。
  • 世代間はハードリンクによってディスクスペースが節約される。
短所
  • バックアップデータの可搬性に乏しい（アーキテクチャ依存）。
  • FSFS形式のリポジトリにしか対応していない。
  • バックアップデータを圧縮できない。
  • ハードリンクを使ってるのでたぶん世代間は同一のファイルシステム上にしかバックアップできない。

svn-backup-dumps.py(svn-backup-dumps)

svnadmin dumpをラッピングしたスクリプト。圧縮とftpおよびsmbによる転送をサポートしている。
１ダンプファイルあたりのリビジョン数を指定することが出来る。
cronで毎日差分バックアップする場合に便利。対象のダンプファイルが既に存在する場合はスキップされるので、常に最新の差分バックアップを取り続けられる。
裏で走るのはsvnadmin dumpなので、リビジョン欠けの不安は残る。また設定やフック等もバックアップされない。
RedHat系の場合は/usr/share/doc/subversion-x.x.x/tools以下に格納されている。
Debian系の場合はsubversion-toolsパッケージにsvn-backup-dumpsコマンドとして入っている。
ソースの場合はtools/server-sideに入っている。

長所
短所
  • 時間がかかる（特にフルバックアップ）。
  • ダンプファイルが壊れると復旧が困難。
  • 設定ファイルやフックスクリプトはバックアップされない。
  • 差分バックアップが段階的に複数ある場合、復元に手間がかかる。

svnsync

これはバックアップというか、ミラーリング、レプリケーションといったほうが近い。
オリジナルのリポジトリを参照して複製先のリポジトリの同期を取るためのツール。
単方向の同期なので複製先にコミット等をしてはいけない。

長所
  • 最低限のデータエラーが検出できる。
  • サーバがダウンしたときに代替サーバとして利用できる。
短所
  • あくまで同期なので、過去にさかのぼって復元することは出来ない。

まとめ

svnadmin dumpでリビジョン欠けが発生するという話をまれに目にするので不安があるが実際のところはどうなのか気になる。

  • 実は差分バックアップのユーザミス
  • svnadmin dumpの仕様上の限界（内部処理のアトミック性とか、テキスト表現とか）
  • svnadmin dumpのバグ


いずれにしても、週単位でフルバックアップ、日単位で差分バックアップといった組み合わせが定番らしい。
最近はデフォルトでFSFSだろうから、svn-fast-backupとsvn-backup-dumpsを併用するのがよさそう。
ただ、svn-fast-backupで検索してもあまり情報が出てこないのと、これだけcontribに入っていることから若干の不安が残るので、svn-hot-backupのほうがいいかもしれない。


バックアップは取るのも大事だけど復元するのも大事なので、バックアップからちゃんと復元できるかは確認した方がいいと思う。
取るだけ取って復元方法がわからないとか……あるあるｗ

参考