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

Re: Backing up - is db/current written last? (was: Berkeley...)

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-07-02 22:41:14 CEST

On Sun, 2005-07-03 at 02:12 +0700, Soren 'Frank' Munch wrote:
> Daniel Berlin wrote:
> > When I started looking at Subversion for our company, the mandatory
> > requirements were reliability and availability. We have development
> > offices in several countries and require 24-hour access. I waited until
> > FSFS was available and stable and have since begun pilot testing.
> >
> > FSFS with rsync is indeed the way to go. We use rsync to backup our
> > repositories being careful to backup db/current first. The backup cron
> > job is amazingly fast - maybe a few seconds every hour, so we get highly
> > reliable backups with essentially no impact on the server. We copy to a
> > standby server (to be located in a disaster recovery center), so should
> > the main server fail, or we lose network connectivity, we can be up and
> > running again in under an hour.
> Smart, and done with only packages, Subversion and rsync only.
> One thing that struck me is that backing up the db/current first is no
> guarantee?
> A commit initiated just before backup-time must result in a corrupted backup,
> virtually every time:
> db/current is written (by svn doing "commit zero")

db/current is written last by svn.

Also, fsfs is still transactional, so the commits are stored in the
transaction directory until they are moved into place, and *then*
db/current is updated.

Thus, at worst, you will end up with a backup that does not include the
last revision, *not* a corrupt repository.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 2 22:43:54 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.