Hello everyone.
Last week we've had sort of trouble - one chunk went offline after two
mirrored disk crashed simultaneously (which was admitedly our fault).
No problem, we take backups every night and continously backup logical logs
so everything was in place for warm restore (it was non-critical dbspace
residing on that chunk).
But, we've had problems with backup server and it's tape library.
Fortunately, all went well and restore was successful.

Of course, that posed a question: what if backup server was unavailable?
I read through Backup and Restore Giude and started playing with external
backup/restore.
At the moment we're using onbar for backup/restore with Legato Networker as
storage manager.
Informix (version 10.00FC3) uses exclusively raw devices.

My idea was to be able to restore (to some extent at least) an instance even
if the storage manager was unavailable.
The procedure described in guide is clear to me, I just want your opinion on
my conclusions, which are as follows...

0. Everything that's supposed to be backed up needs to be dumped in
filesystem and copied to remote host (which is nowhere near current backup
solution).
1. After blocking the instance I have to dump all chunks for all dbspaces to
filesystem, and also the previous and current logical log(s) and then move
it to remote host.
2. Since onbar can't be used to back up logical logs to filesystem (or at
least I wasn't able to find the way to do it) I have to use ontape (which
can do it in v10).
3. After ontape -a finishes, it marks all logical log(s), up to the current
one, as backed up. That means onbar will not back them up later!
4. The previous step isn't that bad since after external backup (and
unblocking the instance) I'll take regular scheduled backup with onbar
(level 0, 1 or 2, depending on the day of the week) and only logs that gets
backed up after that backup are needed in case of regular restore.
5. All of this I plan to do automatically through the script called from
cron, during the period of lowest activity.

So, before I start thorough testing my question is: how does this all sound?
Is this a valid way to do something like this or am I missing something
important?

Thanks everyone.

I read a case study about this awhile back but I haven't tried it so I
am only giving knowledgable conjecture not information gathered from
real experience. So take it for what it is worth. I hope this fosters
conversation and debate so I can correct any misunderstandings that I
have because we are also thinking about doing this but we haven't
gotten to the research stage.

Is this what you are talking about:
onmode -c block

<get permanent copy of chunks in some way>

onmode -c unblock

The onmode -c puts all of the chunks into a consistent state and the
block keeps them there until you give it the unblock command. During
the blocked time you can copy every chunk to a file, or tape. If you
have drives that have a double mirroring scheme you can break one of
the mirrors for each drive and unblock the server and then backup the
now unmirrored drive. This method gives you basically instant, as far
as your users know backups. After you copy off the unmirrored drives
you can remirror the drives. I guess you can do this with single
mirrored drives but during the copy phase the database isn't mirrored.
When I say mirrored I mean OS or drive vendor mirroring. I know EMC had
SANS that did double mirroring for this kind of backup. I would suspect
others would have this technology also.

I don't think that you need to do anything with the current and
previous logs. This is because these have been applied to the dbspaces
that you have just backed up.

Now this doesn't solve point in time backups using the logs. You can
continue using onbar to backup the logs. Then to do a restore you copy
everything from your external backup and then you do a onbar -r -e [-t
<time> | -n <log>] [-O] [-f <filename> | <spaces>] to apply the onbar
log backups. onbar will automatically figure out which logs to apply to
get to the point in time that you want. I wonder now if you have backed
up your logs with ontape can you do an onbar physical restore and then
an ontape logical restore? If so then do an onbar -r -p -e ... then
apply the logs that you need using the ontape -l command. It seems like
you can but I don't actually know.

> Is this what you are talking about:
> onmode -c block
> <get permanent copy of chunks in some way>
> onmode -c unblock

Basically, yes.
I'd use dd, gzip and netcat for dumping all chunks (all of them in raw
devices) to filesystem on a remote host.

> The onmode -c puts all of the chunks into a consistent state and the
> block keeps them there until you give it the unblock command. During
> the blocked time you can copy every chunk to a file, or tape. If you
> have drives that have a double mirroring scheme you can break one of
> the mirrors for each drive and unblock the server and then backup the

Yes, I've read about the mirroring, but in this stage I don't consider it.
I'd have to do it manually, or spend years for writing a script to do it.
My idea was to launch a cron script early in the morning, between 3am and
4am when there's almost no one connected.

> I don't think that you need to do anything with the current and
> previous logs. This is because these have been applied to the dbspaces
> that you have just backed up.

This is exactly what I needed confirmation for.
Martin also suggested it in his reply and it perfectly suits me.
It's because documentation states that logical logs are mandatory for
successful external restore.
It seems that I forgot that logs are not only backed up but also reside on
the disk (from which they get backed up) :-)

> Now this doesn't solve point in time backups using the logs. You can

Well, at the moment I'm not concerned about point-in-time restores. They
fork fine when using onbar and storage manager that does backups is
available (I tested it, although just on trivial set of data).
I'm thinking about external backups/restores because few days ago I was
frightened with strange backup verification results. "Onbar -v" aka
archecker wasn't able to verifiy neither of many backups in the last month.
So we thought something must be wrong with our backup tape library and/or
storage manager. But, when we restored from the last backup taken (it was
whole system backup) everything was fine, all onchecks I ran were
successful.

> I wonder now if you have backed
> up your logs with ontape can you do an onbar physical restore and then
> an ontape logical restore? If so then do an onbar -r -p -e ... then
> apply the logs that you need using the ontape -l command. It seems like
> you can but I don't actually know.

For all I know this can't be done because onbar and ontape internals are
different and you can't backup storage spaces with onbar and logical logs
with ontape and have a decent restore with that.
Somebody correct me if I'm wrong, please.