ぱせらんメモ

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

開発ツール |

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

ただのファイルコピー

普通にファイルシステム上でディレクトリをコピー（あるいはアーカイブ）する方法。非推奨。

誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。

リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。

長所

• 簡単。
• 速い。

短所

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

svnadmin dump/load

svnadminのdumpとloadを使う方法。

誰かがアクセス中でも一貫性が保たれる。

あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。

差分バックアップ(--incremental)は指定リビジョン間のバックアップ。バックアップ処理がインクリメンタルというよりはデータがインクリメンタル。復元が面倒くさい。前回のバックアップの続きを処理してくれるわけではない。

あと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のほうがいいかもしれない。

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

取るだけ取って復元方法がわからないとか……あるあるｗ

参考

• Subversionリポジトリのバックアップ [概略]
• Subversion リポジトリのバックアップ - 玉虫色に染まれ！
• Subversion リポジトリのバックアップ、リストア - snbhsmt_log