Hello folks. I'm not currently a subscriber, and therefore would
appreciate cc's. I will of course respond back to the list.
Here is the gist of my situation. I have a relatively small repo, a little
over 1000 commits, 6G total or so (fair amount of binary data), very few
users (3).
When having a 4th person do a checkout recently, the process (via
tortoisesvn) bombed out with a path to a revs file (db/revs/0/586 or
something) and input/output error.
It became evident very quickly that this was a result of bad sectors, and
maybe 6 total files were corrupt. I had backups for all but 1 of them
(r772). It later became evident that even my backup for one of them (r390)
was corrupt. Copied everything to a new drive, and attempted to start
putting everything back together.
The normal process for trying to salvage these situations is to dump
skipping over the bad revisions such as:
svnadmin dump /svn -r 1:389 > dump_0001_0389
svnadmin dump /svn -r 391:771 --incremental > dump_0391_0771
svnadmin dump /svn -r 773:head --incremental > dump_0773_head
The problem is that the 2nd command fails because 390 is fubar. (The gist
is that I think 390 got truncated somehow because common error messages are
thing like "lacks trailing newline" or "node id missing" - forgive me I'm
not directly at the computer at the moment.) In all my searching and
reading the past few days, I've never really encountered anyone complaining
that this process wouldn't work, I guess that's why I'm getting pretty
confounded.
As further weirdness, if I leave out the --incremental flag, the dump will
actually work (and produce a 64G or so file), and complain about r390 at
the very end. The problem as you might expect with this is that svnadmin
load won't be able to load it because it wants to create everything again
the first time it encounters it, and obviously that's useless (bombs out
immediately that some item already exists).
The original server in question was on ubuntu 12.04 which was running
1.6.17(? definitely some version of 1.6). New disk I made was with 14.04
which runs 1.8 something. The problems seem to happen with both versions
of svnadmin.
Also, please spare me the backup lecture; believe me, I know. I'm just a
programmer trying to clean it up now.
If anyone has seen anything like this before or has any suggestions for
getting around any of this, that would be great. I would love to be at the
point where I could just get some valid dumps and then do what I can to
recreate the missing revs, but I can't even get past the dump stage which
is exceedingly frustrating.
keith
Received on 2015-02-25 19:03:40 CET