I use svnsync, for two reasons:
I backup to a separate server, and then as part of a larger corporate
backup that servers updates are copied to tape, with differential each
night and a full dump each week.
1) A full dump/copy of my repos each night (any method) would take too
long, and I've users in different countries that might change the
database as its used. I can also use svnsync hourly then too, rather
than just nightly.
2) The resulting changed files on the second server would add gigs of
space requirements to my nightly tape dump.
So far svnsync seems to work well.. To recover, I simply have to restore
the physical files and reset the UUID.
Adrian
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2008b_at_ryandesign.com]
Sent: 05 June 2008 08:40
To: Rush Manbert
Cc: users_at_subversion.tigris.org
Subject: Re: best way to backup repositories
On Jun 4, 2008, at 11:49, Rush Manbert wrote:
> On Jun 4, 2008, at 6:37 AM, Ulrich Eckhardt wrote:
>
>> On Wednesday 04 June 2008, Marko Kaening wrote:
>>
>>> I wonder what the best way for a regular backup of svn repos is...
>>>
>>> There is "svnhotcopy.py", but there is also the possibility of
>>> "svnadmin
>>> dump". The first would only work safely if there is no update of
>>> the svn
>>> version, but the latter might be a terrible slowdown of the
>>> backup process
>>> in contrast to simply copying the hotcopied svn repo dir.
>>>
>>> Any hints for me?
>>
>> Use both. The hotcopy script is not much more than a simple
>> filesystem copy,
>> only that it copies things in an order that assures that you don't
>> get an
>> inconsistent repository if you are in the middle of a transaction.
>>
>> Then, from that repository, you create a dumpfile for which you make
>> incremental backups using some backup software.
> <snip>
>
> Why do this step? If I have the hot copy backup, doesn't that
> protect me if my main repository is lost? Making a dumpfile and
> backing it up incrementally seems to lose information that the hot
> copy preserved (the configuration info), and I could always make a
> dumpfile from the hot copy at the time I need to restore from it.
> But I would think I would just replace the original repository with
> the hot copy if I ever needed to do a restore after a disaster. Am
> I missing some subtlety about the backup/restore mechanism?
The hotcopy is fine as a hot spare, to swap in if the main repository
fails. But you must be using the same processor architecture, and at
least as new a version of Subversion and (if applicable) BerkeleyDB.
For permanent archival purposes, a dumpfile is better, because the
dumpfile format is specifically designed to abstract away differences
in processor architecture or software version. So if you make a
dumpfile today, you'll always be able to load it into a new
repository running on any machine with any (?) version of Subversion.
But a hotcopy is more restricted in what platforms and with what
combinations of software version it'll work.
---------------------------------------------------------------------
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-06-05 11:20:08 CEST