Tips for backup and recovery
Use this topic to understand some backup and recovery tasks.
The queue manager restart process recovers your data to a consistent state by applying log information to the page sets. If your page sets are damaged or unavailable, we can resolve the problem using your backup copies of our page sets (if all the logs are available). If your log data sets are damaged or unavailable, it might not be possible to recover completely.
Consider the following points:
- Periodically take backup copies
- Do not discard archive logs you might need
- Do not change the DDname to page set association
Periodically take backup copies
A point of recovery is the term used to describe a set of backup copies of IBM 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 IBM MQ is consistent up to the point that these copies were taken. Provided that all logs are available from this point, IBM MQ can be recovered to the point of failure.
The more recent your backup copies, the quicker IBM MQ can recover the data in the page sets. The recovery of the page sets is 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 we must keep your log data sets and backup copies of page sets for IBM 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 our backup copies being lost or damaged, 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 our page sets and, if we are using single logging or a single BSDS, two copies of our archive logs and BSDS. If we are using dual logging or BSDS, make a single copy of both archive logs or BSDS.
Before moving IBM MQ to a production environment, fully test and document your backup procedures.
- Backing up your page sets
We need to back up page sets regularly. Some enterprises back up the page sets twice a day.
You need the active and archive logs since a backup to be able to recover using the backup. You need enough log data to go back four checkpoints if the backup was taken when the queue manager was running.
We can use ADRDSSU FastReplication to back up page sets, and we can do this while the queue manager is active. Note that we need to ensure there is enough space in the storage pool.
- Backing up your object definitions
Create backup copies of our object definitions. To do this, use the MAKEDEF feature of the COMMAND function of the utility program (described in Use the COMMAND function of CSQUTIL).
We should do this whenever you take backup copies of our queue manager data sets, and keep the most current version.
- Backing up your coupling facility structures
If we have set up any queue sharing groups, even if we are not using them, we must take periodic backups of our CF structures. To do this, use the IBM MQ BACKUP CFSTRUCT command. We can use this command only on CF structures that are defined with the RECOVER(YES) attribute. If any CF entries for persistent shared messages refer to offloaded message data stored in a shared message data set (SMDS) or Db2, the offloaded data is retrieved and backed up together with the CF entries. Shared message data sets should not be backed up separately.
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 we use, IBM 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.
- Backing up your message security policies
- If we are using Advanced Message Security to create a backup of our message security policies, create a backup using the message security policy utility (CSQ0UTIL) to run dspmqspl with the -export parameter, then save the policy definitions that are output to the EXPORT DD.
Do not discard archive logs you might need
IBM MQ might need to use archive logs during restart. We must keep sufficient archive logs so that the system can be fully restored. IBM MQ might use an archive log to recover a page set from a restored backup copy. If we have discarded that archive log, IBM MQ cannot restore the page set to its current state. When and how you discard archive logs is described in Discarding archive log data sets.
We can use the /cpf DIS USAGE TYPE(ALL) command to display the log RBA, and log range sequence number (LRSN) that we need to recover your queue manager's page sets and the queue sharing group's structures. We should then use the print log map utility (CSQJU004) to print bootstrap data set (BSDS) information for the queue manager to locate the logs containing the log RBA.
For CF structures, we need to run the CSQJU004 utility on each queue manager in the queue sharing group to locate the logs containing the LRSN. You need these logs and any later logs to be able to recover the page sets and structures.
Do not change the DDname to page set association
IBM MQ associates page set number 00 with DDname CSQP0000, page set number 01 with DDname CSQP0001, and so on, up to CSQP0099. IBM MQ writes recovery log records for a page set based on the DDname that the page set is associated with. For this reason, we must not move page sets that have already been associated with a PSID DDname.
Parent topic: Plan for backup and recovery