Hmmm,
looking into the /usr/sausalito/codb/objects directory and all
subsequent oids it shouldn't be unreasonable to re-create the index as
well as the codb.oids file. All information in the db.classes file as
well as the used oids are in the DB. Which could be recursively read.
Just recreate the index and then create the codb.oids file based on
whats in the objects directory.
It's a hack but we might need it in the future anyway, to be able to
migrate the gui in the future instead of doing a backup/restore
migration.
Just my 2 cents...
/Rickard
On Mon, 2009-08-24 at 19:31 -0600, J.D. Lien wrote:
> 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!
> >
>
>
--
Rickard Osser <rickard.osser (at mark) bluapp.com>
BluApp AB