Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Sat, 28 Feb 2015 22:24:05 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Keith Johnson <k33f3r@gmail.com>
Cc: Andreas Stieger <andreas.stieger@gmx.de>, users@subversion.apache.org
Subject: Re: Trying to restore a corrupted repo
Message-ID: <20150228222405.GG2045@tarsus.local2>
References: 
 <CAKtDWo_mU9EpqEa84oeG3GGCeCnKqbuhAu9jV6QFqmWGrkrnvQ@mail.gmail.com>
 <8A82FB92-8F78-4586-B536-D22261D7F26C@gmx.de>
 <CAKtDWo-2Lb05KuWH_ydN2BY=_TJAsr72uzpiVCGXzD7_rsv4oQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAKtDWo-2Lb05KuWH_ydN2BY=_TJAsr72uzpiVCGXzD7_rsv4oQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

Keith Johnson wrote on Wed, Feb 25, 2015 at 13:14:56 -0600:
> On Wed, Feb 25, 2015 at 12:33 PM, Andreas Stieger <andreas.stieger@gmx.de>
> wrote:
> 
> > Hi,
> >
> > Am 25. Februar 2015 18:48:37 MEZ, schrieb Keith Johnson <k33f3r@gmail.com
> > >:
> >
> > >When having a 4th person do a checkout recently, the process (via
> > >tortoisesvn) bombed out with a path to a revs file (db/revs/0/586 or
> > >something) and input/output error.
> > >
> > >It became evident very quickly that this was a result of bad sectors,
> > >and
> > >maybe 6 total files were corrupt.  I had backups for all but 1 of them
> > >(r772).  It later became evident that even my backup for one of them
> > >(r390)
> > >was corrupt.  Copied everything to a new drive, and attempted to start
> > >putting everything back together.
> > >
> > >The normal process for trying to salvage these situations is to dump
> > >skipping over the bad revisions such as:
> > >
> > >svnadmin dump /svn -r 1:389 > dump_0001_0389
> > >svnadmin dump /svn -r 391:771 --incremental > dump_0391_0771
> > >svnadmin dump /svn -r 773:head --incremental > dump_0773_head
> > >
> > >The problem is that the 2nd command fails because 390 is fubar.  (The
> > >gist
> > >is that I think 390 got truncated somehow because common error messages
> > >are
> > >thing like "lacks trailing newline" or "node id missing" - forgive me
> > >I'm
> > >not directly at the computer at the moment.)  In all my searching and
> > >reading the past few days, I've never really encountered anyone
> > >complaining
> > >that this process wouldn't work, I guess that's why I'm getting pretty
> > >confounded.
> > >
> > >As further weirdness, if I leave out the --incremental flag, the dump
> > >will
> > >actually work (and produce a 64G or so file), and complain about r390
> > >at
> > >the very end.  The problem as you might expect with this is that
> > >svnadmin
> > >load won't be able to load it because it wants to create everything
> > >again
> > >the first time it encounters it, and obviously that's useless (bombs
> > >out
> > >immediately that some item already exists).
> > >
> > >The original server in question was on ubuntu 12.04 which was running
> > >1.6.17(? definitely some version of 1.6).  New disk I made was with
> > >14.04
> > >which runs 1.8 something.  The problems seem to happen with both
> > >versions
> > >of svnadmin.
> > >
> > >Also, please spare me the backup lecture; believe me, I know.  I'm just
> > >a
> > >programmer trying to clean it up now.
> > >
> > >If anyone has seen anything like this before or has any suggestions for
> > >getting around any of this, that would be great.  I would love to be at
> > >the
> > >point where I could just get some valid dumps and then do what I can to
> > >recreate the missing revs, but I can't even get past the dump stage
> > >which
> > >is exceedingly frustrating.
> >
> > Make a backup of all existing working copies including the pristine
> > content cache under ".svn".
> >
> > When I last recovered a zeroed out block for someone I recreated the
> > broken revison N by committing an indentical change into a repository with
> > 1..N-1 loaded, with content from working copies and partial backups. The
> > remaining incremental dumps then applied cleanly. The fixed rev file could
> > be dropped back into the production area as it was.
> >
> 
> Hi Andreas, thanks for the response.
> 
> The revision in question is over a year old, so I'm not sure I can put it
> back exactly as it was (guess all I can do is try my best).  I assume
> there's no way to actually get historical data from pristine - that's just
> a cache of current documents, correct?

In theory, yes.  In practice, the cache may contain everything since the
last time you ran 'svn cleanup'.  See:

http://subversion.apache.org/docs/release-notes/1.7#wc-pristines