Re: tbtape: the spawn of Satan

> daveb@romulus.cfer.com (Dave Buchholz -- SA) writes: > > John Campbell wrote: > > } > } I have been dealing with attempts to run IFX-O/L's tbtape backup program > } from w/i a script for unattended backups. > Try something like this: > > $INFORMIXDIR/bin/tbtape -s << EOF | head -150 > > $1 > EOF > > The head statement will terminate tbtape if the situation you described occurs. > Make sure that the line number argument is large enough to handle your normal > backup output. Hope this helps. > > Cheers, > >>>> I must ask: Can someone from Informix please tell us how long it will be before you supply backup tools for OnLine that can run in the only sencible way - in the background. Of course support for multiple tape drives and stackers must be included in a final product. In the meantime support for a single tapedrive will help a lot of users. If the tape runs full, simply terminate with an error. Better still, look at the solution suplied with BRU (Backup and Restore Utility). If it runs out of tape space wile running in background mode, it simply writes a message to a file (can probably mail it also). Then it waits for a message from another supplied program, telling it that the user has changed to a new tape, and continues on the new tape. In this way backups can be run in the background (via cron of course). Should it one day become full, a user is told about it and can change tape first thing in the morning so the backup can finish then. Why can't backups be run in the forground? 1. There are no operators present at night after the batch jobs has finished. 2. It is too easy to forget. If it is started automatically the worst thing that can happen is that the tape(s) where not changed in the morning, so the next night they are reused for a new backup. I am also very frightend that I can't read the backup tapes. You need to implement some way of checking the tapes. An option to ontape/onarchive should read the tapes immediately after they have been written and check their consistency. This must be an option because if multiple tapes are needed this reading must be done for every tape before a new tape is inserted. If not we are in for trouble if an early tape is bad, and we need to redo the entire backup. Also if a tape is found to be bad the backup should, if possible, restart on a new tape from the place it where at the start of a bad tape. We shouldn't only find more or less hacker type solutions to problems. We should also push Informix to supply the proper solutions. Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company