RabbitMQ

Published: 15 Jan. 2025 Last updated: 11 Dec. 2025

Summary

RabbitMQ is an open-source message broker that enables reliable communication between distributed systems through message queuing. It implements the Advanced Message Queuing Protocol (AMQP) and allows applications to exchange data asynchronously, improving scalability, resilience, and decoupling between services.

In RabbitMQ, producers send messages to exchanges, which route them to queues based on defined rules, and consumers retrieve messages from those queues for processing. It supports various messaging patterns such as publish/subscribe, request/reply, and work queues, and includes features like message persistence, acknowledgments, and clustering for high availability.

This Application Note discusses how to use CloudCasa to properly back up and restore RabbitMQ running in containers under Kubernetes.

CloudCasa has been tested for this application note with RabbitMQ 4.0.5 clusters created using the RabbitMQ cluster-operator as well as with Bitnami Helm chart. The information herein is expected to apply to more recent versions as well and other modes of installation.

Backup

Note

CloudCasa can only back up messages in Quorum queues or messages published with “persistent” mode in durable Classic queues. See RabbitMQ Persistent Configuration for details.

Run a full cluster backup since there can be multiple cluster-scoped resources that may be required during the restore.

No application hooks need to be configured as RabbitMQ does not have support for “backup mode” and there is no way to quiesce or “freeze” the RabbitMQ cluster in Kubernetes.

See also

For more details on defining a backup, see Defining a Kubernetes backup job.

Restore

When creating the restore definition, you may select both the namespace of the RabbitMQ operator and the namespace of the RabbitMQ cluster. Make sure that you have enabled the “Include all cluster-scoped resources” switch when creating the restore definition. This will ensure that all of the CRDs for RabbitMQ are restored.

By default, RabbitMQ node name comes from the namespace where RabbitMQ server is running, so it is recommended to restore to the same namespace as original. If RabbitMQ is restored to a new namespace, node names will need to be updated and optionally passwords need to be reset as well.

One way to change the node name is to update the key cluster_formation.k8s.hostname_suffix in the secret rabbitmq-config to the new namespace name. Note that the exact steps may depend on how RabbitMQ is installed. Similarly, if you see authentication errors after restoring to a new namespace, it could be because password hashes have been written in an incompatible format. To fix it, exec into each of the node pods and run the following command:

rabbitmqctl change_password <USER> <PASSWORD>

After making above changes, it is a good idea to delete the existing RabbitMQ pods which will trigger creation of the new pods with the new configuration.

See also