On 10/20/07, Blair Zajac <blair@orcaware.com> wrote:
> I was messing around with fsfs recovery today and if you remove the latest
> revprops file and current file, then the recovery will set current to that
> revision even though you can't get the revision properties from that file. So
> the repository is broken.
This is obviously bad. ;)
> I could see this happening with a race between the non-'svnadmin hotcopy'
> program backing up the rev file but not the current or revprops file during a
> commit, which seems possible given that fsfs writes the rev, revprops and then
> the current file in that order.
Not all third-party backup solutions are Subversion aware and unless
you perform a cold/offline backup, this is a possible situation. The
good thing is that "The Book" outlines this as a scenario which can be
expected.
> The rev file is more important then the revprops, so presumably we wouldn't want
> to set current to the previous revision and loose the rev, but we should do
> something about missing revprops also, at least flag a large warning and provide
> a way to fill in some default values.
I think any partially backed-up revision should be discarded with a
warning. Something along the lines of "Revision X discarded due to a
partial backup.". We should have no problem checking for this
scenario and acting accordingly. The idea here is that we make it
aware that the backup up to that point is fine but there was a problem
with that revision.
> We could populate a revprops from the previous revprops and increment the
> timestamp by one second and fill in default svn:author and svn:log files and ask
> the admin to get these fields from a post-commit email. But this sounds messy.
I agree that this is messy and I would not expect this if I were a
consumer. Anytime you have to "guess" what to put in place, you are
in a bad situation. There is no reason Subversion should be forced to
"clean up" after a backup problem. Besides, they should be using
incremental backups coupled with full backup anyways. ;)
> I would rather see no fsfs recovery ability in svn then to have people think
> that using a non-svnadmin hotcopy to backup a repository is safe if they can
> just run recover on it.
I think we are placing blame/ownership of this situation on Subversion
and it should not be. I would propose that we check for any revision
that is incompletely backed up, restore the repository to the revision
before that and then alert the user of the situation. Alerting the
user with the problem is a lot better than trying to get Subversion to
guess the missing values, getting them wrong and then having to
document a way to fix them. If the consumer has incremental backups
or commit emails, recreating the faulty revision should be no problem.
What do you think?
Take care,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 16:52:43 2007