Hi,
Am 25. Februar 2015 18:48:37 MEZ, schrieb Keith Johnson <k33f3r_at_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.
Andreas
Received on 2015-02-25 19:34:39 CET