Preaching backup during an uncovered recovery scenario may be fun and make you feel smirk, but it is rarely useful for the particular problem. Your advice jumps from generic (image and scan fs) to speculative (data recovery firms). Would it not be better to address the specific problem?
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.
Andreas
> On 4 Jun 2014, at 08:07, Henrik Carlqvist <hc94_at_poolhem.se> wrote:
>
> On Tue, 3 Jun 2014 20:06:09 +0000
> Curtis Stiebler <CStiebler_at_Navegate.com> wrote:
>> we had a power flicker
>
> Power flicker, physical hard disk crashes, fires, shit happens every now
> and then...
>
>> We do not have a backup of the repository structure
>
> I was once told that the 3 most important tasks for a sysadm is:
>
> 1) backup
> 2) backup
> 3) backup
>
> It really does seem as if you need a sysadm who takes his job seriously.
>
>> need of recovering the repository and we are looking for some guidance.
>
> First of all, shut down the machine and remove the disk. Every write that
> happens to the disk from now on might cause you to lose more data that
> otherwise would have been possible to recover.
>
> Next, create an image file of the disk and start working with copies of
> that image. Try tools to fix the file system, if those tools are not
> enough, try data recovery tools, sometimes called forensics tools.
>
> You could also give this as a work to some professional data recovery
> company. That will cost a lot of $$$, but still you can not be sure to
> recover all data.
>
> Or, you could simply face the fact that you have lost your repository in
> lack of backup and in this case a choice of an untrusty file system. Next
> time you might want to choose some kind of journalling file system, but
> even with better file systems you should not neglect the need for backup.
>
> Even with the repository lost you probably have not lost all your source.
> Most likely you can create a new repository and check in the source you
> have checked out in a working copy. The history will be lost, but at least
> you have something resembling the last version of your source.
>
> No matter how you solve this it might be a good idea to consider the
> advices at http://www.taobackup.com/
> Even though those pages are made to sell some software the thoughts are
> really worth considering.
>
>
> regards Henrik
Received on 2014-06-04 18:52:46 CEST