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

Re: Repository Recovery

From: Henrik Carlqvist <hc528_at_poolhem.se>
Date: Wed, 4 Jun 2014 21:00:33 +0200

On Wed, 4 Jun 2014 17:51:49 +0100
Andreas Stieger <andreas.stieger_at_gmx.de> wrote:

> Preaching backup during an uncovered recovery scenario may be fun and
> make you feel smirk, but it is rarely useful for the particular problem.

As backups are only useful when taken before the disaster a backup will
not help in this case. However, if done right, a backup might be useful
the next time. There will be a next time. Sooner or later, for some reason
there will be a next time.

> Your advice jumps from generic (image and scan fs) to speculative (data
> recovery firms). Would it not be better to address the specific problem?

The most important part in my advice for this case is to stop any
operation that might be writing to the disk with a corrupted file system.
In the unix world, the file system should be unmounted or at least mounted
read-only. As this seems like Windows to me with backslashes in the path I
have no better advice than shutting down the machine and remove the disk.

> db/current contains exactly the following:
> 1. Highest revision in plain text
> 2. LF (0x0a, Unix file ending format)
> Find the highest revision in db/revs/N (depending on sharding).
> If that is the only file affected it may very well resolve the issue
> immediately. Verify using svnadmin verify. Failing that, you could
> dismiss the last revision by the same means, or re-create it if you have
> the committing wc or a diff. It may also be dangling as a transaction.

Those commands might be useful, or they might become the commands which
overwrite the part of disk that contains some important data but is marked
as unused by the broken file system. Before applying these or any other
data rescue attempts, be sure to work only on disposable copies of the
crashed file system!

But IMHO this is not a subversion problem. This is a filesystem problem.
First the file system should be fixed. Then any lost data should be
recovered. Once we start recovering data it might become a subversion
problem considering the structure and contents of the repository.

regards Henrik
Received on 2014-06-04 21:01:16 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.