[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: corrupt repository

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-03-22 02:44:09 CET

Ryan Schmidt wrote:
> On Mar 21, 2006, at 20:24, Christopher L Merrill wrote:
>> We were getting low on disk space so we remapped the /opt hierarch
>> (including
>> /opt/subversion where all our respositories are) and rsynced all
>> the files
>> to the new area. This was done by our sysadmin who is pretty
>> good. He assured
>> us that all timestamps and permissions were preserved and I have no
>> reason to
>> doubt it.
> Is this new area on an NFS mount? If so, BerkeleyDB won't work like
> that.

A "good" sysadmin should have not "remapped": He should have shut down the
Apache and svnservice services, done a complete system backup (perhaps using
the hot-backup.py script designed for creating snapshots), then *DUPLICATED*
the repository to the target location.

Only after the new location had also been successfully backed up should he
have deleted the old one.

>> Can anybody suggest what I should try next? I am pretty darn sure
>> these
>> files did not get corrupted by the move process, but I'm starting
>> to get
>> worried that we've lost our entire repository.
> Do you have up-to-date backups? Dumpfiles?
> Once you get this sorted out, consider moving the repository to FSFS,
> since it cannot suffer from these problems. How to do so is in the
> FAQ.

It's not clear to me yet that FSFS is better than Berkeley DB overall. But
recovering from a corrupted database is an old problem in many venues,
especially when people mistake doing a file-system snapshot for getting an
actual database image.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 22 02:44:49 2006

This is an archived mail posted to the Subversion Users mailing list.