Backing up the queue-sharing group at the prime site

At the prime site we need to establish a consistent set of backups on a regular basis, which can be used in the event of a disaster to rebuild the queue-sharing group at an alternative site. For a single queue manager, recovery can be to an arbitrary point in time, usually the end of the logs available at the remote site. However, where persistent messages have been stored on a shared queue, the logs of all the queue managers in the queue-sharing group must be merged to recover shared queues, as any queue manager in the queue-sharing group might have performed updates (MQPUTs or MQGETs) on the queue.

For recovery of a queue-sharing group, we need to establish a point in time that is within the log range of the log data of all queue managers. However, as we can only forward recover media from the log, this point in time must be after the BACKUP CFSTRUCT command has been issued and after any page set backups have been performed. (Typically, the point in time for recovery might correspond to the end of a business day or week.)

The following diagram shows time lines for two queue managers in a queue-sharing group. For each queue manager, fuzzy backups of page sets are taken (see Method 2: Fuzzy backup). On queue manager A, a BACKUP CFSTRUCT command is issued. Subsequently, an ARCHIVE LOG command is issued on each queue manager to truncate the active log, and copy it to media offline from the queue manager, which can be transported to the alternative site. 'End of log' identifies the time at which the ARCHIVE LOG command was issued, and therefore marks the extent of log data typically available at the alternative site. The point in time for recovery must lie between the end of any page set or CF structure backups, and the earliest end of log available at the alternative site.

Figure 48. Point in time for recovery for 2 queue managers in a queue-sharing group

WebSphere MQ records information associated with the CF structure backups in a table in DB2. Depending on your requirements, you might want to coordinate the point in time for recovery of WebSphere MQ with that for DB2, or it might be sufficient to take a copy of the WebSphere MQ CSQ.ADMIN_B_STRBACKUP table after the BACKUP CFSTRUCT commands have finished.

To prepare for a recovery:

  1. Create page set backups for each queue manager in the queue-sharing group.

  2. Issue a BACKUP CFSTRUCT command for each CF structure with the RECOVER(YES) attribute. We can issue these commands from a single queue manager, or from different queue managers within the queue-sharing group to balance the workload.

  3. Once all the backups have completed, issue an ARCHIVE LOG command to switch the active log and create copies of the logs and BSDSs of each queue manager in the queue-sharing group.

  4. Transport the page set backups, the archived logs, the archived BSDS of all the queue managers in the queue-sharing group, and your chosen DB2 backup information, offsite.