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. Not a good
scenario.
What were you saying before about a manual repair again? I know it didn't
sound pleasant :(
It might be the only way to repair this though... it's either that or dump
and re-import the records somehow.
Can something along that lines be done?
On Mon, 24 Aug 2009 19:21:34 -0600, Michael Stauber <bq (at mark) solarspeed.net>
wrote:
> Hi J.D.,
>
>> You're right - that's certainly not the news we wanted to hear!
>
> Yeah, I can imagine.
>
>> Unfortunately our backup might not be in the best of shape. It should
>> have backed up early this morning, but for some reason
>> the codb.oids and db.classes files are not present in the backup... I
>> think that it was because of the permissions on them (600 root:root)
>
> Yeah, that's the default ownership and permissions for them:
>
> [root@cbq web]# ls -la /usr/sausalito/codb/
> total 68
> drwxr-xr-x 4 root root 4096 Aug 7 10:14 .
> drwxr-xr-x 27 root root 4096 Aug 25 03:15 ..
> -rw------- 1 root root 13 Aug 25 03:00 codb.oids
> -rw------- 1 root root 40960 Aug 25 03:00 db.classes
> drwx------ 582 root root 12288 Aug 25 03:00 objects
> drwxr-xr-x 2 root root 4096 Aug 25 03:15 txn
>
>> my codb.oids looks like:
>> 1-2650,2653-2732,2742-2819,2825-2829,2831-2837,2839-2850,2855-2870,2876-289
>> 7,2903-3116,3122-3129,3131-3162,3164-3215,3221-3377,3380-3414,3420-3500,3502
>> -3581,3583-3800,3815-3820 Which seems a little longer than is typical...
>
> That's a bit cluttered, but not all that unusual. Typically there aren't
> so
> many "gaps" in between the Object IDs, but on a long running server with
> plenty of DNS records, too, this can happen.
>
>> I'll have a go at restoring from backups and see how bad it ends up :(
>
> Indeed. Best of luck to you and lets hope all goes well!
>
--
J.D. Lien
Ph: 780-702-3114