SVN（Subversion）のリポジトリは、会社の資産そのものです。ソースコードだけでなく、何年も積み上げた変更履歴、監査の証跡——これらは一度失えば、再生できません。
結論から言えば、バックアップは「取っている」だけでは不十分です。「離れた場所に・定期的に・戻せることを確認して」の3点がそろって、初めて備えになります。とくに見落とされがちなのが、最後の「戻せることの確認」です。
この記事では、SVNを10年以上ホスティングサービスとして提供してきた私たちが、バックアップの方法から、災害に備えるBCPの考え方までを整理します。
どんなホスティングを選ぶべきかは、「SVNホスティングの選び方｜大容量・監査対応の8チェック」でも扱っています。
なぜSVNのバックアップが重要か
バージョン管理システムは「過去に戻れる」のが価値ですが、それはリポジトリが無事である限りの話です。
- 失えば再生できない：履歴は人手で復元できません。最新ファイルのコピーがあっても、「いつ・誰が・なぜ変えたか」は戻せません
- 監査証跡を兼ねる：製造業や業務システムでは、履歴そのものが品質保証・監査の証跡です。欠損は対外的な信頼に関わります
- 開発が止まる：リポジトリが使えない間、チーム全体の作業が止まります
だからこそ、バックアップは「あればよい」ではなく、確実に・継続的に・検証込みで回す必要があります。
SVNのバックアップ3つの方法
SVNには、目的に応じた3つのバックアップ手段があります。まずは全体像を表で押さえてください。
| 方法 | 何をするか | 向いている用途 |
|---|---|---|
svnadmin hotcopy |
リポジトリを稼働させたまま、安全に丸ごと複製する | 日々の確実なバックアップの基本 |
svnadmin dump |
リポジトリを移植可能な形式（ダンプ）に書き出す | 世代保管・別環境への移行・長期保存 |
svnsync |
別サーバーにミラー（複製）を維持し続ける | 遠隔地への分散・災害対策（DR） |
それぞれの使いどころを補足します。
- hotcopy は、サービスを止めずに整合性の取れたコピーを作れるのが利点です。まずはこれを、定期実行の軸にします
- dump は、
--incrementalで差分だけを書き出すこともでき、世代管理や別環境への持ち運びに向きます。復元はsvnadmin loadで行います - svnsync は、もう一台のサーバーに読み取り専用の複製を保ち続けます。遠隔地に置けば、本番が被災してもミラーが残る——これが、BCPの中核になります
バックアップ戦略の基本
方法を選んだら、運用ルールを決めます。
- フルと差分を組み合わせる：定期的にフルバックアップを取りつつ、その間は差分で間隔を詰めます
- 世代を保つ：最新だけを上書きするのではなく、複数世代を残します。障害に気づくのが遅れたときでも、壊れる前の状態へ戻れます
- 自動化する：人が手で実行する運用は、いつか忘れます。スケジュール実行にして、属人化を避けます
「戻せること」を確認する
ここが最も大切で、最も飛ばされがちな工程です。バックアップは、復元できて初めてバックアップです。
「毎日取っているから安心」と思っていたファイルが、いざ復元しようとしたら壊れていた、必要なものが含まれていなかった——これは珍しくありません。
- 定期的にリストアのテストを行い、実際に別の場所へ戻せることを確認します
- 「誰が・どの手順で・どれくらいの時間で戻せるか」を文書化しておきます
取れているつもりが一番危ない、と肝に銘じておくべきです。
BCP：離れた場所に備える
障害には、機器の故障だけでなく、火災・地震・水害といった拠点ごと失う事態も含まれます。バックアップが本番と同じ建物にあれば、災害時には同時に失われます。
ここで重要になるのが、2つの考え方です。どちらも、復旧の目標を数値で決めるための指標です。
- RPO（Recovery Point Objective／どこまで戻れるか）：障害時に、どの時点まで復旧できればよいか。バックアップの間隔が、これを決めます
- RTO（Recovery Time Objective／どれだけで戻せるか）：復旧までに許容できる時間。手順の整備とミラーの有無が、これを決めます
そして核心が、地理的に離れた拠点へバックアップを分散することです。svnsync で遠隔地にミラーを保てば、一方の拠点が被災しても、もう一方からデータを取り戻せます。別リージョン（離れた地域のデータセンター）への分散は、BCPで最も効く備えのひとつです。
別リージョン分散を、自前で組むか／任せるか
遠隔地ミラーや世代管理、リストア検証まで自社で組むには、相応の設計と運用工数がかかります。クラウドのSVNホスティングなら、地理的に離れた拠点への分散バックアップを含めて、運用を任せられます。
→ バックアップ・BCP体制のご相談（無料）
よくある落とし穴
最後に、BCPが「ある」のに機能しない典型を挙げます。
- 単一拠点にしかない：本番と同じ場所のバックアップは、災害では共倒れになります
- 検証していない：取っているだけで、戻せるかを試したことがない
- 手作業で属人化している：担当者しか手順を知らず、その人の不在時に復旧できない
- サービスを止めて取っている：hotcopy を使わず、毎回サービスを停止している
いずれも「備えているつもり」で止まっている状態です。仕組みと検証で、実際に機能する備えにする必要があります。
SVN運用を属人化させない方法｜「あの人しか分からない」をなくす引き継ぎとドキュメント
公平に：クラウドでも「丸投げ」にはしない
公平に書きます。クラウドホスティングに移しても、BCPの責任がすべて消えるわけではありません。
利用する側は、そのサービスのRPO・RTO（どこまで・どれだけで戻せるか）を把握しておくべきです。どこまでをサービスが担い、どこからが自社の責任かという責任分界を理解したうえで選ぶことが、本当の備えになります。良いサービスは、この点を明確に説明できます。
裏を返せば、自社運用でも、専任体制と設計があれば堅牢なBCPは組めます。判断は「任せれば安心」ではなく、自社にその体制を維持し続ける余力があるかで行うべきです（自社運用の負担は「SVNサーバー自社運用の課題」で整理しています）。
まとめ
- リポジトリは再生不能の資産。バックアップは「離れた場所に・定期的に・戻せることを確認して」の3点セット
- 方法は hotcopy（基本）・dump（世代/移行）・svnsync（遠隔ミラー） を使い分ける
- 最重要工程はリストア検証。取れているつもりが一番危ない
- 災害に備える核心は別リージョンへの分散。RPO・RTOで「どこまで・どれだけで戻せるか」を決める
- クラウドでも責任分界とRPO/RTOの把握は必要。丸投げにしない
離れた拠点へ、止めずに、確実に。
tracpathはSVN・Gitのクラウドホスティング。地理的に離れた拠点への分散バックアップと安定運用で、障害・災害時にもリポジトリを守ります。国内サーバー・ISMS認証。
→ バックアップ・BCP体制のご相談（無料） ／ → まずは無料で試す
関連記事
- SVNホスティングの選び方｜大容量・監査対応の8チェック
- SVNサーバーの自社運用、限界はどこ？｜クラウド移行を検討すべきサイン
- 古いSVNサーバーのセキュリティリスクと対策｜放置された環境をどう守るか
この記事の著者
株式会社オープングルーヴ ／ tracpath編集部
2004年よりソフトウェア開発の現場を支援。SVN・Gitのクラウドホスティングサービス「tracpath」を提供し、製造業・業務システム開発企業のバージョン管理・移行を多数支援。ISMS（ISO 27001／27017）認証取得。
