Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 30590 invoked from network); 5 Feb 2011 00:27:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Feb 2011 00:27:08 -0000 Received: (qmail 15508 invoked by uid 500); 5 Feb 2011 00:27:07 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 15455 invoked by uid 500); 5 Feb 2011 00:27:07 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 15448 invoked by uid 99); 5 Feb 2011 00:27:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Feb 2011 00:27:07 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dcchapman@acm.org designates 64.142.19.5 as permitted sender) Received: from [64.142.19.5] (HELO b.mail.sonic.net) (64.142.19.5) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Feb 2011 00:26:59 +0000 Received: from [192.168.1.115] (70-36-212-24.dsl.static.sonic.net [70.36.212.24]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p150QaPc002409 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 16:26:37 -0800 Message-ID: <4D4C9934.5010804@acm.org> Date: Fri, 04 Feb 2011 16:26:28 -0800 From: David Chapman Organization: Chapman Consulting User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: ankush chadha CC: users@subversion.apache.org Subject: Re: Need help in restoring the svn repository (server side) References: <852438.71161.qm@web37504.mail.mud.yahoo.com> <503526.78919.qm@web37507.mail.mud.yahoo.com> In-Reply-To: <503526.78919.qm@web37507.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------090703080200090201020705" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------090703080200090201020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (reordering to remove top-posting) > ------------------------------------------------------------------------ > *From:* ankush chadha > *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 --------------090703080200090201020705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (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
--------------090703080200090201020705--