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.
See http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
> 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/fsfsverify.py
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_base/notes/fs-history
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/structure
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
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-24 12:17:54 CET