On Sep 5, 2007, at 07:21, Bicking, David (HHoldings, IT) wrote:
>>> The contents of db/revs/124 look reasonable. However the contents of
>>> db/revs/125 is not good. It is basically a bunch of ^@. When I tried
>>> to cat it, nothing is printed on the command line. However the
>>> contents of db/revs/125, db/revs/126 etc., all look reasonable upto
>>> revision 132.
>>
>> In the future, make sure you back up your repository religiously.
>> Creating a backup in the post-commit hook is the best idea,
>> so that the backup gets created the instant the original gets
>> created, so there's no chance for any data loss.
>
> All this raises a question for me. Unless I misread something in the
> thread, the corruption happened somewhere in February, but was not
> discovered until recently. Thus, a robust backup schedule still would
> not be useful here.
>
> Are there any tools available to "analyze" the database? I would like
> to have a nightly process verify the integrity of the repository, log
> any problems, and return a useful exit code. This, combined with a
> reasonable backup rotation, should prevent this problem from occuring.
> Ideally, the revision numbers (and user ids) affected by corruption
> should be logged so the dump/reload solution could be quickly
> executed.
Don't forget to Reply To All so your reply goes to the mailing list
too, not just to me.
The nice thing about FSFS repositories is that once created,
revisions never change. So the robust backup method is to backup the
revision files the moment they're created and retain them
indefinitely. If they ever become corrupted on the hard drive due to
hard drive controller failure or user error or what have you, restore
them from the immutable backup (CD, DVD, etc.).
Now, with "svn propset --revprop" you can change old revision
properlies. So it may be necessary to re-backup revprops if they change.
The tool to analyze the repo is "svnadmin verify"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 7 04:56:30 2007