Hi J.D.,
> Well, as it turns out, our backups were missing well... ALL of the actual
> files in each of the OID directories... so we've got nothing at all.
Yeah, depending on how you back up (and what) these files may not get backed
up.
> Not a good scenario.
No, unfortunately not.
> What were you saying before about a manual repair again? I know it didn't
> sound pleasant :(
No, it's not pleasant. In fact it's so much work that I'd discourage doing it.
I'll offer some advice now, but please read the entire message before you
actually do anything.
Like said: You'd have to manually go through all 3800 directories in
/usr/sausalito/codb/objects/ and would have to check if the files that are
within those directories match the Schema file for the Class of the Object. An
easy way of doing that is to use CCEclient and to attempt to make a small
change to each object. If the change goes through OK, then the Object is OK.
If it reports the -7 error, then something's wrong with the Object. Even if
you just need 30 seconds for each test, with 3800 Objects you'd be at it for
quite some time.
Reconstructing /usr/sausalito/codb/codb.oids is by far the easiest thing to
do. While it may be a start, it most likely won't get you out of the bend
entirely. What can be done there is this:
Make a copy of your existing /usr/sausalito/codb/codb.oids and put it
somewhere safe.
Then run this commands:
/etc/init.d/cced.init stop
ls -k1 /usr/sausalito/codb/objects/|sort -n|awk '{printf "%s,",$1}'|perl -pi -
e 'chop' > /usr/sausalito/codb/codb.oids
(That goes all into one line!)
/etc/init.d/cced.init start
The 1st command stops CCEd. The second command creates a new
/usr/sausalito/codb/codb.oids and will fill it with the numbers of your
existing Objects and will separate the numbers with a single ','. That is not
the entirely correct format for this file, but CODB should be able to work
with it. The third command starts CCEd again.
Now this MAY work. But if it doesn't, then be prepared to copy your backed up
/usr/sausalito/codb/codb.oids back into place.
> It might be the only way to repair this though... it's either that or dump
> and re-import the records somehow.
If I were in your situation, then I'd skip all of the above.
Instead I'd suggest trying a cmuExport first of all things. See if that goes
through. If it does, then it would be WAY less hassles to OS restore the box
and re-import from the cmuExport.
You see, the data on the server is certainly important to you. But CODB is the
"brain" of BlueQuartz (and BlueOnyx). Yours has Alzheimer and the mad cow
disease together. You may be able to fill some of the holes in the swiss
cheese type of brain your server now has, but in the long run ... would you
still trust it not to forget other important things? Even if you manage to fix
most of the issues ... in the longer haul there will still be some lingering
issues and you'd never know if it's still caused by the shot CODB, or if it's
something new and different.
If cmuExport fails, then it may still be partially salvageable. Like if it's
possible to cmuExport most of the sites and users (except for a few), then at
least those can be reconstructed far more easily. If need be from scratch.
That ought to be far easier than going through all CODB objects with a fine
toothed comb.
--
With best regards,
Michael Stauber