RE: Onbar physical followed by onbar logical...then...ontape ?
-----Original Message-----
From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]
On Behalf Of scottishpoet
Sent: Monday, November 14, 2005 6:50 PM
To: informix-list@iiug.org
Subject: Re: Onbar physical followed by onbar logical...then...ontape ?
>since you were taught not to mix onbar and ontape the, since you
archive using onbar
>you will have been backing up your logical logs using onbar as well, I
assume this is a
>purely hypothetical question
Normally, yes logs are backed up with onbar...we lost the Netbackup
server, so I backed up logs to disk quickly with ontape to keep things
moving,
since I Could not access backup manager. And did not have time to figure
out how to safely change storage managers to
ISM locally and use onbar. But yes, it is purely hypothetical at this
point.
sending to informix-list
Gentsch, Sam wrote:
> -----Original Message-----
> From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]
> On Behalf Of scottishpoet
> Sent: Monday, November 14, 2005 6:50 PM
> To: informix-list@iiug.org
> Subject: Re: Onbar physical followed by onbar logical...then...ontape ?
>
>
>>since you were taught not to mix onbar and ontape the, since you
>
> archive using onbar
>
>>you will have been backing up your logical logs using onbar as well, I
>
> assume this is a
>
>>purely hypothetical question
>
>
>
> Normally, yes logs are backed up with onbar...we lost the Netbackup
> server, so I backed up logs to disk quickly with ontape to keep things
> moving,
> since I Could not access backup manager. And did not have time to figure
> out how to safely change storage managers to
> ISM locally and use onbar. But yes, it is purely hypothetical at this
> point.
> sending to informix-list
Seeing as there have been several "hack" suggestions I thought I would
confirm that I have tested the following :
Step 1.
Amend the ixbar.<servernum> file, adding an extra line for the log which
isn't in the storage manager but is on ontape, and make the object id
duff (e.g. 99999)
Step 2.
onbar -r -p
Step 3.
onbar -r -l
At the end it will try and get the "duff" logical log from the storage
manager and then suspend logical recovery.
Step 4.
ontape -l
which will then go off and get the logs via ontape that are on disk.
Not supported, not supported and I believe that it is, errr, not supported.
If in doubt about the above, post your ixbar.<servernum> file (or at
least the relevant bits) and I will "show you how".
TBP
What can I say but
"it's always fun to play around with your backups and try risky
unsupported stuff.
It's always fun until the restore doesn't work!"
I'd hate to think what situation this would leave you in if you then
backup logical logs via onbar and
the instance fails before the next level 0 archive completes.
You have
onbar level 0 archive
logical logs in onbar
logical logs in ontape
logical logs in onbar.
How do you restore that then?
Plus onbar will be very confused.
If the storage manager fails then do
level 0 archive with ontape
logical log backups with ontape
When the storage manager is back do
onsmsync (?) to resync the storage manager and onbar (sysutils
database, ixbar file etc).
level 0 archive with onbar
logical log backups with onbar.
That way you either restore everything via ontape or everything via
onbar.