On Wed, Apr 18, 2007 at 12:46:16PM -0700, Steve Midgley wrote:
> Thanks Ryan..
>
> You are correct that the svnadmin dump command is failing for the
> entire repository. Here's the error message that the ISP provided to
> me:
>
> # svnadmin dump repo | bzip2 > repo.dump
> * Dumped revision 0.
> <snip revision 1 through 161>
> * Dumped revision 162.
> svnadmin: Decompression of svndiff data failed
>
> Now, I don't even know positively that this is a BDB database b/c I
> can't get my hands on it (yet). Working on that. I believe the ISP has
> tried a recovery using "svnadmin recover" but I'm not sure why it
> didn't work. It's possible they are stored in FSFS format and they
> haven't communicated that clearly to me..
>
> Here's my follow up question. Let's take the following example:
>
> Revision 1-44: intact
> Revision 44-82: corrupt (can't be dumped)
> Revision 83-200: intact
>
> Will "svnadmin dump [path] -r NX:NY" allow me to dump Revisions 1-44
> and Revisions 83-200 and then "svnadmin load" these two files
> sequentially?
We used this script to attempt a dump/load of a corrupted FSFS repository
(replace the revision numbers with your own in the "seq" command):
#!/bin/bash
seq 1 151303 |\
while read r; do
(echo "==Dumping $r" 1>&2;svnadmin dump --incremental -r $r /svn) 2>> dump.log | (echo "==Loading $r"; svnadmin load $(pwd)/repos/) >> load.log
if [ "$?" -ne "0" ]; then
echo -e "\nCleaning stale transaction $r"
svnadmin lstxns $(pwd)/repos/ | xargs svnadmin rmtxns $(pwd)/repos/
fi
done >& log
This script was able to skip the corrupted entries. On the first run,
this script recovered about 10% of the repository. We then used
fsfsverify.py (google it) and manually replaced some bad revisions with
fake ones and got that recovery rate up to 85%. Took us many days (~50Gb
repo).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 18 21:59:05 2007