Re: Need Help with recovery of 7.31
Posted in 2005
Superboer wrote:
> for one
>
> if the filesystem is full, ontape -a will start writing to nonextisting
> stdout
> that you have to mount a new tape..... this will also fill up a
> filesystem
> not to mention eat a cpu.
ALARMPROGRAM script/application should handle that before running ontape.
We use my eventalarm.c program here for almos 8 years with no problems.
Eventalarm even correctly handles the situation Martin notes when multiple
logs complete before the initial ontape completes. After the ontape
completes eventalarm renames the archive file to a name that reflects its
contents and recreates the empty LTAPEFILE file ready for the next run.
What we also do is have a cron wake hourly, sweep all log archive files to
another machine using rcp for safety, and delete files older than 7 days.
This insures that every logical log backup file is on two independent
machines in two different data centers. In addition, the nightly FS
archives pick up the files on both machines and archive them to tape. Each
file is on up to 7 day's daily system archive tapes. Eventalarm.c is in
the utils3_ak package in the IIUG Software Repository.
> Most important have seen situations that it missed trx log data making
> it
> impossible to rollforward.
Haven't lost a single logical log archive in 8 years! If for some reason
the ontape fired immediately after the log fills fails, the next log fill
event will archvie both logs. In addition, we run an ontape -a to the same
disk file at server startup.
Art S. Kagel
> (can't remember the details could be copying or
> moveing the 'ontape-a tapefile' too soon or starting ontape-a too soon
> or...
> specially with blobs in blobspaces.)
>
>
> Superboer.
>
> Richard Spitz schreef:
>
>
>>"Superboer" <superboer7@planet.nl> schrieb:
>>
>>
>>>ahum most likely in log_full.sh which is configured as
>>>alarmprogram in $ONCONFIG.
>>>
>>>having this is a recept for disaster...
>>
>>Please explain. What's wrong with calling "ontape -a" from log_full.sh?
>>
>>Regards, Richard
>
>