Offline backups

Offline backups can be used for configuration information; that is, all information about your CICS® system except the CICS log and the data that is stored on the file manager logical volumes. Offline backups can also be used for those conditions in which the restoration of applications to the point of failure is not required.

Schedule your backups in accordance with the amount of work that it is acceptable to lose. For example, if you can afford to lose the information for a day’s work, schedule the offline backups for once a day. The need to shut down the region and the file manager affects your decisions about the timing and frequency of the backups.

When you use an SFS server for queue and file management, you must schedule periodic backups of the SFS volume, which can be large and awkward to copy. Consider setting the parameters for the file size and the number of files so that each execution of the backup tool backs up part of an SFS volume instead of the whole volume. In this way, the backup tool produces files of a manageable size, but you need to ensure that it takes backups quickly and frequently. This is known as fuzzy or incremental backup.

For example, you can set the backup parameters such that the backup size is one-eighth of the whole SFS volume. Any eight successive backup files constitute a complete backup of the volume.

During recovery, the complete backup of the SFS volume is loaded, and the information in the log volumes and archive files is used to redo any changes that have occurred since the start of the backup; that is, since the time that the first of the eight incremental backups started. The result is to bring the SFS volume up-to-date. If the backup of the SFS volume is old, much log data is available to scan and act on. If the backup of the SFS volume is newer, less log data is needed, so recovery occurs more quickly.

If you are using DB2® for queue and file management, refer to the BACKUP DATABASE utility information in the DB2: Administration Guide.

The incremental backup mechanism ensures that all file managers and regions are restored to a state that is consistent for all transactions and consistent with the state of the log. This means that when the backup is restored:

These are the desirable effects for a transaction processing system, but they do not allow for recovery from the effects of a defective application program that possibly incorrectly adds, changes, or deletes records in a file and then commits the transaction.