Sorry for the late follow-up to this.
The machine our subversion server is running on has a 900GB RAID 5 array
which is backed up incrementally by our IT department every night to
tape. On the weekend they do a full backup. We are using FSFS as the
backend for our SVN server.
Is this not a good plan and we should do a hot back up before the daily
backup?
Thanks
Tom
-----Original Message-----
From: Johnathan Gifford [mailto:jgifford@wernervas.com]
Sent: Friday, April 27, 2007 3:03 PM
To: Dhiraj Soni; users@subversion.tigris.org
Subject: Re: Strategy for backup and recovering svn repository
Dhiraj,
Yes, the plan you propose will work. But, will be a lot more work in
the event of a recovery situation.
Our backup strategy plan is this.
Requisites:
1. A hot back up of the repository created the svn-fast-backup script
every 12 hours. We only keep four days worth of backups as anything
above that is just taking up space for no real reason in our opinion,
but feel free keep them longer. Some folks even do this after every
commit, but that may really be to much over head on your server and
commit process.
2. When a user commits a change to the repository, the post-commit hook
does an incremental dump of the new revision immediately. We keep every
single one of these as a 'last ditch' source, but realistically you only
need the last 12 to 24 hours, but for good measure you should keep the
last four days worth.
3. Everything is kept on RAID 5 storage.
Recovery:
Using the last 'good' hot backup copy, we load each incremental dump
manually to bring the repository backup to up to the point of the known
last revision committed.
Additional Insurance:
A) Run 'svnadmin verify' daily. This will let you know if your
repository has become corrupt much sooner than when you upgrade to the
next version of Subversion. Nothing like the experience of doing a dump
and reload to take advantage of new features to find out that your
repository has a problem.
B) If your not getting and keeping the e-mail diffs for all commits,
you may want to consider that. This is excellent reference to what is
missing from the last hot-backup. In the event your repository becomes
corrupt at a revision that is older than your backups, these may help a
third party support provider like CollabNet or Polarion in fixing your
repository.
C) Archive your hot-backups and incremental dumps and move them to
another server at another location at least once a day.
D) Remember, tape backup will not do you much good on a live
repository. Tape is only good for restoring the configuration of your
system, not the repository. The only guaranteed way to backup your
repository is to use the hot-backup tools.
E) If you are running 1.4.x and have a disaster recovery site and
access to a server at the site, consider mirroring your
repository/repositories to that location using the the 'svnsync' tools.
We've only had to put the above recovery plan into effect once due to
hard configuration snafu. In another situation, the e-mail diffs saved
our butt when we upgraded our Subversion installation and discovered
seven 'bad' revisions. We don't want to go there again, but we're sure
glad we took this approach when they did occur.
Johnathan
>>> On Fri, Apr 27, 2007 at 11:16 AM, in message
<463221ED.7040505@oracle.com>,
Dhiraj Soni <dhiraj.soni@oracle.com> wrote:
> Hi,
> I'm trying to setup a backup/reco strategy for our svn repositories.
My
> question is if i take a full dump via 'svnadmin hotcopy' command then
> taking incrementail daily via 'svnadmin dump', can i apply the daily
> incremental dumps to the full dump taken by hotcopy command??
> Thanks,
> Dhiraj.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 21 01:51:16 2007