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

Re: Re: DB corruption of first day of subversion

From: Jani Averbach <jaa_at_jaa.iki.fi>
Date: 2004-11-11 19:37:59 CET

On 2004-11-11 12:30-0500, Ritesh Nadhani wrote:
> First of all I will change my memory sticks with a new one.
> Secondly, move to FSFS and work with it. Take backups weekly and hop
> nothing catastrophic happens :)

I think you should really find the reason behind your problems, SVN
should work just fine on your system. If and when it doesn't, just
blindly switching to FSFS isn't a real solution.

Secondly, I strongly suggest that you do a viable, robust backup plan.
Frankly, your once a week doesn't sound like an one. Can you afford
to lose a week worth of work?

Read the book,

and make your plan as against a case that you will lose your
repository at the worst possible moment. Make real life test that
your plan will protect you against that and you can survive from that

Couple of ideas:

1) make incremental backup of every commit
2) make full dump of repository regularly
3) copy your backups off-site or at least to the another disk/machine
4) create hot-backups of repository
5) declare how much down time you can afford, 1 minute, 1 hour, 1 day?
   If your repository is big enough you might don't have enough time
   to recover from full/incremental dump. If that is the case,
   consider live mirroring of your data, to the switchable server or
   to other HA-system.

In many cases, your data is your most valuable assets you have, please
treat it as such.

BR, Jani

Jani Averbach
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 11 19:38:24 2004

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.