Hi all. This thread has been quite valuable and I appreciate the replies
that have been very helpful. I am currently working on the following
approach:
1. svnsync on the osx system between two isolated drives so slave can be
promoted to master in event of a disk or os failure. I currently have a
clean os on the second drive that can be used to boot so the first can
be recovered so there should be very little downtime.
2. cron hotcopy to keep a weeks worth of backups so the svn filesystem
can be put back in place at at particular time if corruption has
propagated to the slave.
3. dump from the hotcopy on the second drive and move the archive files
to an external backup if a new repository on a different os needs to be
considered (ie. certain types of failure of the osx machine). My
thinking is to produce a dump of revisions (based on the last revision
of the previous hotcopy to the last revision of the current hotcopy) so
I don't have to dump the whole repository each time. This will produce a
backup of dumps with no overlapping revisions.
I would most likely attempt to restore the osx system but want the
option to move the repository to CentOS which is the second os used and
restore the dump archives in. Many thanks.
Regards,
David
Harvey, Edward wrote:
> There's another advantage to svnsync -
>
> Suppose you do a hotcopy at midnight capturing rev 100, and people do updates/commits during the day after, pushing the repo up to rev 101, and then somehow your repository server dies.
>
> If you restore rev 100 of the repo to a new server, and then the clients with rev 101 try to connect to the restored repository of a lower rev number ... I'm not sure what will happen, but I know it's bad. To be safe, you'd have to blow away everyone's working copy and re-checkout for each person.
>
> Svnsync can help you avoid this problem. If you keep a "live" synchronized backup of the repo, and then you need to make the "slave" into the "master," then your restored master is already up to 101, and peoples' clients are happy to continue where they left off.
>
> Of course, whatever might have blown up your master repository would have a small chance of propagating to the slave repository too. So the best practice would be - Use chronic hotcopy in addition to a slave using svnsync. This gives you the most options available to you, if you should need to restore.
>
>
>
>> -----Original Message-----
>> From: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
>> Sent: Friday, April 04, 2008 1:34 PM
>> To: David Pratt
>> Cc: users_at_subversion.tigris.org
>> Subject: Re: hot-backup vs svnadmin dump
>>
>> David Pratt wrote:
>>> Hi. I am in the process of automating a backup and recovery and would
>>> like to know what is best for complete restoration of the repository.
>>> The machines have different os's so just want to ensure I do not run
>>> into snags.
>>>
>>> My repository is hosted on an mac osx machine. I would prefer to do
>>> cron hot-backups and unarchive my repository without any consequences
>>> to a CentOS machine in event of failure. Will I run into any trouble
>>> with this scenario? Would it be better to do a dump and then load the
>>> dump file to a new repository on the Linux box. I guess I am
>>> questioning whether these method are os agnostic and if not how to
>> work around this.
>>> Many thanks.
>> You could try using svnsync. It is cross-platform, and when included
>> in a cron job, will automatically keep the backup up-to-date with the
>> original, without having to worry about moving files between hosts.
>>
>> http://svnbook.red-
>> bean.com/en/1.4/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnsy
>> nc
>>
>> -Hyrum
>
>
> This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin_at_patni.com and delete this mail.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-05 16:17:49 CEST