Re: Need help in restoring the svn repository (server side)

Yes, you are right. The fundamental problem was that a good reliable and
scalable backup solution was missing.

 Incremental svn dump looks promising.

Ankush

________________________________
From: David Chapman <dcchapman_at_acm.org>
To: ankush chadha <ankushchadha2003_at_yahoo.com>
Cc: users_at_subversion.apache.org
Sent: Fri, February 4, 2011 7:26:28 PM
Subject: Re: Need help in restoring the svn repository (server side)

 (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