Saving the Log Files

In the event that the worst happens and the database needs to be recovered from tape, it's essential that the logfiles be regularly copied to tape. They can also be stored on other media. Such saving to disk or optical disk can be kludged together, but the OnLine/IDS archive utilities are really designed to be used with a tape device, preferably two. This changes in the NT port, where archives and logfile backups can both be directed to disk using the Informix Storage Manager (ISM) program in conjunction with onbar/onarchive.

There are really two good reasons to get the logs copied to tape rapidly. The first is the obvious reason of getting them safely stored off-line. The other reason is that once a logfile has filled up with data, it cannot be reused unless it has been marked as "backed up" and copied to tape (or some other medium).

Both engines provide two methods for saving the logfiles to tape, automatic backup and continuous backup. Automatic backup is not really automatic. It just backs up all existing logfiles to tape. It's almost useless except for instances where you need to back up a batch of logs in a one-time situation. After an automatic backup, you need to change tapes in the tape device because tb/ontape will write over them the next time it backs up logfiles. The really useful backup is the continuous backup option. Under continuous backup, whenever a logfile fills up, it is automatically backed up to the tape device and the process waits for the next log to fill up. Continuous backup provides an almost invisible method of assuring that the tape backups get done. Under continuous backup, the tape device is not closed and the backups of the logfiles occur one after another on the tape. The IDS engine also supports an ALARMPROGRAM such as logs_full.sh, that automates the logfile backup. Look in your $INFORMIXBIN directory to see how the ALARMPROGRAM works.

It's recommended that you have two tape devices available for each Informix instance. This can be a major problem if you are running multiple instances. It usually means that it becomes very hard to automate database archives and logfile backups with multiple instances unless you have a lot of tape devices. Consider this if you are considering going to multiple instances of the database.

For a single instance, it is still best to have two tape drives, one for the archives and one for the logfile backups. Working with one drive is possible, but it means that you'll have to do some manual intervention. Actually, this is not all bad. The temptation, especially with large DAT drives, is to just pop in a logfile backup tape, turn on continuous logfile backups, and wait till the end of the tape. This is not advisable for several reasons. First, tb/ontape does not reliably handle end of tape conditions and it's best to avoid getting that far on a tape. Second, if you have gigabytes of logfiles on one tape, you're putting a lot of your eggs in one eight-millimeter basket. If you're on your hundredth logfile and the tape breaks, you've just lost numbers one through ninety-nine.

The most important reason is that if you ever have to apply the logfiles in a restore situation, you'll have to run through the entire logfile backup tape, which may take forever. Suppose you have a logfile backup tape that starts with logfile number 1 and goes through number 100, with each logfile taking 20 megabytes. Your last archive occurred at logfile number 75. If you should have to restore from tape, you'll first have to load the archive tape, then you'll have to apply the logs from number 75 to number 100. Since all of your logfiles are on one tape, you'll have to run through tapes number 1 through number 74 before you get to the first usable logfile. The amount of time that it takes to do this will be magnified greatly if you have users asking you "When will the system be back up?" every five minutes.

It's best to rotate your logfile tapes on a regular basis along with your archive tapes. If you're using one tape drive for both archives and logfile backups, you're forced to do this anyway, since you have to restart the logging after the archive is done.