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..._at_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!
Received on 2011-03-26 01:09:43 CET