Introduce an official, supported control command utility pair to standardize and automate point in time backup and restoration of IBM MQ queue manager configurations, authorities, and operational state across distributed platforms.
Business Problem / Use Case
Currently, backing up an IBM MQ queue manager requires administrators to maintain custom, OS level scripts that combine utilities like dmpmqcfg with manual file system copies of data and log directories. This model requires strict coordination of queue manager states to avoid data inconsistency or corruption, which introduces several distinct challenges for modern enterprise environments:
Operational Risk: Custom backup scripts vary across teams and platforms such as AIX, Linux, and Windows. They are tightly coupled to internal directory structures, making them prone to failure during MQ upgrades, OS patches, or storage reconfigurations.
Middleware Skills Gap: Newer engineers frequently come from database or integration backgrounds where unified backup tools like mqsibackupbroker are standard. Requiring deep knowledge of internal MQ file layouts increases the risk of human error during high pressure disaster recovery scenarios.
CI/CD Barriers: Reproducing a queue manager for development, testing, or cloud staging requires a manual, multi step process of configuration export and file copying. This limits the ability to integrate MQ into modern GitOps and containerized workflows.
Recovery Complexity: Disaster recovery procedures remain manual and error prone, which drives up Mean Time to Resolution. There is no single, auditable operation to reliably restore a queue manager to a known good state.
Proposed Solution / Specification
This proposal introduces two new native MQ control commands to address these gaps.
1. Backup Command: crtmqbackup
Syntax: crtmqbackup -m QMGR_NAME -o /path/to/backup/archive.bak [options]
Execution Modes:
Offline: Verifies the queue manager is cleanly stopped via endmqm, then captures the qm.ini configuration, object definitions via internal dmpmqcfg mechanics, OAM authority records, and the queue and log data directories into a single compressed archive.
Online: Provides a transactionally consistent backup while the queue manager is running. It forces a log checkpoint, flushes in flight persistent transactions to disk, and briefly quiesces new transactional work during the snapshot window to capture object definitions and persistent message state without a full outage.
Optional Parameters:
--compress: Built in compression using standard algorithms like gzip or zstd.
--encrypt: Optional encryption utilizing a provided password or certificate.
2. Restore Command: rstmqbackup
Syntax: rstmqbackup -i /path/to/backup/archive.bak [-m NEW_QMGR_NAME] [options]
Capabilities: Restores a queue manager directly from a backup archive, optionally renaming the queue manager during the restore process and automatically adjusting internal metadata for portability. This directly supports disaster recovery, environment cloning, and test environment provisioning.
Design Considerations
This capability is intended as a higher level orchestration layer built on top of existing MQ recovery mechanisms, not a replacement for them. These utilities would leverage internal MQ checkpointing and logging to ensure consistency, provide clearly defined recovery semantics aligned with MQ transactional behavior, and remain fully interoperable with existing enterprise backup solutions. This capability is designed to complement, not replace, existing file system level backup and enterprise snapshot strategies by providing a consistent MQ aware orchestration layer.
Consistency Scope: Persistent messages and committed transactions are included in both modes. Non-persistent messages and transient in flight state are not guaranteed in online mode, which is fully consistent with existing MQ recovery semantics.
Why a Native Implementation is Needed: While customers can script these processes today, an official implementation provides deep integration with MQ internals, a version stable interface across releases, cross platform consistency, and futureproofing against internal architectural changes. This is a standardized, supported operational capability rather than a simple convenience wrapper.
Expected Benefits
Standardized DevOps Integration: Provides a single command interface that simplifies integration with automation tools like Ansible, Terraform, and OpenShift pipelines.
Reduced Recovery Times: Transforms queue manager recovery from a multi step file manipulation procedure into a single, auditable operation.
Improved Consistency: Eliminates variation in custom scripts across teams, reducing maintenance overhead and scripting errors.
Accelerated Cloud Migration: Provides a deterministic, portable backup artifact to easily seed queue managers in containerized environments like Cloud Pak for Integration or Kubernetes.
Regulatory Alignment: Delivers an IBM supported, auditable backup and restore mechanism, simplifying compliance validation and reducing reliance on custom built tooling.
This capability reduces queue manager recovery from a multi step, error prone procedure to a single, predictable, and auditable operation.
We recognize that this is a valid requirement. However it doesn't fit with our delivery plans for the next year or so.
As a result we are declining this idea. While declined the idea can still be voted, and commented, upon.