Re: Logical Log Dilemma

Michael Strother wrote: > > > > > The company that I am working for has an off-again, on-again type of > > problem with logical logs. We are using Informix-OnLine 5.00 in > > combination with 4GL 4.10. Here's the situation: We currently > > continuously back up our logical logs to a Maynard (now Conner) Python DAT > > drive. We also have an internal 1/4" drive that we use for system > > backups. Every now and then, at random intervals, there will be a write > > error and continuous backup grinds to a halt. This has happened less > > often since I've started cleaning the drive regularly (and this never > > happens when we archive the database), although it still happens from time > > to time anyway. Our database is small by comparison; in fact, we will > > have to upgrade to a 2 GB hard drive in order to avoid running out of > > space on our 520 MB drive. At an Informix class I took recently, the > > instructor suggested first backing up to disk and then tar'ing them to > > tape at night. Since heavy days can generate up to 200 half-megabyte log > > files, we don't have room on our hard drive now, nor do we want to risk > > filling up the hard drive once we upgrade. Does anybody have any > > suggestions? > > > > This may seem a bit odd but if your only concern is that continuous backup not > stop due to a tape write error there are a couple of things you can do. > > One is to run the backup from a script that would catch the error notify > the administrator by mail or write or flashing the screen or whatever. > > Two would be to write a cron job that would run every five minutes or so > and do essentially the same thing (make sure that the tape backup is > still running. > > Third would be to write a daemon that backs up the logs every thirty > minutes or so to disk, then tars that to tape, then deletes the disk > file(s) > > Hope this helps > > Michael Strother > > > > > > > I think that the best option would be to run a script from crontab (every hour, half hour, the timing is up to you) that basically checks to see if "tbtape -c" or "ontape -c" is running. If not, then send an e-mail, print an alarm page, etc. to more than 1 person or printer. This way you've contacted more that 1 person that can resolve the problem.