38

ホーム サーバーでハード ドライブに障害が発生しました。

ディスクが不足していることに気づいたら、ログインして、複数のプロジェクトを含むリポジトリのコピーを作成しました。

ただし、ディスクに障害が発生していたため、リビジョンの 1 つが破損しています。

$ svnadmin verify master/
[...]
* Verified revision 820.
* Verified revision 821.
* Verified revision 822.
svnadmin: No such revision 823

master/db/revs/およびディレクトリには、実際にはというmaster/db/revprops/ファイルが含まれていない823ため、このリビジョンはありません (壊れています)。master/リポジトリには、リビジョン #947 までの後続のリビジョン (私が本当に保持したい!) があります。

今日、私は最新のオフサイト バックアップ (!) を取得しました。これには、幸いにもこのリビジョンが含まれています。master/不足しているリビジョンはバックアップよりも新しいため、修正して壊れたリポジトリを「修復」したいと考えています。

でコピーしたものと同じバージョンの新しく作成されたリポジトリにダンプ ファイルをロードしたことを確認したmaster/ので、すべて古い「リニア」フォーマット 3.

823バックアップdb/revs/db/revprops/ディレクトリからファイルをコピーするだけで、明らかなことを試しました。

$ cp repos/db/revs/0/823 master/db/revs/
$ cp repos/db/revprops/0/823 master/db/revprops/

このディレクトリーrepos/には、バックアップ・ダンプからロードされたリポジトリーが含まれています。今私は得る:

$ svnadmin verify master/
[...]
* Verified revision 821.
* Verified revision 822.
svnadmin: /build/buildd/subversion-1.6.12dfsg/subversion/libsvn_delta/compose_delta.c:165: search_offset_index: Assertion `offset < ndx->offs[ndx->length]' failed.
Aborted

これはあまり心強いことではありません。他のさまざまなコマンドを試しましsvnadminたが、ベリファイアを満足させるものはありませんでした。

私の次のアイデアは、コピーを取り消して、壊れたリポジトリの「新しい」コピーから始め、823以降のリビジョンをダンプして、バックアップとマージすることでした。しかし、それは可能ではないようです。欠落しているリビジョンの後にリビジョンをダンプすることはできません:

$ svnadmin dump -r 824 master/ >r824.dmp
svnadmin: No such revision 823

世界がリビジョン 824 で始まったふりをして、そこから進むことを期待して、ダンプを「インクリメンタル」にすることは役に立たないことに注意してください。

$ svnadmin dump --incremental -r 824:947 master/ > dump.txt
svnadmin: No such revision 823

これはに出力を書き込みますがdump.txt、信頼できるかどうかはわかりません。リビジョンを正常にダンプしたことは記録されないことに注意してください

更新: 別のアイデアがありました: 新しいリビジョン ファイルを crashing-disk-copy からmaster/バックアップにコピーして、「行方不明のテール」を提供する:

$ for a in $(seq 910 947) ; do cp  master/db/revs/$a repos/db/revs ; cp master/db/revprops/$a repos/db/revprops/ ; echo $a ; done

ただし、これはターゲットリポジトリを破損するだけのようです:

$ svnadmin verify repos/
[...]
* Verified revision 907.
* Verified revision 908.
* Verified revision 909.
svnadmin: Corrupt representation '907 21815 45 30922 158d3e72732f45bf6f02919b22fc899a'
svnadmin: Malformed representation header

今、私はアイデアを使い果たしました。

4

1 に答える 1

38

私はそれを解決しました。

私が気づいたら、解決策は(もちろん)明白でした。

私はこれを持っていました:

  • master/:壊れたリポジトリのコピー。リビジョン0..947が特徴で、リビジョン823のファイルが物理的に欠落しています。
  • repos/:リビジョン0..910をカバーする、バックアップ(ダンプファイル)からロードされたリポジトリ。

master/解決策は、リビジョン911以降からダンプすることでした。これはエラーなしで可能でした。つまり、911..947の範囲のリビジョンは、リビジョン823の状態などに直接依存していなかったということです。

$ svnadmin dump --incremental -r 911:947 master/ > tail.txt
* Dumped revision 911.
* Dumped revision 912.
* Dumped revision 913.
[...]
* Dumped revision 947.

とにかく、バックアップからのリポジトリにダンプを適用するだけです。

$ cat tail.txt | svnadmin load repos/
[lots of commits]

そして今、私は完全な履歴を復元しました、問題はありません:

$ svnadmin verify repos/
* Verified revision 0.
* Verified revision 1.
* Verified revision 2.
[...]
* Verified revision 945.
* Verified revision 946.
* Verified revision 947.

わーい!

于 2011-04-08T20:12:30.237 に答える