Roo,
Fsfsverify.pl fixes a hell of a lot of problems -
http://www.szakmeister.net/blog/?page_id=16. I think I've had only 2
corruptions that aren't fixable with it - start with that. You may
(read will) need to run it in -f mode more than once - don't be
discouraged if it doesn't work the first time - just make sure the
reported error message from the last verify run differs from the next -
and if it's a big revision it will take a long time to run.
If it doesn't work then in all likelihood you've lost a few files from
the revision - but not the whole lot. What I would do is, dump
everything up to the broken revision and dump everything after the
broken revision:
svnadmin -r 0:<broken - 1> <repo> > head.dmp
svnadmin -r <broken + 1>:<youngest> --incremental <repo> > tail.dmp
Create a new repo containing everything up to the broken revision:
svnadmin create <cleanrepo>
svnadmin load <cleanrepo> < head.dmp
Checkout the clean repo:
svn co <cleanrepo> <working location>
In another folder extract everything from the broken revision of the
repo you can. You will probably need to do multiple directory level
checkouts; you can generally checkout the directories around the broken
files, but not anything in the directory containing the broken files
that occurs after the files. Get anything else you can out with "svn
cat" - "svnlook changed" will tell you what files you need to get out.
Once you've extracted everything you possibly can then you need to go
and see if anyone has a copy of the broken files you can put in place -
if not you need to create empty stub files. Once you have all that,
drop it into the correct place in the location where you checked out the
clean repo, and check it all in 1 transaction so that the set of files
changed is identical - including of course any deletions. Then load the
final part of the broken repo:
Svnadmin load <cleanrepo> < tail.dmp
And you have recovered everything you can.
The latter manual fix process is incredibly irritating but has saved my
repos more than once. Less so after I realized that fsfsverify needed
to be run more than once.
Chris
-----Original Message-----
From: Roo [mailto:roo.watt@gmail.com]
Sent: 03 October 2007 06:28
To: users@subversion.tigris.org
Subject: Hardware failure, corrupt repo (including backups)
I am posting here in the hope that someone may be able top offer some
advice.
Some details:
* Ubuntu 6.06LTS
* Subversion 1.3.1 (r19032) via apt-get
* Apache 2.0.55 via apt-get
In short we had a hardware failure (faulty equipment shorted out the
mains supply) and this has led to a crash of the filesystem that the
repos were host hosted on.
When restoring the backup (N) we found that two repos would fail a
"svnadmin verify" with different errors:
Repo 1 error: "svnadmin: Invalid diff stream: [new] insn 76
overflows the new data section"
Repo 2 error: "svnadmin: Unexpected end of svndiff input"
A backup from the N-1 backup does verify properly.
I thought a FSFS svn repo does not alter previous revision files and I
guess this points to a potential FSFS corruption that had occurred
prior to the hardware failure as was backed up.
I have a number of questions of the experienced users that are
(hopefully) reading this:
1/ Is there a way to excise a corrupted revision and restore the repo
with a missing rev?
2/ Alternatively, is there a way to simply restore the HEAD revision
of the repo without all previous history?
3/ Is it recommended to run "svnadmin verify" on a live repo via cron,
or on a backedup repo?
Any thoughts, recommendations or otherwise are appreciated.
Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 10:08:59 2007