>>>>> "Phil" == Phil Endecott <spam_from_subversion_users@chezphil.org> writes:
Phil> Paul Koning <pkoning@equallogic.com> wrote:
>> My management is cautious about backups (having been burned by
>> database corruption in the past). So I need to be able to do at
>> least some of my backups simply by turning Subversion off (no
>> writes to the repository internals), then copy the repository
>> data, then turn it back on. We'll also use svnadmin hotcopy, but
>> not exclusively.
Phil> I'm using LVW snapshots. As I see it, very many data files
Phil> from very many applications will be corrupt in a conventional
Phil> backup taken while the applications are running. Finding how
Phil> to safely back up each one (i.e. the equivalent of svn hotcopy
Phil> or psql-dump) would be very time-consuming and error prone.
Phil> LVM snapshots take the approach of solving the problem at the
Phil> filesystem level: you backup a "point-in-time" image of the
Phil> filesystem.
Phil> I asked on this list a few months ago to see if other users had
Phil> any experience with or comments about the approach, but didn't
Phil> get much response. It is working well for me, and I would
Phil> still be interested to hear of others' experiences of this and
Phil> other backup techniques.
I like that approach, and I want to try that at some point also (with
storage array level snapshots in our case, but that's a detail).
As I mentioned in an earlier reply, this "should" work, because the
file system and Subversion should both be designed to recover cleanly
from crashes. A snapshot at the block level is "crash consistent".
So a snapshot should always be a useable backup, otherwise either the
file system or Subversion has a P1 bug.
On the other hand, I wouldn't trust that as my sole means of backup
any more than I will trust hotcopy. I still want the slow but safe
"turn things off, copy the repository, turn it back on" approach.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 6 18:55:03 2006