夜も眠れなくなるほど恐ろしい画像 -subversion編-

以下には特定の人にとって非常にショッキングな文面が存在します。
サーバ管理などという退廃的な仕事をされている方は気を強く持ってお読みください。
なお、一部文面は現場を再現した物のため正確性を欠いている恐れがあります。

そろそろsubversionのバージョンを1.6系列に更新しようと画策。
業務時間外に、現在進行形のプロジェクトのリポジトリのhotcopyを取り、dumpを試みる。

$ svnadmin dump /backup/repos/hoge > dumpfile
svnadmin:svndiff データの解凍に失敗しました

…、うん、いや、ほら、一回だけなら誤報かもしれないし。
本リポジトリを使って直接試行。

$ svnadmin dump /base/repos/hoge > dumpfile
svnadmin:svndiff データの解凍に失敗しました

試合終了。
頭の中で甲子園のサイレンが悲しく鳴り響く。

調査の結果、ずいぶん昔からリポジトリが破損していたらしい。
同時commitでロックが重なりでもしたのだろうか。
不幸中の幸いか、破損したファイルの殆どがtags以下の以降の更新が無いどん詰まりディレクトリ。
これらについては、最悪破損リビジョンを消去し、破損を取り除いたdump/loadの繰り返しでリポジトリを再構築することが可能。
問題は作業ブランチ側の根本で破損が発生していたことで、更新されていないファイルのため、その後も破損が発覚せず今日に至ってしてしまったらしい。
これらはsubversionの仕様上大本のリビジョンを抜く=ブランチ削除のため、うかつに消せない。
悪いことにそのファイルを触らない状態ならcommitはエラーを起こさず可能で、さらに該当ファイルの消去動作を伴うcopyを行ってもエラーにならないらしい。(同様の作業がリビジョンに存在していた)
しかもその作業ブランチは使用頻度の高いブランチだったりする。

選択A.
現状維持。リポジトリデータベースのバージョンは未来永劫更新しない。
選択B.
作業ブランチを手動で辿れるだけ辿り再構築。地獄の作業。

LIFEカードなみの究極の選択。

教訓:

svnadmin hotcopyでのバックアップは必ずsvnadmin verifyと併用する

hotcopyはリポジトリデータベースの検証を行わない上、リポジトリが破損していてもエラーを起こさず終了する。
これはdumpを使わないバックアップスクリプトなら同じかも。
hotcopyでバックアップを行うならverifyも併用すべし。

残トランザクションの消去は慎重に

コミット失敗でのデータ破損なら、トランザクションから作業を再現できる可能性がある。
普段機械的に削除しがちな残トランザクションだが、消すのはリポジトリにverifyを掛けた後からでも遅くはない。

動いている≠壊れていない

運用で問題が発生していない事が、そのままリポジトリの完全性を示すことにはならない。
常にリポジトリの破損を疑い、検証を欠かさない事。

subversionバックアップにはデータ検証の入るsvnsyncがいいのかなあ…
破損した現システムでsvnsync使うにはリポジトリの再構築が必要ですけどね！