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

Re: Lack of Subversion repository recovery tools

From: Andreas Hasenack <andreas_at_mandriva.com.br>
Date: 2007-06-29 00:10:00 CEST

On Thu, Jun 28, 2007 at 06:51:30PM -0300, Toby Thain wrote:
> On 28-Jun-07, at 5:02 PM, Andreas Hasenack wrote:
>> On Thu, Jun 28, 2007 at 01:57:16PM -0300, Toby Thain wrote:
>>>> I have used BDB with very large repositories (~50Gb) and it survived
>>>> many
>>>> hardware failures (after running recovery and with proper log files
>>>> archived). Now I'm also using FSFS, and had to spend about a week
>>>> manually recovering from corruptions (caused by hardware failure).
>>> Prevention is better than cure... People really should start looking more
>> Is this the reason why there is no recovery for FSFS?
> It's not clear how much effort to "cure" hardware-caused problems is

That's not what I meant/asked.

> worthwhile, especially when a solution is available at a lower layer. Any
> discussion of this topic has to begin with asking, "where are the errors
> coming from." You mentioned hardware failure. There are two surefire ways
> of dealing with it: 1) ZFS 2) backups. A scavenging tool that is supposed
> to cope with arbitrary corruption (i.e. hardware problem) should be a last
> resort, IMHO? And this scenario is pretty much guaranteed to result in
> -some- loss. Hence, "Prevention is better than cure".

You seem to imply tools like fsck are useless. FSFS does not have tools
to bring it back to a consistent state, which even the worst case
scenario of fsck can do. Even worse, a corruption at revision 1 out of
150.000 will make svnadmin dump fail, even when the subsequent commits
did not depend on that one in particular (i.e., no delta).

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 00:10:23 2007

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.