Planning storage for the IBM MQ Operator

When you plan storage, consider aspects such as storage type, capacity, encryption, and any requirements that are specific to your cloud platform.

The IBM® MQ Operator can configure IBM MQ queue managers to run in one of two storage modes:

Ephemeral storage is used when all state information for the container can be discarded when the container restarts. This is commonly used when environments are created for demonstration, or when developing with stand-alone queue managers.
Persistent storage is the common configuration for IBM MQ and ensures that if the container is restarted, the existing configuration, logs and persistent messages are available in the restarted container.

The IBM MQ Operator provides the capability to customize the storage characteristics which can differ considerably depending on the environment, and the desired storage mode.

Ephemeral storage

IBM MQ is a stateful application and persists this state to storage for recovery in the event of a restart. If using ephemeral storage, all state information for the queue manager is lost on restart. This includes:

All messages
All queue manager to queue manager communication state (channel message sequence numbers)
The MQ Cluster identity of the queue manager
All transaction state
All queue manager configuration
All local diagnostic data

For this reason you need to consider if ephemeral storage is a suitable approach for a production, test or development scenario. For example, where all messages are known to be non-persistent and the queue manager is not a member of an MQ Cluster. As well as disposing of all messaging state at restart, the configuration of the queue manager is also discarded. To enable a completely ephemeral container the IBM MQ configuration must be added to the container image itself (for more information, see Building an image with custom MQSC and INI files, using the Red Hat OpenShift CLI ). If this is not completed, then IBM MQ will need to be configured each time the container restarts.

For example, to configure IBM MQ with ephemeral storage the storage type of the QueueManager should include the following:

queueManager:
  storage:
    queueManager:
      type: ephemeral

Persistent storage

IBM MQ normally runs with persistent storage to assure the queue manager retains its persistent messages and configuration after a restart. This is the default behavior. Because there are various storage providers, each supporting different capabilities, this often means that customization of the configuration is required. The example below outlines the common fields that customize the IBM MQ storage configuration in the v1beta1 API:

spec.queueManager.availability controls the availability mode. If you are using SingleInstance or NativeHA, you only require ReadWriteOnce storage. For multiInstance you require a storage class that supports ReadWriteMany with the correct file locking characteristics. IBM MQ provides a support statement and a testing statement. The availability mode also influences the persistent volume layout. For more information, see Planning high availability for IBM MQ in containers.
spec.queueManager.storage controls the individual storage settings. A queue manager can be configured to use between one and four persistent volumes.

The following example shows a snippet of a simple configuration using a single-instance queue manager:

spec:
  queueManager:
    storage:
      queueManager:
        type: persistent-claim

Storage capacity

When you use the IBM MQ Operator, try to ensure that you request volumes that are large enough for your ongoing needs.

[MQ 9.4.5 Feb 2026] One example of when you should increase volume size is if you set the enabled property of the Scratch or Tmp volumes to false (the default value is true). In this configuration, Scratch or Tmp data is written to the queue manager data volume. You should therefore increase the .spec.queueManager.storage.queueManager size property to account for the expected use of the Scratch and Tmp volumes. The default value for the size property is 2Gi. The default values of the sizeLimit properties for Scratch and Tmp volumes are 100M and 2Gi respectively; account for these sizes when Scratch and Tmp data is written to the queue manager data volume.

If you need to increase the storage capacity of one or more volumes, these volumes can be expanded if your storage class supports volume expansion. Volumes can be expanded either by an online or offline procedure. An offline procedure requires QueueManager pods to be restarted, whereas an online procedure does not. To determine if your storage class supports volume expansion, and which procedure the volume expansion follows, refer to your storage provider documentation. You should consider this information when selecting a storage class. For a guide to volume expansion, see Expanding persistent volumes.

Encryption

IBM MQ does not actively encrypt data at rest. Therefore you should use passively encrypted storage, or IBM MQ Advanced Message Security, or both, to encrypt your messages. On IBM Cloud® both block and file storage are available with passive encryption at rest.