Subversionリポジトリのバックアップ [概略]

概要

もしハードディスククラッシュ等で失われてしまったら泣くに泣けません。 そうならないように日頃からバックアップを取るようにしましょう。

• [svn-backup-dumps.py の利用方法] は こっちです。
• [svn-backup-dumps.py カスタム版の利用方法] は こっちです。
• svnsync の説明は、こっちです。

データ損失リスク

• 外的要因(火事、落雷、盗難など)
• ハードディスク故障(つまりハードディスククラッシュ)
• 誤操作(リポジトリのデータを間違って消してしまう)

ハードディスク故障によるデータ破壊から、リポジトリデータを 保護するためには、リポジトリを格納しているハードディスクドライブとは、 物理的に別のハードディスクまたは外部記憶メディア(DVD-R とか) に バックアップデータを保存する必要があります。同じバードディスクの 別のパーティションにコピーしただけではバックアップしたことになりません。 (通常考えるリスクはこれです。)

ハードディスク故障によるデータ破壊からデータを救う方法として RAID がありますが、RAID では 誤操作やフトウェアのバグによるデータ破壊を 防止する効果はありません。

マシン自体が損傷を受けるようなリスク(火事など)からデータを保護するためには 離れた場所にあるマシンかメディアにバックアップを置く必要があります。 同じマシンの別のハードディスクにバックアップするだけではバックアップも 被害を受けてしまいます。盗難にあってもデータを秘匿にしたいという場合は データの暗号化が必要となります。

バックアップ頻度

バックアップを行うときにはバックアップ頻度を考える必要があります。

これはどれだけの期間のデータを失うことが許容できるかに関わっています。 もしバックアップ頻度が 1週間であれば、最大1週間分のデータを失ってしまう というリスクがあります。1日単位であれば、最大1日分になります。

バックアップを行う頻度を高くすれば、それだけデータを失ってしまうリスクを 少なくすることができますが、バックアップデータを保存しておくための ディスク容量が多く必要です。

バックアップの方法

• ファイルコピー
• svnadmin dump/load (svn-backup-dumps.py)
• svnsync
• svnrdump

ファイルコピー

リポジトリデータのファイルをコピーする方法です。

長所

• svnadmin dump/load の方法に比べて高速です。
  

短所

• 可搬性に乏しい

  リポジトリの形式に依存してしまうため場合によっては 単にコピーしただけでは利用できない場合がある点です。

  • Berkley DB ファイルシステムを使う場合 OS, BDB のバージョンに依存して しまうためそのままでは利用できない。

• 単純にファイル単位でコピーするだけなのでデータが壊れていたとしても 何も検出してくれない。

  Berkley DB 形式のリポジトリの場合、リポジトリがわずかに壊れる場合が あります。通常の利用では気づかないけど、何ヶ月もたってから壊れていることに 気づくことがあります。(svnadmin dump & svnadmin load するとそのときに判明する) この方式では単にコピーするだけなので、エラーもそのままコピーします。

参考

• svnadmin hotcopy
• hot-backup.py.in
(configure すると hot-backup.py になる)

svnadmin dump によるダンプ

長所

• Subversion のダンプ形式は上位互換性、下位互換性を持っているので ダンプファイルが壊れていない限り、ほぼどんな場合でも復旧できます。

  (ただしダンプファイルが壊れていると復旧できなくなってしまうので、可能な限りダンプファイルには 冗長性を持たせるようにしましょう。つまりフルダンプ、インクリメンタルダンプ等を組み合わせて 複数のバックアップが存在するようにしましょう。)

• 差分バックアップつまり更新されたものだけをバックアップすることが可能です。

短所

• バックアップ、復旧ともに時間がかかります。ただし差分バックアップを 行うことができるので、バックアップ時間を短縮することは可能です。

注意点

• ダンプファイルには conf ディレクトリ や hooks ディレクトリは含まれないので 手動でバックアップする必要があります。
• ダンプファイルが少しでも壊れていると復旧することができないので バックアップテータには冗長性を持たせましょう。
  つまりフルバックアップや差分バックアップを組み合わせて 複数のバックアップが存在するようにしましょう。

参考

• svnadmin dump
• svnadmin load
• svn-backup-dumps.py の利用方法

svnsync によるバックアップ (ver 1.4 以降)

長所

• バックアップしたいサーバーへのSubversion の読み込みアクセス権が あればバックアップすることができます。
  • サーバーに(SSH やリモートデスクトップで)直接ログインできなくても OK です
  • サーバー管理者でなくてもバックアップできる
• バックアップ元サーバーに問題が発生して使えなくなったときに バックアップ先サーバーを臨時の代替サーバーとしても利用可能です。
• バックアップ先に物理的に離れたサーバーを指定するだけで 容易に別のマシンへのリモートバックアップが可能です。
• バックアップ先はコミット権限があるリポジトリであれば何でもかまいません。 file:/// でもかまいませんし、http プロトコルでもかまいません。
• svnadmin dump + svnadmin load と同様の処理が行われるので 自動的にリポジトリの整合性チェックにもなる。
• 初回バックアップ以外は差分バックアップとなるので、前回バックアップを 取ってから更新されたものだけをバックアップできる。

短所

• バックアップ元のサーバーが、Subversion 1.4 以降である必要があります。
  (ただしバックアップ先は Subversion 1.0 以降であれば OK)

注意点

• conf ディレクトリ や hooks ディレクトリはバックアップしないので 手動でバックアップする必要があります。
• バックアップ先のリポジトリで、リビジョン属性の変更を許可する必要があるので バックアップを取る前に、フックスクリプトを設置する必要があります。

svnrdump dump によるダンプ

長所

• Subversion のダンプ形式は上位互換性、下位互換性を持っているので ダンプファイルが壊れていない限り、ほぼどんな場合でも復旧できます。

  (ただしダンプファイルが壊れていると復旧できなくなってしまうので、可能な限りダンプファイルには 冗長性を持たせるようにしましょう。つまりフルダンプ、インクリメンタルダンプ等を組み合わせて 複数のバックアップが存在するようにしましょう。)

• 差分バックアップつまり更新されたものだけをバックアップすることが可能です。

短所

• バックアップ、復旧ともに時間がかかります。ただし差分バックアップを 行うことができるので、バックアップ時間を短縮することは可能です。

注意点

• ダンプファイルには conf ディレクトリ や hooks ディレクトリは含まれないので 手動でバックアップする必要があります。
• ダンプファイルが少しでも壊れていると復旧することができないので バックアップテータには冗長性を持たせましょう。
  つまりフルバックアップや差分バックアップを組み合わせて 複数のバックアップが存在するようにしましょう。