[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Backup strategy sanity check

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Thu, 25 Jul 2013 07:02:54 -0400

On 7/24/2013 4:21 PM, Les Mikesell wrote:
> Is that better than using svnsync from a remote server plus some
> normal file backup approach for the conf/hooks directories?

Not sure, I have not tried out svnsync. We also don't use post-commit
hooks (yet). I am under the impression that hotcopy does grab
conf/hooks stuff while dump does not. But can't find anything in the
svnbook that says either way at the moment.



svnsync definitely does not handle some things:

> The primary disadvantage of this method is that only the versioned
> repository data gets synchronizedórepository configuration files,
> user-specified repository path locks, and other items that might live
> in the physical repository directory but not inside the repository's
> virtual versioned filesystem are not handled by svnsync.


We also run a svnadmin verify on the rdiff-backup directories each week,
combined with verifying the checksums on the rdiff-backup files. The
combination of checksums on the rdiff-backups plus 26W of snapshots that
I can restore to is, I feel, pretty safe.

I try to reexamine the backup strategy every 6 months, but I think I'm
in a good spot now with the svnadmin hotcopy / rdiff-backup setup.
Which also makes it easy for us to rsync the rdiff-backup folder to an
offsite server.

Downside is the delay introduced by doing hotcopy only once per day. So
worst case might mean the lost of 20-48 hours of commits. A more
frequent svnsync / incremental hotcopy triggered by a post-commit hook
would have a much smaller delay.
Received on 2013-07-25 13:03:33 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.