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

Re: Hot vs. Live Backups

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2005-09-20 15:49:11 CEST

>>>>> "Dimitri" == Dimitri Papadopoulos-Orfanos <papadopo@shfj.cea.fr> writes:

 Dimitri> Hi,
>> I'm trying to understand the need for hot copies before backing up
>> data. I believe I've read through the relevant documentation, but
>> as I understand it transaction commits are atomic, so it's
>> impossible to back up half a revision.

 Dimitri> The atomicity of a transaction is achieved through lock
 Dimitri> files and such. As a result the transaction seems atomic to
 Dimitri> users of Subversion, but that doesn't mean the files in the
 Dimitri> Subversion repository are always in a consistent state. For
 Dimitri> example what happens if the database is backed up while a
 Dimitri> file is locked and being written?

 Dimitri> A Subversion transaction is not atomic as far as the OS is
 Dimitri> concerned. Only the Subversion user sees the transaction as
 Dimitri> an atomic operation through the use of an additional layer
 Dimitri> over the OS (Berkeley DB).

That makes sense, but there's an additional angle.

For things to be recoverable, the syscalls have to be done in the
right order, so that a crash at any time leaves the on-disk data in a
state where things can be recovered. It's easy to see how that can be
true for bdb; it's not so obvious with fsfs given that you're
depending on file system ordering and caching then.

In any case, that's how it needs to work. If it does, then a backup
system that uses snapshots (common on storage area networks) would
work, because such a system has "crash consistent semantics".


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 20 15:52:48 2005

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.