Am 24.07.2007 16:59 Uhr schrieb "patrick" unter
<Patrick.Wyss@mobilesolutions.ch>:
>
>
> 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.
Regards
felix
--
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