jpierrot@chubb.com wrote:
> There is still a possibility that it might work - Assume that you will be
> using your logs for onbar
> Try this :
> Before taking your ontape backup , make sure that your logs are backed up
> to current - Then , comment out the alarm program onconfig line that calls
> logfull.sh, or rename logfull.sh to something else so no logs get backed up
> during the time of your ontape backup -
> As a result, you will end up with a few full logs that are waiting to be
> backed up.
> When ontape backup is complete, uncomment the alarmprogram line in onconfig
> or rename back to logfull.sh.
>
> For if you want to restore with onbar past the time you took your ontape
> backup, and any logs were backed up with ontape, your onbar point in time
> will not go beyond the starting time of your ontape.
>
>
>
>
>
>
> Marco Greco
> <marco@4glworks.c
> om> To
> Sent by: mweallans@panacea.co.uk
> owner-informix-li cc
> st@iiug.org informix-list@iiug.org
> Subject
> Re: Both ontape and onbar on the
> 07/06/2005 02:12 same system?
> PM
>
>
>
>
>
>
>
>
>
> mweallans@panacea.co.uk wrote:
>
>>One of our clients has been using ontape successfully for some time but
>>have been throwing away logical logs on the basis that they could
>>restore to the previous night.
>>
>>I have persuaded them to look at onbar and to backup their logs and
>>after a failure to get it working correctly with ISM they are now
>>implementing a BakBone NetVault Storage Manager based solution. This
>>is not without difficulty with the dialects of jargon - but we are
>>getting there slowly.
>>
>>However their next challenge is that they would like to run both ontape
>>and onbar for a period of time to backup the same server. I don't
>>think that should present a problem - or does anybody think or know
>>different?
>>
>>regards
>>
>>Malcolm
>>
>>
>
> Not a good idea - once you archive logical logs with one tool, they won't
> be
> available for archive with the other tool. In short, you'll have plenty of
> archives, but it's unlikely that you will be able to restore to where you
> want, or, in case of onbar, there's even the possibility that you won't be
> able to restore at all
> --
> Ciao,
> Marco

JP,
I haven't said that you can't get it to work - I have said that you will not
be able to restore to when you want to. And if you are not careful, an
inconsiderate use of ontape could actually prevent onbar from performing a
restore properly.
Note also that your plan will not work:-
an ontape archive copies the logs needed to rollback the transactions open at
archive time to the L 0 tape and marks them as archived to tape (!= backed up)
onbar -b -l does not bother to back up logs which are marked as archived to
tape, because it rightly deems them already to be available within the storage
manager, so it just marks them as backed up without taking any real action.
In short, every time you use ontape, a few logs will go missing from your
storage manager, even if you do not archive any logs with ontape.
If you use parallel onbar archives, or archive different dbspaces in different
moments in time, then this is a recipe for disaster.
As an advanced tech support analyst, I could tell you a number of interesting
war stories of mixed archiving strategies gone wrong. The best one is that of
a client who had just switched storage manager, and had some of the dbspaces
and some of the logs on one SM, and a few others on the SM he was using
previously, and was in desperate need of a restore. A colleague managed to use
a crude XBSA client to pull the objects from the old SM and inject them on the
new one. I myself have extracted logs from ontape tapes a fair number of times
in order to fix some of the scenarios described above.
--
Ciao,
Marco
__________________________________________________ ____________________________
Marco Greco /UK /IBM Standard disclaimers apply!

Informix faq http://www.iiug.org/techinfo/faq/informix.htm
4glworks http://www.4glworks.com
Informix on Linux http://www.4glworks.com/ifmxlinux.htm
sending to informix-list