> I'm pretty sure it's BDB (I'm pretty new at this admin stuff but a
> veteran of using svn as a developer)
I'm sure there are more definitive ways to tell, but look in the
README.txt file in the root directory of the repository. On a BDB
repository, this file contains the paragraph:
"The directory "db" contains a Berkeley DB environment,
you may need to tweak the values in "db/DB_CONFIG" to match the
requirements of your site."
On an FSFS repository, there is no such wording.
> I ran svnadmin verify on the server (I control it)
> it said the following:
> svnadmin: Can't open file '/back2/svn/tixrus/trunk/format': No such
file
> or directory
Not a good omen, but as Ryan pointed out, maybe you've passed in the
wrong parameter to svnadmin verify.
> I didn't hack the repository itself only my working copy. In retro,
it
> probably wasn't such a great idea. I suspect it checks dates and
> filestamps to guard against this kind of thing.
An relational integrity of the disconnected dataset. Treat .svn folders
as a black box.
> > You do back up your repositories, correct?
> I hope to shout. I pay a backup fee at my colo, they're responsible
> for massive damages if they can't bring back a previous. If I
restore,
> though, wouldn't all working copies be invalid and out of synch and is
> there an easy way to synch them?
That's good, but it does sound like you're having the disk backed up,
not (necessarily) a consistent copy of the repository. If one or more
transactions are committed to the repository as the disk image is backed
up, what's in the image? (Answer, you don't really know, and if you're
unlucky, you get copy of a repository in an inconsistent state.)
See the svnadmin hotcopy operation (or hotbackup.py) for making a copy
of the repository that is consistent, even while users are committing
changes.
And maybe you're lucky (timing with scheduled backup, small number of
users, phases of the moon) and some of your backed up images are just
fine.
Yes, working copies will be invalid. I'd restore the repository to a new
location to emphasize this. Do NOT synchronize working copies from one
repository to a restored repository using svn switch --relocate. I think
the best strategy would be to set the old working copy aside, create a
new working copy the restored repository, and move changes from one
working copy to the other by hand (use svn status on the old wc to
identify the changes without having to use the repository). You will
also need to account for changes made since the backed up repository was
created.
Ideally, people are not accumulating vast changes in their working
copies, but instead committing small, logical changesets. YMMV. So, in
theory, it should not be a big burden to abandon old working copies --
assuming, as you point out, that the repository is not corrupted.
> I was suspicious of the rep being corrupted because I had a
> hard disk fail last week in a raid set. I am not a hardware person
but
> I thought the whole point of raid was that the system just fails over
to
> the remaining good disk(s) and that you don't even notice except that
it
> emails some contact to let you know a drive failed.
I'm also not a hardware person, but there are several levels of RAID
arrays. We use a dedicated RAID 5 array for our repositories, and it
does have the behavior you expect. See
http://www.webopedia.com/TERM/R/RAID.html for more information, and find
out what you've got.
Yes, I would be very concerned about a hard disk failure on a volume
containing a repository. Even more reason to perform a svnadmin verify,
and then get a hotcopy of the repository on some other storage medium
(e.g., DVD or a local hard disk) asap.
Best luck!
Stuart Celarier | Corillian Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 5 15:48:18 2006