(reordering to remove top-posting)
> ------------------------------------------------------------------------
> *From:* ankush chadha <ankushchadha2003_at_yahoo.com>
> *To:* users_at_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_at_acm.org
Chapman Consulting -- San Jose, CA
Received on 2011-02-05 01:27:21 CET