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.
> * Tuesday through Sunday overnights, incremental backups (svnadmin
> dump --incremental, compress the result)
> * After completing the Monday night full backup, purge the previous
> week's incrementals.
> * After completing the Monday night full backup, run svnadmin pack
> * Keep the last 6 full backups on local disk (these will be kept
> written to the corporate backup system, so we can go back further if
> needed).
>
> I'm saving the packing for after the Monday full backup so that in
> case something goes wrong with it, I have the full backup right there
> that I can restore from.
svnadmin does not do full backups. It does *database* backups, but
does not mirror the rest of the configuration.
> Will svnadmin pack have a significant impact on the incremental backup
> I take the following day(s)? I'm guessing not because those are dumps
> and not hotcopies, but want to be sure.
>
> I recognize that this isn't 100% air-tight, in that we're exposed
> during the workday, but based on the size of our repositories & the
> frequency of commits, standing up another server to act as an svnsync
> mirror or adding the complexity of making a backup of each commit when
> it happens is more than I can get away with right now.
>
> Aside from that, is this a sound strategy? Have I overlooked anything?
See above.
Received on 2013-07-25 05:09:11 CEST