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

Re: FSFS backup

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-10-25 03:22:54 CEST

On Oct 24, 2006, at 18:59, Tim Liu wrote:

> I have read svn book and mailing list about this topic. I'd like to
> summarize them and make sure what I understand meets my
> requirements. thank you for your opinios first.
>
> Requirement
> ==========
> Backup repository perodically and in case of failure, restore
> backup repository as first repository.
> We are using FSFS
>
> A few choices:
>
> 1. svnadmin hotcopy
>
> 2. shut down public access to copy directory manually
>
> 3. incremental backup
>
> 4. hot-backup.py
>
> 5. svnsync
>
> 6. write a new backup script
>
> Look like choice #1 is simple. I just need to write a con job to
> run it periodically. The drawback is if backup happens in the
> middle of commit, backup has obsolete information.

Sure, the backup has obsolete information if a commit happens later.
But it does not have inconsistent or incorrect information in it,
which is the main thing: It is designed to be used on a live
repository (hence "hot" in the name). From the book:

http://svnbook.red-bean.com/en/1.2/svn.ref.svnadmin.c.hotcopy.html

"You can run this command at any time and make a safe copy of the
repository, regardless of whether other processes are using the
repository."

If you want to be absolutely safe, and I recommend this, then you
could do both of the following:

- "svnadmin hotcopy $REPOS new.repos" periodically via cron.
- "svnadmin dump $REPOS --incremental > complete.dump" periodically
via cron.

This way you have backups in two different formats -- one (a hot
backup) which can replace the primary repository on a moment's
notice, and the other (the dump file) which can be loaded into a new
repository, which takes longer, but is useful when upgrading to a new
version of Subversion if that new version offers improvements in
repository storage, like 1.4.0 does. Also, do this:

- "svnadmin dump $REPOS -r $REV --incremental > rev_$REV.dump" in
your post-commit hook so that you have a backup created immediately
after each revision is committed, so that if your repository blows
up, you'll be able to get back each and every revision up to the very
latest one. This is very important because if you do not do this and
you lose the last few revisions because your backup is old, then
everybody will have to throw out their working copies and get new
ones because their old working copies may point to revisions the
server no longer knows anything about, which will cause problems.
This is inconvenient and wastes time, so it's best to implement a
complete backup strategy.

Another good thing you can do in your cron task is "svnadmin verify"
to make sure the repository stays healthy.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 25 03:23:36 2006

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.