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 dcchap...@acm.org To: ankush chadha ankushchadha2...@yahoo.com Cc: users@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 ankushchadha2...@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 dcchap...@acm.org Chapman Consulting -- San Jose, CA
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
Re: Need help in restoring the svn repository (server side)
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: ankush chadha ankushchadha2...@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
Re: Need help in restoring the svn repository (server side)
(reordering to remove top-posting) *From:* ankush chadha ankushchadha2...@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 dcchap...@acm.org Chapman Consulting -- San Jose, CA
