bdu12 wrote on Fri, Mar 25, 2011 at 16:31:10 -0700: > 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
Again: please use standard terminology. "Working copies" exist, and "db/revs/ directories in FSFS-backed repositories" exist, but there is no such thing as "db/revs dir in a checked out repository". > recover the missing revisions. Is there a way of making diff files > from these backups I have recovered? > It's not possible to extract a reverse diff from a revision file. (You can extract a binary delta stream, but you can't reconstruct A given only B and a binary delta changing A into B) > 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!
