The RabbitMQ Disaster Recovery Guide

HA is redundancy inside one cluster: a node fails and the remaining nodes carry the queues. DR is redundancy across clusters: a site fails and another cluster takes the workload. Quorum queues give you the first; they do nothing for the second, because a cluster does not span regions well and should not be asked to. Decide which failure you are designing for before choosing any mechanism.

Three or five nodes across independent failure domains, quorum queues for every workload that must survive a node loss, pause_minority partition handling, and classic mirrored queues retired. A DR design built on top of a cluster that still runs mirrored queues inherits their failover behaviour, which is the thing you were trying to fix.

Both move messages between clusters over AMQP and both survive link failure; they differ in what they replicate. Federation links exchanges and queues so topology is mirrored and consumers can run on either side; shovel moves messages from a source to a destination with more control and less coupling. For active-passive DR most estates want shovels from specific queues; for active-active or geo-distributed consumers, federated exchanges. Neither gives you exactly-once, so consumers must be idempotent either way.

Users, vhosts, permissions, exchanges, queues, bindings and policies export as one JSON document from the management API, and a new cluster imports it in seconds. Messages do not export that way; they are recovered by the replication in step 3 or accepted as lost within the recovery objective. Export definitions on every change and store them with the infrastructure code, so a rebuild starts from a known topology rather than from memory.

Recovery time objective decides whether the second site runs warm with shovels flowing or is rebuilt from definitions on demand. Recovery point objective decides whether in-flight messages must survive, which pushes you toward publisher confirms, durable queues and replication, or may be lost, which allows a far simpler design. Most RabbitMQ workloads tolerate a short RPO because producers retry; state the number anyway, because it is the number the rest of the design is measured against.

The Cluster Operator handles node replacement inside a cluster, but persistent volumes are zonal or regional depending on the storage class, and a region loss takes the volumes with it. A second cluster in a second region with shovel or federation remains the answer; volume snapshots are a definitions-and-data backup, not a failover. Confirm the storage class's failure domain before trusting the replica count.

A documented failover is a hypothesis. Kill a node and confirm quorum queues elect leaders and clients reconnect. Then take the primary site offline and confirm consumers on the secondary receive traffic within the recovery time objective, that definitions imported cleanly, and that the shovels or federation links resume when the primary returns. Record the elapsed time; that is your real RTO. Repeat after every topology change and at least quarterly.