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