svn recovery - 恢复单个修订
不管我是如何到达这里的,我都可以从备份中恢复 SVN 存储库。不幸的是,备份略有损坏,在 19000 多个修订中,大约有 80 个丢失了。备份是一个 bzip2 文件,我能够使用 bzip2recover 恢复大约 99% 的块。这些是“已知良好”的,因为它们已成功解压。
因此,我能够创建已知良好提交和丢失提交的列表。
原始存储库也已损坏,但许多文件幸存下来。不幸的是,整个存储库已损坏。
因此,我很幸运能够从原始 db/revs 和 db/revprops 目录中获取这些缺失修订的文件。可能性是备份 bz2 文件的损坏与 db/revs 文件的损坏不一致。
我已经重建了 r13892 之前的所有内容,但我知道 r13893 已损坏,因此我没有 r13893 的转储。我确实有原始存储库中的文件 db/revs/13893 和 db/revprops/13893 。
我使用 svn-1.4 创建并重建了存储库,但我升级到 svn-1.6,以便可以使用选择性 svnadmin verify 命令(在单个或一系列提交上)。
我想也许我可以将这两个文件放入新存储库中,更新 db/current [1],然后继续。但是,当我尝试验证时,出现此错误:
$ svnadmin verify new-svn
* Verified revision 1.
...
* Verified revision 13889.
* Verified revision 13890.
* Verified revision 13891.
* Verified revision 13892.
svnadmin: Can't read file 'svn/db/revs/13214': End of file found
所以这显然不起作用。不确定 13214 与这里有什么关系。
我降级回 svn-1.4.6,以防 1.6 发生任何奇怪的情况。不幸的是,我得到了相同的结果 - 修订版 13893 未验证:
...
* Verified revision 13891.
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214':
End of file found
所以这就是我所知道的:
- 我知道修订版 1 到 13892 是 100% 正确的(除非 bz2 块解压错误但通过了校验和)。
- 我不知道原始 SVN 存储库中的 r13893 文件是否正常 - 它们可能已损坏,但损坏量很小,不太可能(但有可能)。
有谁知道我如何填补这个漏洞?请注意,我拥有 100% 自信的 r13894,因此如果我能插入 r13893,我就可以继续进行其余的恢复。
[1] 我用这个脚本更新了 db/current: http://svn.haxx。 se/users/archive-2005-12/att-0630/make-current-fix.py
我在其他一些 SVN 存储库上对此进行了测试(在禁用对 db/current 的写入之后!)以验证它是否正在生成与已有的值相同。确实如此。
Regardless of how I got here, I'm in the position of restoring a SVN repository from backup. Unfortunately the backup was slightly corrupted and out of over 19000 revisions, approximately 80 are lost. The backup was a bzip2 file and I was able to use bzip2recover to recover about 99% of the blocks. These are 'known good' since they decompressed successfully.
Therefore I was able to create a list of known-good commits, and lost commits.
The original repository was also corrupted but many of the files survived. Unfortunately the repository as a whole is broken though.
So I am lucky enough to have the files from the original db/revs and db/revprops directories for these missing revisions. The odds are that the corruption of the backup bz2 file does not align with the corruption of the db/revs files.
I have rebuilt everything up to r13892, but I know that r13893 is corrupt so I don't have a dump for r13893. I do have the files db/revs/13893 and db/revprops/13893 from the original repository.
I created and rebuilt the repository with svn-1.4, but I upgraded to svn-1.6 so that I could use the selective svnadmin verify command (on a single or range of commits).
I thought perhaps I could drop in these two files into the new repository, update db/current [1] and then continue. However when I try to verify I get this error:
$ svnadmin verify new-svn
* Verified revision 1.
...
* Verified revision 13889.
* Verified revision 13890.
* Verified revision 13891.
* Verified revision 13892.
svnadmin: Can't read file 'svn/db/revs/13214': End of file found
So this obviously didn't work. Not sure what 13214 has to do with anything here.
I downgraded back to svn-1.4.6 just in case anything odd was happening with 1.6. Unfortunately I get the same result - revision 13893 is not verifying:
...
* Verified revision 13891.
* Verified revision 13892. svnadmin: Can't read file 'svn/db/revs/13214':
End of file found
So here's what I know:
- I know that revisions 1 to 13892 are 100% correct (unless by some extremely unlikely chance a bz2 block has decompressed incorrectly but passed checksum).
- I do not know if the r13893 files from the original SVN repository are OK - they may be corrupt, but the amount of corruption was so small it's unlikely (but possible).
Does anyone have any ideas how I might be able to fill this hole? Note that I have a 100% confident r13894 in my possession, so if I can get r13893 plugged I can move on with the rest of the restore.
[1] I updated db/current with this script:
http://svn.haxx.se/users/archive-2005-12/att-0630/make-current-fix.py
I tested this on some other SVN repositories (after disabling the write to db/current!) to verify that it was producing the same value as that already there. It does.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
关于这一点:
我怀疑 rev 13893 引用了 rev 13214 中的某些内容(例如文件副本,或跳过版本的东西,或其他东西)。
进行 svn 加载时,新修订版本是否与原始修订版本匹配?我记得遇到过这样的情况:我的转储引用了 rev 0,并且它被加载为 rev 1。如果这里发生类似的情况,则对 rev 13214 的反向引用将减少 1。
您可以尝试使用存储库数据库中的文件以转储格式创建丢失的版本。不幸的是,我不知道有什么工具可以做到这一点。但我建议查看 SvnDumpTool;它能够以许多有用的方式操作 svn 转储。
披露:我过去曾为 svndumptool 做出过贡献
Regarding this:
I suspect that rev 13893 referenced something from rev 13214 (such as a file copy, or skip-rev stuff, or something).
When doing the svn load, did the new revisions match the original revisions? I recall running into a case where my dump referenced a rev 0, and it got loaded as a rev 1. If something like that is happening here, the back-reference to rev 13214 will be off by one.
You might try using the files from the repo db to create the missing rev in dump format. Unfortunately, I don't know of a tool that will do that. But I would recommend looking at SvnDumpTool; it is able to manipulate svn dumps in a lot of useful ways.
Disclosure: I have contributed to svndumptool in the past