We recently covered the installation of RabbitMQ on CentOS 7, CentOS 6, Fedora and Ubuntu. You can find the links for the guides below:
- Installing RabbitMQ on CentOS 7 / Fedora
- How to install Latest RabbitMQ Server on Ubuntu
- Installing RabbitMQ on CentOS 6 and CentOS 7
In this post, I’ll like us to look at how to perform a backup for RabbitMQ configurations and data. This will also include information on restoring a RabbitMQ backup into a new deployment.
Get Cluster Status
$ rabbitmqctl cluster_status
Cluster status of node rabbit@neveropen-centos7 ...
[{nodes,[{disc,['rabbit@neveropen-centos7']}]},
{running_nodes,['rabbit@neveropen-centos7']},
{cluster_name,<<"rabbit@neveropen-centos7">>},
{partitions,[]},
{alarms,[{'rabbit@neveropen-centos7',[]}]}]
How to Backup RabbitMQ Configurations
Please note this backup doesn’t include Messages since they are stored in a separate message store. It will only backup RabbitMQ users, vhosts, queues, exchanges, and bindings. The backup file is a JSON representation of RabbitMQ metadata. We will do a backup using rabbitmqadmincommand line tool.
The management plugin ships with a command line tool rabbitmqadmin. You need to enable the management plugin:
rabbitmq-plugins enable rabbitmq_management
This plugin is used to perform some of the same actions as the Web-based UI, and which may be more convenient for automation tasks.
Download rabbitmqadmin
Once you enable the management plugin, download rabbitmqadmin Python command line tool that interacts with the HTTP API. It can be downloaded from any RabbitMQ node that has the management plugin enabled at
http://nodeio_or_hostname:15672/cli/
Once downloaded, make the file executable and move it to /usr/local/bin directory:
chmod +x rabbitmqadmin sudo mv rabbitmqadmin /usr/local/bin
To backup RabbitMQ configurations, use the command:
rabbitmqadmin export <backup-file-name>
Example:
$ rabbitmqadmin export rabbitmq-backup-config.json Exported definitions for localhost to "rabbitmq-backup-config.json"
The export will be written to filerabbitmq-backup-config.json.
Restore RabbitMQ Configurations backup
If you ever want to restore your RabbitMQ configurations from a backup, use the command:
rabbitmqadmin import <JSON backup file >
Example
$ rabbitmqadmin import rabbitmq-backup.json Imported definitions for localhost from "rabbitmq-backup.json"
How to Backup RabbitMQ Data
RabbitMQ Definitions and Messages are stored in an internal database located in the node’s data directory. To get the directory path, run the following command against a running RabbitMQ node:
rabbitmqctl eval 'rabbit_mnesia:dir().'
Sample output:
"/var/lib/rabbitmq/mnesia/rabbit@neveropen-server1"
This directory contains many files:
# ls /var/lib/rabbitmq/mnesia/rabbit@neveropen-centos7 cluster_nodes.config nodes_running_at_shutdown rabbit_durable_route.DCD rabbit_user.DCD schema.DAT DECISION_TAB.LOG rabbit_durable_exchange.DCD rabbit_runtime_parameters.DCD rabbit_user_permission.DCD schema_version LATEST.LOG rabbit_durable_exchange.DCL rabbit_serial rabbit_vhost.DCD msg_stores rabbit_durable_queue.DCD rabbit_topic_permission.DCD rabbit_vhost.DCL
In RabbitMQ versions starting with 3.7.0 all messages data is combined in the msg_stores/vhosts directory and stored in a subdirectory per vhost. Each vhost directory is named with a hash and contains a .vhost file with the vhost name, so a specific vhost’s message set can be backed up separately.
To do RabbitMQ definitions and messages data backup, copy or archive this directory and its contents. But first, you need to stop RabbitMQ service
sudo systemctl stop rabbitmq-server.service
The example below will create an archive:
tar cvf rabbitmq-backup.tgz /var/lib/rabbitmq/mnesia/rabbit@neveropen-centos7
How to Restore RabbitMQ Data
To restore from Backup, extract the files from backup to the data directory.
Internal node database stores node’s name in certain records. Should node name change, the database must first be updated to reflect the change using the following rabbitmqctl command:
rabbitmqctl rename_cluster_node <oldnode> <newnode>
When a new node starts with a backed up directory and a matching node name, it should perform the upgrade steps as needed and proceed to boot.
