Periodically take backup copies

A point of recovery is the term used to describe a set of backup copies of WebSphere MQ page sets and the corresponding log data sets required to recover these page sets. These backup copies provide a potential restart point in the event of page set loss (for example, page set I/O error). If you restart the queue manager using these backup copies, the data in WebSphere MQ will be consistent up to the point that these copies were taken. Providing that all logs are available from this point, WebSphere MQ can be recovered to the point of failure.

The more recent your backup copies, the quicker WebSphere MQ can recover the data in the page sets. The recovery of the page sets are dependent on all the necessary log data sets being available.

In planning for recovery, we need to determine how often to take backup copies and how many complete backup cycles to keep. These values tell you how long keep your log data sets and backup copies of page sets for WebSphere MQ recovery.

When deciding how often to take backup copies, consider the time needed to recover a page set. The time needed is determined by the following:

• The amount of log to traverse.

• The time it takes an operator to mount and remove archive tape volumes.

• The time it takes to read the part of the log needed for recovery.

• The time needed to reprocess changed pages.

• The storage medium used for the backup copies.

• The method used to make and restore backup copies.

In general, the more frequently you make backup copies, the less time recovery takes, but the more time is spent making copies.

For each queue manager, you should take backup copies of the following:

• The archive log data sets

• The BSDS copies created at the time of the archive

• The page sets

• Your object definitions

• Your CF structures

To reduce the risk of your backup copies being lost of damaged, you should consider:

• Storing the backup copies on different storage volumes to the original copies.

• Storing the backup copies at a different site to the original copies.

• Making at least two copies of each backup of your page sets and, if you are using single logging or a single BSDS, two copies of your archive logs and BSDS. If you are using dual logging or BSDS, make a single copy of both archive logs or BSDS.

Before moving WebSphere MQ to a production environment you should have tested and documented your backup procedures.

 

Backing up your object definitions

You should also create backup copies of your object definitions. To do this, use the MAKEDEF feature of the COMMAND function of the utility program (described in the WebSphere MQ for z/OS System Administration Guide).

You should do this whenever you take backup copies of your queue manager data sets, and keep the most current version.

 

Backing up your Coupling Facility structures

If you have set up any queue-sharing groups, even if you are not using them, take periodic backups of your CF structures. To do this, use the WebSphere MQ BACKUP CFSTRUCT command (described in the WebSphere MQ Script (MQSC) Command Reference). We can use this command only on CF structures that are defined with the RECOVER(YES) attribute.

It is recommended that you take a backup of all your CF structures about every hour, to minimize the time it takes to restore a CF structure.

You could perform all your CF structure backups on a single queue manager, which has the advantage of limiting the increase in log use to a single queue manager. Alternatively, you could perform backups on all the queue managers in the queue-sharing group, which has the advantage of spreading the workload across the queue-sharing group. Whichever strategy you use, WebSphere MQ can locate the backup and perform a RECOVER CFSTRUCT from any queue manager in the queue-sharing group. The logs of all the queue managers in the queue-sharing group need to be accessed to recover the CF structure.