Archive Schedules

The tb/ontape program provides a three-level archive schema. A full archive is a Level 0 archive, and it corresponds to an epoch level UNIX dump. Everything is dumped to tape. A Level 1 archive will back up any database pages that have changed since the last Level 0 archive. Likewise, a Level 2 archive will back up any changes since the last Level 1 archive.

In deciding on an archive schedule, the DBA needs to balance several factors. Obviously, if the DBA has two fast extended capacity tape drives available, he will handle the archives differently than he will if he is backing up to one smaller tape drive. How volatile is the data? Does it change often, or are some of the tables very large and relatively static? How valuable is the data? Can it be easily re-created from other sources? How much time is available to do the archives? Are there people available to change tapes? Can you dedicate a terminal just for archiving?

For a system that has large-capacity tape drives with the entire archive being well below the UNIX filesystem size unit, the answer is easy. Simply do Level 0 archives daily. As the database gets larger, the archive process must become more complicated. At some point it becomes necessary to begin to do Level 1 and maybe Level 2 archives.

One of the major factors to consider when deciding on an archive schedule is what will happen in the event that you actually have to use the archives to recover the database. Archive tapes are sort of like atomic bombs. You keep them around but hope you never have to use them. If you are doing only Level 0 archives, the recovery process consists of loading the Level 0 tape and then applying any subsequent log tapes. Systems using Level 1 and Level 2 archives require loading the Level 0 tape first, followed by any Level 1 tape, followed by any Level 2 tape, then followed by any log tapes.

The process of applying the log tapes after restoring the archive is the most time-consuming part of the process. For this reason, it is best to schedule your archives so that you do not allow an excessive number of logs to accumulate between archives. For example, on a Pyramid multiprocessor system using 60-megabyte logs, it takes about 15 to 20 minutes to apply each log tape. At a TAPESIZE of about 2 gigabytes per tape, a full tape could take close to 10 hours to apply all of the logs if the tape were totally full and if all logfiles were used. Faster DAT and DLT tapes reduce the times needed.

Problems with an archive usually do not show up until you try to recover the data. The fact that tb/ontape completed an archive without errors and without complaint does not mean that the archive has completed properly. When setting up your system, at some point you need to schedule a test of your recovery process. The test should be as realistic as possible. If you are using multiple levels of archives, create them and try to recover from them. Let several logfiles accumulate after the last archive. When you recover, time the process, note the size of the database, note the size of the archives, and note how long it takes for each activity of the recovery. This data will help you to fine-tune your procedures.

Having to recover from an archive is usually a traumatic event, accompanied by confusion, angry users and managers, and much finger-crossing by the DBA. Recoveries also seem to occur after midnight on holidays. You want to make the process as simple and as fast as possible. Remember, though, that the most important part is actually getting the data back.

The archecker Program

The Informix User Group archives at http://www.iiug.org contain several versions of a program called archecker. This program can inspect an Informix archive tape and verify that it is indeed readable and consistent. This program was written by an Informix employee and is "unofficially supported" by Informix for IDS versions prior to 7.24. This means that Informix may help you acquire the program but that anything you do with it is your business and your responsibility. Archecker is included with IDS 7.30 releases with minimal documentation in the release notes. With IDS 7.31, it will be fully supported and documented.