Hello all, Thanks for your help. Here are some answers to your questions.
fs-type is fsfs. "Incremental backup" was done using my own script that looked at timestamps of files. It doesn't matter how this works it just means I am missing some of my revision files that were created on the dates in question, these are missing from: repos/db/revs/0/ I used the default settings in SVN and apache. Let me know if you have any more questions. I still don't know if I can apply a reverse diff from the files in the repo/db/revs on the latest checked out repository that I have to recover the missing revisions. Is there a way of making diff files from these backups I have recovered? Thanks. On Mar 26, 7:27 am, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Other points: > > * The terms used are unclear. > > (Example: 'incremental backup' could mean 'zfs/lvm snapshot', could > mean "find -mtime | xargs tar", and could mean 'incremental dump'.) > > I'd rather get a concrete set of facts (read: one that doesn't require > me to guess what the facts are) before suggesting a recovery procedure. > > * There are some more subtleties here. > > One example: under certain conditions (which depend on your > configuration and on your data), if you don't enable the rep-cache > while re-creating revisions, the pieced-together repository may be > corrupted. > > Stefan Sperling wrote on Thu, Mar 24, 2011 at 12:17:19 +0100: > > > > > > > > > On Tue, Mar 22, 2011 at 08:27:39PM -0700, bdu12 wrote: > > > Hello, > > > > I use to have two SVN repositories and a single trac DB setup running > > > in Ubuntu on vmware. The server had a cron daily job that ran each > > > night doing incremental backups onto an email server (the incremental > > > backups, backs up files that have been changed during the day). > > > Occasionally I also did a snapshot of the system for a complete > > > backup. > > > I guess this means that you backed up the repository files as > > they appeared on the filesystem (i.e. repos/db folders etc.). > > > Which repository backend were you using? BDB or FSFS? > > See the file called repos/db/fs-type. > > FSFS has been the default for quite some time so it's likely that you > > have FSFS repositories. > > > Do you have any dump files of repository data (obtainable via svnadmin > > dump)? > > > > My server has now been lost after the Christchurch earthquake in NZ on > > > 22/02/2011 and am trying to rebuild everything from these backups. > > > > I have managed to recover an old snapshot from: > > > - 24/01/2011 > > > > I have also managed to recover all incremental backups except for two: > > > - 28/01/2011 > > > - 29/01/2011 > > > > I managed to take the client laptops out of the office when the quake > > > hit which have different revisions of the DB's from different > > > checkouts done of the different projects. > > > "DB" as in "Subversion repository"? > > > Note that a checkout may not mirror any given revision in the > > repository. It working copy can contain mixed revisions. > > Seehttp://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.b... > > > > Is there a way of rebuilding my server with all of this data? I am > > > not sure what I was working on on the days that I lost the incremental > > > backups. > > > Once a revision file has been created, it is never changed. > > Newer revisions often refer to data from older revisions. > > > In FSFS repository filesystems, Subversion stores revision data as > > separate files in repos/db/revs and repos/db/revprops. > > So incremental backups of FSFS repositories should only be adding new files > > to the repository, with one exception. The file repos/db/current contains > > the number of the HEAD revision, and should change in every incremental > > backup. > > > If the data you already have tells you enough to figure out what the > > missing changes were, you can try restoring revisions in order. > > Use the full backup you have as a starting point. > > Then copy in new revision files from incremental backups, and also copy > > or adjust the 'current' file. > > For the missing revisions, you will need to manually replay the *exact* > > changes made in them (using checkout and commit from a working copy), > > so that future revisions fit on top. > > > If that doesn't get you anywhere, a more low-level approach might work: > > > Try to figure out which files and directories were changed in the missing > > revisions. E.g. try to open every file in every revision (from HEAD > > downwards) > > and note the path/revision pairs for which svn errors out. > > Now locate revisions that changed the same paths. > > Decode the corresponding revision files from before and after the missing > > revisions and try to interpolate the changes that the missing revisions > > were describing. A tool that can decode FSFS revision files is here: > >https://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side... > > This tool parses FSFS revision files and prints their content in > > somewhat human-readable form. To understand the decoded data, refer to > > these documents: > >http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs... > >http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs... > >http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs... > >http://svn.apache.org/repos/asf/subversion/trunk/notes/svndiff > > > A similar approach might work for BDB backends, but off-hand I don't > > know how it would be done. Some of the above links talk about BDB, > > and information within them is also important for understanding FSFS. > > > > I think in theory I should be able to have the current working copy > > > per project and then perform a reverse diff of the revisions from > > > 30/01/2011 to the date just before the checkout of the project in > > > question. This should then give the version at 30/01/2011. Then > > > using this version with the version of 27/01/2011 should be able to > > > recalculate per project what occurred on the lost dates of 28/01/2011 > > > and 29/01/2011. Then these should be able to be used to rebuild all > > > of the repositories as it was before the earthquake. > > > The problem with this approach is that checkouts (and maybe diffs) > > referring to missing revision data simply won't work. > > > Good luck!
