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. The information herein is expected to apply to more recent versions as well.

Backup

Important: CloudCasa can only backup messages in Quorum queues or 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.

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.

Important: By default, the operator will name the RabbitMQ node using the current namespace name, so it is recommended to keep the namespace name in the restore the same as the name in the backup. Otherwise, the node name will need to be updated post-restore. See Node Names for more information.