How to back up a RabbitMQ Docker container (2026)

What Dockstash detects

Back up RabbitMQ with Dockstash, step by step

1. 01
   Create your Dockstash account and open the dashboard

   Sign up free at app.dockstash.com/register. The one-time setup wizard asks for your storage VPS (the machine that will hold the encrypted backups) and generates an encryption password — save that password in a password manager immediately, it is shown exactly once.

2. 02
   Add the Docker project that runs RabbitMQ

   On the Projects screen Dockstash auto-detects every Compose project folder on the server (by default under /var/www). Pick the project that contains your RabbitMQ service. Nothing is backed up yet — you are just telling Dockstash where the project lives.

3. 03
   Check that RabbitMQ was detected

   Open the project and look at the Plan tab. Dockstash reads docker-compose.yml, recognizes the rabbitmq image, and adds a layer that exports broker definitions — plus the container name it resolved and the env keys it found (RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST). You can toggle files, databases, and proxy configs on or off before saving.

4. 04
   Optional: sanity-check the export by hand

   If you want proof before automating, run rabbitmqctl export_definitions inside the container. It writes a JSON file describing your whole broker topology — vhosts, exchanges, queues, bindings, users, and policies. Open it and you will recognize every queue your app declares; that JSON is what gets backed up.

   docker exec <rabbitmq-container> rabbitmqctl export_definitions /tmp/definitions.json
5. 05
   Confirm your storage destination

   Backups are stored as encrypted restic snapshots on your own storage VPS over SSH. If you completed the setup wizard this is already configured; you can change host, user, port, or the SSH key any time under Settings → Storage.

6. 06
   Set a backup schedule

   On the project’s Schedule tab pick daily, weekly, or a custom cron expression (validated inline). Daily is plenty for most brokers — topology changes when you deploy, not every minute. Add a weekly prune schedule with your retention policy so old snapshots are trimmed automatically.

7. 07
   Run the first backup now

   Click Backup Now on the project card. Dockstash runs rabbitmqctl export_definitions inside the running container and restics the JSON along with your project files — you can watch the live restic output line by line in the log panel while it runs. Definitions export cleanly while the broker serves traffic; nothing is stopped or locked.

8. 08
   Confirm the snapshot exists

   When the run finishes, the project card shows the new last-backup time, snapshot count, and repository size. Open the Snapshots screen and you will see the restore point in the timeline — that is your proof the backup landed off-site.

The dump command

The restore command

exporting definitions captures the full broker topology as JSON, the durable part of RabbitMQ, while the live Mnesia message store is not point-in-time consistent under load.

Restore a RabbitMQ backup and prove it works

A RabbitMQ backup is only real once it has restored. Dockstash restores never overwrite your live broker by default — you restore to a fresh location first, verify the topology, and promote deliberately. Remember what you are restoring: the definitions JSON rebuilds your topology, not the messages that were sitting in queues.

1. 01
   Pick a restore point

   Open Snapshots, select the project, and browse the timeline of restore points. Each row contains the exported definitions JSON — the complete broker topology at that moment — plus the project files captured in the same run.

2. 02
   Restore to a new location

   Click Restore and keep the default "Restore to new location" mode. Type the project name to confirm — this is a deliberate, typed-confirm action. The definitions JSON and files land in the target path you choose, leaving the live broker untouched. Stand up a fresh RabbitMQ container and run rabbitmqctl import_definitions against it.

3. 03
   Verify the restored topology

   Run rabbitmqctl list_queues on the scratch broker: it prints each queue name with its message count. Every queue your app declares should be listed (counts will be zero — messages are not part of the backup). Check exchanges, bindings, users, and policies the same way or through the management UI.

   docker exec <rabbitmq-container> rabbitmqctl list_queues
4. 04
   Promote when satisfied

   Once the topology checks out, point your producers and consumers at the restored broker (or repeat the restore with "Overwrite existing" — an explicit opt-in). Better: let the weekly restore drill do this proof automatically so a restore is never your first rehearsal.

Gotchas to avoid

• Back up broker definitions (topology) via export_definitions — this is the durable, restorable part of RabbitMQ.
• The Mnesia message store holds in-flight messages and is not safe to copy live; treat persisted messages as transient and rely on producers/consumers to recover.
• Restoring definitions recreates topology but not the messages that were in queues at backup time.

Common RabbitMQ backup problems

Do it in one click with Dockstash

Dockstash runs the exact dump above, restics it off-site, and drill-tests the restore automatically — no script to maintain.

Last updated: July 2026

Related