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..._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 00:31:39 CET