On 4/10/07, Andreas Hasenack <email@example.com> wrote:
> We had a filesystem crash and after running fsck, the svn backend (FSFS)
> was corrupted. Some checkouts work, most don't.
> svnadmin recover says everything is fine, but svnadmin verify quickly
> finds errors in very old revisions.
> svnadmin dump also doesn't work, stopping on the first error it
> So far, we are running this script which seems to skip over the bad
> svnadmin dump --incremental -r $r /svn | svnadmin load $(pwd)/repos/
> $r is looped over all revisions
> Right now, I'm not that much worried about the lost data. What worries
> me is that lost data is preventing me from getting to the good data. I
> thought svnadmin recover would do that: nuke the corrupted parts and
> leave me with the good ones, but that is not the case.
> The above procedure (dump & reload) is still running, should take a few
> The error messages are various. Here are some:
> # svnadmin verify /svn
> * Verified revision 14.
> svnadmin: Can't read file '/svn/db/revs/99182': End of file
> - malformed header
> It also seems fsck moved some files from revprops to revs. For example,
> that 99182 one from the error above:
> # cat /svn/db/revs/99182
> K 10
> V 8
> K 8
> V 27
> K 7
> V 12
> Tagging 0.03
> This looks like it should belong to revprops, but I'm not that familiar
> with FSFS internals. Anyway, seems everything was badly corrupted.
> So, basically, is there some magic command that would fix the
> consistency of the repository, leaving me with just the data that can be
> salvaged? Is the dump&reload procedure I'm doing above the best thing
> (besides after having a sane backup, of course)?
Sorry, I have no advice or magic bullet for you, but I did want to point out
that "svnadmin recover" is only for BDB repositories - it has no effect at
all on FSFS repos.
Good luck with your recovery!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Apr 10 22:19:11 2007