SVN Recovery from raw db files

[Tim Tornid]

Hello,

I had a catastrophic Subversion server loss, and I'm having some troubles recovering. The server was using VisualSVN 3.2.3 which is Apache Subversion 1.8.13.

I have a full exact duplicate of the repositories directory, but it's giving me 'invalid name for 'fsfs' when I copy them back in. I realize the automation going on should have been utilizing dumps or svnadmin hotcopy.

I have tried copying the /rev and /revops folders into a new repository but I'm getting an error: "Can't get the author of r1: Serialized hash malformed". I've tried fsfsverify, svnadmin recover, and even the Oracle Berkeley db_recover tool.

After I added the rev/ and revops/ files to a new repository, and modified the db/current file to the latest revision, I –can- actually see the files. I just can't see the author nor date of the revision in the web. When I try to checkout I get "Found malformed header 'P ' in revision file. When I run “svnadmin verify” I get: ' in revision file Found malformed header 'P.

Does anyone have any idea of how I can recover these repositories? I can package them and send them out if you believe you can help.

Thank you!

[Ryan Schmidt]

Perhaps the developers more familiar with Subversion's internals will have another viewpoint, but I would refrain from attempting to shoehorn files from the internals of one repository into another repository. In my years on this list I've never heard of anybody trying that. It's not meant to be done. There are too many variations in the way the internals of the repository could be arranged and formatted.

I'd start from the error you mentioned: "invalid name for 'fsfs'". I can't find such an error message in Subversion. I found an error "Invalid name for FS type '%s'"; is that what you saw? When exactly did you see the error: what commands had you run?

[David Brodbeck]

On Sun, Aug 2, 2015 at 7:10 PM, Tim Tornid <timt...@gmail.com> wrote:

Hello,

I had a catastrophic Subversion server loss, and I'm having some troubles recovering. The server was using VisualSVN 3.2.3 which is Apache Subversion 1.8.13.

What version is the new server running?  I'd suggest using the exact same version of VisualSVN if you can, to maximize the odds of success.  Wait until you have a working repository to attempt any upgrades.  (Apologies if you already thought of this.)

 

--

D. Brodbeck

System Administrator, Linguistics

University of Washington

GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875