subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chapman <dcchap...@acm.org>
Subject Re: Need help in restoring the svn repository (server side)
Date Sat, 05 Feb 2011 00:26:28 GMT
(reordering to remove top-posting)

> ------------------------------------------------------------------------
> *From:* ankush chadha <ankushchadha2003@yahoo.com>
> *To:* users@subversion.apache.org
> *Sent:* Fri, February 4, 2011 1:47:34 PM
> *Subject:* Need help in restoring the svn repository (server side)
>
> Hi All
>
> I am trying to recover the repository from a corrupted hard drive. I 
> have very huge source repository, about 136000 revisions. Luckily I 
> have a 4 month old backup.
>
> I think I was able to recover the contents of db/revs and db/revprops 
> folder as it contains 136000 + 1 files each. ( 1 file per revision and 
> a 0 revision file)
>
> There is a node-origins folder that has a bunch of files. I am not 
> sure if I was able to fully recover files under this folder.
>
> After restoring the files, when I booted up the svn server, its 
> reading till 133000 revisions. Its not recogizing the revisions after 
> 133000.
>
> Does anyone know how to sync that up?
>
> Thanks
> AC

On 2/4/2011 11:56 AM, ankush chadha wrote:
>
> Found that there is a file named 'current' that stores the HEAD 
> revision. When I kicked off svn verify on 133001 it complained that 
> "revisions must not be greater than the youngest revision" so I knew 
> they stored the HEAD revision somewhere. Once I updated the value of 
> HEAD, I can see all the revisions :)
>
> Running a svn verifier on the entire repository to make sure that 
> nothing else is corrupted.
>
>
> Ankush
>
>

 From this I hope you (and everyone else reading this list) learned that 
you need to be backing up your repository much more often.  Success 
should not be based on luck.

You need to think about how much work you're willing to lose, 
worst-case, should your server hardware crash or otherwise go offline.  
Then back up more often than that.  If you're not willing to lose as 
much as a day's worth of work then you need to backup multiple times per 
day, and those backups need to be copied off the server.

Every night I copy my repositories using hot-backup.py, then dump the 
repositories and copy the dump files off the server.  Once a week copies 
of the dump files go off-site (along with full backups of all my other 
data).  I never have all copies of my data in the same place at the same 
time.  The worst-case scenario is having the building catch fire as I'm 
doing weekly backups, taking all of the computers with it and forcing me 
to redo a week's work.  But I can live with that; I work solo and do a 
couple dozen commits a week.  With 136,000 revisions in your repository, 
you should backup your repository to a second machine multiple times per 
day (or use svnsync) and store at least an incremental backup of the 
repository off-site once per day.

Think about it - you very nearly lost four months of history.  Maybe 
your team could have reconstructed much of the changed data using giant 
commits from their surviving sandboxes, but that takes a lot of time and 
effort, is risky, and wouldn't allow you to see why the changes were 
made or distinguish between changes (e.g. was this line of code 
implementing a feature or fixing a bug?).

-- 
     David Chapman         dcchapman@acm.org
     Chapman Consulting -- San Jose, CA


Mime
View raw message