[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin obliterate features (was: RE: the obliterate discussion - why dumpfiltering is no validworkaround)

From: Felix Gilcher <felix.gilcher_at_exozet.com>
Date: 2007-07-24 17:26:16 CEST

Am 24.07.2007 16:59 Uhr schrieb "patrick" unter

> Erik Hemdal wrote:
>> It would seem then that following an obliterate operation, one would have
>> to
>> invalidate any existing incremental backups and maybe all your existing
>> backups too. After all, they depend on a state of the repository that no
>> longer exists. If an admin uses a complex backup strategy, he then has to
>> start from scratch with a complete backup and restart the backup scheme.
>> If we didn't do that, then we'd have a situation where, in order to
>> restore,
>> one would have to apply some incremental backups up to the point of the
>> obliterate operation, then repeat the obliterate, and then continue with
>> restoring backups (because the structure of the repository is now
>> different). Thinking about "obliteration tracking" makes merge tracking
>> seem trivial.
> i'm still not sure if i understand you correctly...
> are you talking about FSFS and backups using a "traditional" filebackuptool?
> if yes, i think there are no problems with that. the (rev-)files we change
> are changed and will be backuped in the next incremental/differential
> backup.
> i have no clue about other mechanisms, don't know what the "official
> released backup scripts" are.
> but i can not imagine anything that would not be messed up by dumpfiltering
> but would fail here.

Well, simple case: Currently, a revision file is considered to be immutable
once it has been created. A simple, space efficient backup method is to use
a post-commit hook that writes the new revision file to a WORM media (CD,
DVD or a remote ftp dropbox). Advantages: complete, immediate backup that
cannot be destroyed by an attacker that cracks your svn server. Case closed.
This however leverages the fact that revision files are guaranteed to be
immutable and would break the instant that property changes.

Another use-case that might get broken: To save diskspace you can currently
move away revision files and symlink them. You can move those to a
network-drive (possibly read-only) or even on a dvd/tape/whatever media.

This does not mean that the 'immutable' property must be kept at all costs,
but still this is something to consider.



Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
E-Mail: felix.gilcher@exozet.com
URL: www.exozet.com
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 17:25:26 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.