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

RE: Question on db backup strategy

From: Henderson, Michael D <michael.d.henderson_at_lmco.com>
Date: 2004-04-14 17:46:58 CEST

>> It's late, and I'm new to this, so I have to ask if revision ==
commit?
>> The usage has been pretty consistent, so I'm supposing so. Does that
>> really hurt performance of the server? Is the size of the backup
>> approximately the same size as the repository? Or, am I completely
>> reading that wrong, and they're just backing up the newly commited
>> transaction?
>
> You are reading it wrong, they are describing a method that you could
> use to create a full backup after every commit. However, they also
stat
> that "only the truly paranoid" would take that approach, and that a
> more sane person would do incremental backups after every backup, and
> complete "hot-backups" over the week end, or something like that.

The book does say that's what the developers do.

        Subversion developers, for example, back up the Subversion
        source code repository after every new revision is created,
        and keep an archive of all the commit and property change
        notification emails.

So, I'll assume that they are paranoid. Which really isn't a bad thing,
given the work they're doing. But, I've got to estimate the sizes to
complete the risk analysis.

Back to my question on the size of the backups. Are the incremental
backups proportional to the size * number of transactions or does the
page size play into it?

Is this question better addressed to the Berkeley forums?

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 14 17:48:42 2004

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.