Log shipping is how many enterprises move IBM MQ recovery data from a primary datacenter to a disaster recovery site when they are not using continuous synchronous replication products for every queue manager. The queue manager writes persistent changes to circular logs; when logs wrap, archive logs land on disk or tape. Shipping copies those files—by rsync, object storage replication, SAN async mirror, or mainframe tape pipeline—to the backup location. After primary loss, the backup queue manager replays shipped logs to reconstruct queues and messages as they existed at the last consistent recovery point. Beginners hear logs and think only troubleshooting. For DR, logs are the message insurance policy. This tutorial explains circular versus archive logs, shipping schedules, consistency, replay on the backup queue manager, lag and RPO, tooling patterns, z/OS differences, and pitfalls that leave DR queue managers empty or inconsistent.
Distributed queue managers use primary log files in a circular set—LOGFIL and LOGPATH attributes define count and size. While the queue manager runs, it writes all durable puts, gets, transactional commits, and object changes to the current log extent. When an extent fills, it becomes an archive log and a new extent becomes active. Archive logs accumulate in the archive directory until pruned per retention policy. Shipping can target archive logs only (simpler, higher lag) or include coordinated copy of active log and queue files during a controlled quiesce (lower lag, requires brief outage). Understand your release documentation for dspmqlog, rcrmqobj, and backup utilities—names vary slightly by platform.
| Approach | Typical lag | RPO impact | Notes |
|---|---|---|---|
| Archive log copy on schedule | Minutes to hours | Interval-bound | Script after log archive event |
| Storage array async mirror | Seconds | Small but non-zero | Whole volume; watch consistency groups |
| Quiesced snapshot | Near zero at snapshot | Low for that point | Brief stop or hold traffic |
| Product replication (RDQM etc.) | Milliseconds–seconds | Often lowest | HA/DR product, not manual ship |
A minimal shipping package includes archive log files and the queue manager log configuration metadata needed for replay. Queue files (.q files on distributed) or page sets on z/OS hold message data; logs describe how to apply changes consistently. DR procedures often ship the entire mqmdir data tree after quiesce, or ship logs plus periodic queue file sync—your vendor and IBM documentation for your version govern supported combinations. Never mix logs from different queue manager instances or different start times without media recovery procedures. Label shipments with log range, timestamp, and checksum.
Automate alerts when shipping falls behind—if the newest archive on DR is four hours older than primary, RPO is four hours. Operations dashboards should show lag in minutes, not only success/fail ping.
When DR activates, operators place shipped logs in the paths the backup queue manager expects, then start or restart with recovery. MQ replays logs to rebuild in-memory and on-disk state. You may see lengthy restart times on large hubs—factor that into RTO. If logs are missing a range, recovery stops or warns; do not ignore AMQ messages about log integrity. Practice replay quarterly on an isolated DR queue manager name to measure duration without touching production names.
Recovery point objective equals the worst-case gap between the last shipped log and the failure moment, plus any in-flight transactions not yet committed to log. Fifteen-minute shipping implies fifteen-minute RPO unless you also mirror active logs. Non-persistent messages may never appear on DR—state that in the plan. Syncpoint boundaries matter: in-doubt transactions after replay need transaction manager coordination identical to HA failover scenarios.
z/OS queue managers use BSDS to catalog log data sets and page sets for messages. DR may copy archive logs to tape and restore on DR LPAR, or use storage replication for log and page set volumes. Coupling facility queue sharing groups add complexity—member recovery differs from standalone QM DR. Work with IBM z/OS MQ documentation for your release; terminology includes archive log data sets, copy bundles, and recovery procedures in the operations guide. RACF and SMF may audit who mounted DR volumes.
Logs contain message payloads for persistent traffic—encrypt shipping paths (TLS on SFTP, encrypted buckets). Restrict DR landing zone access to break-glass roles. Retention on DR must meet legal hold requirements without exceeding storage budgets—automate prune after successful DR test apply where safe.
12345678910* Primary — list newest archive (paths vary by install) ls -lt /var/mqm/log/QM1/active/ | head * DR — compare highest RBA or log number cataloged # dr-log-catalog.txt should record: # LAST_SHIPPED_ARCHIVE=S0000123.LOG # LAST_SHIPPED_TIME=2026-05-17T14:32:00Z * Alert if primary newest minus DR newest > 15 minutes * On DR test: place logs, strmqm QM1_DR, review AMQ7xxx recovery messages
The queue manager keeps a diary of every important change. Log shipping photocopies new diary pages to a safe house. If the original diary burns, the backup copy lets you reconstruct what happened—up to the last page you copied.
Every time you finish a chapter in your coloring book, Mom takes a picture and sends it to Grandma's house. If our house floods, Grandma has pictures of all chapters up to the last picture—maybe not the page you were coloring right when the flood came.
Calculate RPO if archive logs ship every ten minutes and primary fails five minutes after a successful ship.
Design an alert for shipping lag using log sequence numbers.
Contrast log shipping with RDQM replication in three bullet points.
1. Log shipping moves:
2. Archive logs are created when:
3. Longer shipping interval generally means:
4. Backup QM recovery uses: