Johnathan,
What does this post-commit script look like to do the incremental backup
on commit? It sounds like a great idea. I'd be interested to see it.
Thanks,
Brian
Johnathan Gifford wrote:
> 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 Wed May 2 02:33:27 2007