Re: tbtape -c in background

Greg Salmon wrote: > > Mark D. Stock wrote: > > > > Neil Truby wrote: > > > > > > I've been asked to set up a background script to automatically run a > > > continuous logical log backup when my UNIX server starts. > > > > This can be done, but is SO dangerous that I'm not even going to > > say how. I would only implement this idea if I could ensure an > > operator was present 24 hours a day to pull out the tape when the > > system crashes. Then of course they might as well do a manual one > > if they are sitting there anyway. :-) > > > > I have been to sites running this where they couldn't even SPELL > > "logical log". When I asked for their logs to restore, they pointed > > at THE log tape in the drive. Of course they were right...., but > > every log backup was overwritten on the previous one, ie. every > > time the box was booted! :-( > > > > NOT a good idea IMNSHO. > > Biting the hand that offered to feed me... You can't win 'em all. ;-) > In this day of maximum automation and minimum operator skills, I beg to > differ. Oh go on then. :-) > I think you are OK if you backup your logs continuously to disk and then > do a Level 0 backup of the db every night, copying the logical log file > to a .bak file before nulling it and restarting the continuous backup. Using a disk "tape drive" is exactly the same as having a single tape stuck in the drive. If the ontape -c fires up a second time before your copy..., you can guess the rest. > I worked at a client that had 40 production boxes and 2 operators. There > was no question of them hovering over a terminal waiting for "feed me" > messages, so I did as described above. Then I wrote a basic safeguarding > shell that monitors free disk space on the filesystem storing the log > "tape", checks that ontape is running and greps the message log for > nasty words like "Assert Failure", paging the operator when things don't > look good. All the operator has to do is load 2 tapes every night, one > for the db and one for the rest. No, no your missing the point. My point about hovering over a terminal was a joke. :-(#) I have no problem with a FULLY automated routine which can safe guard the tape as soon as ontape finishes. Remember, ontape -c can finish when the process is aborted, OnLine is shutdown, the system is shutdown or the system crashes. The ONLY way you could achieve this with ontape is by using a disk "tape" as you suggest and then instead of running ontape from cron, run your own script which copies the last "tape" out BEFORE running ontape -c. This would be the only way to ensure the "tape" is not over-written again. This copy would also need to give unique names to EACH "tape" that was copied out. The bottom line is, OnLine needs a DBA. Not necessarily full-time, but it needs more attention than SE, and a lot of sites choose to ignore this. You wouldn't buy a manual car for the performance if you never intended to change gear yourself. Cheers, -- Mark. +------------------------------------------------------------------+ |Mark D. Stock - The West Solutions Group http://www.west.co.za | | The Informix FAQ is at http://www.iiug.org | |mailto:marks@west.co.za +-----------------------------------------+ |Tel: +27 11 803 2151 |If it doesn't work, force it! | |Fax: +27 11 803 2189 |If it breaks, it needed replacing anyway!| |Cell: +27 83 250 2325 |Well, that's how I code anyway! | +------------------------+-----------------------------------------+