On Thu, Jul 25, 2013 at 7:27 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jul 24, 2013 at 11:08:28PM -0400, Nico Kadel-Garcia wrote:
>> On Wed, Jul 24, 2013 at 2:59 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
>> > I'm planning my upgrade to SVN 1.8 & to go along with it, setting up a
>> > new backup process. Here's what I'm thinking:
>> >
>> > * Monday overnight, take a full backup (svnadmin hotcopy, then
>> > compress the result for storage)
>>
>> Insufficient. You also need the Apache or svnserve or SSH configs, and
>> the varoius commit scripts from the base repository, along with their
>> ownership and permissions. Tarballs are good, "rsync -avH" is even
>> better for imaging such loactions in a decodable format.
>
> Well, actually, a hotcopy includes hook scripts and config stored
> inside the repository directory. A dump file does not. I suppose
> you're confusing the two?
>
> Andy, if you're upgrading to 1.8, perhaps the new incremental
> hotcopy feature can help you:
> http://subversion.apache.org/docs/release-notes/1.8.html#incremental-hotcopy
I am planning on going to 1.8.x, so this does look very interesting.
It would definitely simplify things.
> You might also want to consider making use of 'svnadmin freeze':
> http://subversion.apache.org/docs/release-notes/1.8.html#svnadmin-freeze
That one won't work for me. I'm not in control of the enterprise
backup software, so I don't even know when the backup will even happen
(I know it'll be within a many-hours-wide window). I asked the
sysadmin who is in charge of that software and he would have to
research whether it's even possible to run a script to freeze &
unfreeze the repository when the system gets to that server. Even if
it is possible, the implementation timeline will be long.
Received on 2013-07-25 16:12:37 CEST