On Thu, Jul 25, 2013 at 7:27 AM, Stefan Sperling <s...@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.l...@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.
