Cómo respaldar un contenedor Docker de RabbitMQ (2026)
Respaldar RabbitMQ con seguridad se resume en una regla: volcar, no copiar. `rabbitmqctl export_definitions /tmp/definitions.json` produce un volcado consistente y restaurable desde el contenedor en ejecución, que restic cifra después fuera del servidor. exportar las definiciones captura toda la topología del broker como JSON — la parte duradera de RabbitMQ — mientras que el almacén de mensajes Mnesia no es consistente a un instante preciso bajo carga. Todo lo que copie /var/lib/rabbitmq/mnesia en caliente arriesga un respaldo irrecuperable.
Qué detecta Dockstash
| Claves de entorno detectadas | RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST |
|---|---|
| Puerto por defecto | 5672 |
| Rutas de datos vivas (nunca copiadas en caliente) | /var/lib/rabbitmq/mnesia |
| Imágenes de ejemplo | rabbitmq:3.13-management, rabbitmq:3-management, rabbitmq |
Respalda RabbitMQ con Dockstash, paso a paso
Crea tu cuenta de Dockstash y abre el panel
Regístrate gratis en app.dockstash.com/register. El asistente de configuración único te pide tu VPS de almacenamiento (la máquina que guardará los respaldos cifrados) y genera una contraseña de cifrado — guárdala de inmediato en un gestor de contraseñas: se muestra exactamente una vez.
Añade el proyecto Docker que ejecuta RabbitMQ
En la pantalla Projects, Dockstash detecta automáticamente cada carpeta de proyecto Compose del servidor (por defecto bajo /var/www). Elige el proyecto que contiene tu servicio RabbitMQ. Aún no se respalda nada — solo le indicas a Dockstash dónde vive el proyecto.
Comprueba que RabbitMQ fue detectado
Abre el proyecto y mira la pestaña Plan. Dockstash lee docker-compose.yml, reconoce la imagen rabbitmq y añade una capa que exporta las definiciones del broker — más el nombre del contenedor resuelto y las claves encontradas (RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST). Puedes activar o desactivar archivos, bases y configuraciones de proxy antes de guardar.
Opcional: comprueba la exportación a mano
Si quieres una prueba antes de automatizar, ejecuta rabbitmqctl export_definitions en el contenedor. Escribe un JSON con toda la topología del broker — vhosts, exchanges, colas, bindings, usuarios y policies. Ábrelo: reconocerás cada cola que declara tu app; ese JSON es lo que se respalda.
docker exec <rabbitmq-container> rabbitmqctl export_definitions /tmp/definitions.jsonConfirma tu destino de almacenamiento
Los respaldos se guardan como instantáneas restic cifradas en tu propio VPS de almacenamiento, vía SSH. Si completaste el asistente, ya está configurado; puedes cambiar host, usuario, puerto o la clave SSH en cualquier momento en Settings → Storage.
Define una programación de respaldo
En la pestaña Schedule elige diario, semanal o una expresión cron personalizada (validada al escribir). Diario sobra para la mayoría de brokers — la topología cambia al desplegar, no cada minuto. Añade un prune semanal con tu retención.
Ejecuta el primer respaldo ahora
Haz clic en Backup Now. Dockstash ejecuta rabbitmqctl export_definitions en el contenedor en marcha y entrega el JSON a restic junto con los archivos del proyecto — sigue la salida en vivo en el panel de logs. Las definiciones se exportan limpias mientras el broker sirve tráfico; nada se para ni se bloquea.
Confirma que la instantánea existe
Al terminar la ejecución, la tarjeta del proyecto muestra la nueva hora del último respaldo, el número de instantáneas y el tamaño del repositorio. Abre la pantalla Snapshots: el punto de restauración aparece en la línea de tiempo — tu prueba de que el respaldo llegó fuera del servidor.
El comando de volcado
rabbitmqctl export_definitions /tmp/definitions.jsonEl comando de restauración
rabbitmqctl import_definitions /tmp/definitions.jsonexportar las definiciones captura toda la topología del broker como JSON — la parte duradera de RabbitMQ — mientras que el almacén de mensajes Mnesia no es consistente a un instante preciso bajo carga.
Restaura un respaldo de RabbitMQ y prueba que funciona
Un respaldo de RabbitMQ solo es real una vez restaurado. Las restauraciones de Dockstash nunca sobrescriben tu broker vivo por defecto — primero restauras a una ubicación nueva, verificas la topología y promocionas deliberadamente. Recuerda qué restauras: el JSON de definiciones reconstruye la topología, no los mensajes que esperaban en las colas.
Elige un punto de restauración
Abre Snapshots, selecciona el proyecto y recorre la línea de tiempo. Cada fila contiene el JSON de definiciones exportado — la topología completa del broker en ese momento — más los archivos del proyecto de la misma ejecución.
Restaura a una nueva ubicación
Haz clic en Restore y mantén el modo por defecto « Restore to new location ». Escribe el nombre del proyecto para confirmar — una acción deliberada con confirmación tecleada. El volcado y los archivos aterrizan en la ruta de destino que elijas, sin tocar el proyecto vivo.
Verifica la topología restaurada
Ejecuta rabbitmqctl list_queues en el broker de prueba: imprime cada nombre de cola con su recuento de mensajes. Cada cola que declara tu app debe aparecer (los recuentos serán cero — los mensajes no forman parte del respaldo). Verifica exchanges, bindings, usuarios y policies igual o por la UI de management.
docker exec <rabbitmq-container> rabbitmqctl list_queuesPromociona cuando estés conforme
Cuando los datos restaurados estén validados, apunta tu aplicación a ellos (o repite la restauración en modo « Overwrite existing » — un opt-in explícito). Mejor aún: deja que el simulacro de restauración semanal produzca esta prueba automáticamente, para que una restauración nunca sea tu primer ensayo.
Trampas a evitar
- Respalda las definiciones del broker (topología) vía export_definitions — es la parte duradera y restaurable de RabbitMQ.
- El almacén de mensajes Mnesia guarda mensajes en vuelo y no es seguro copiarlo en caliente; trata los mensajes persistidos como transitorios y confía en productores/consumidores para recuperar.
- Restaurar las definiciones recrea la topología pero no los mensajes que estaban en las colas al momento del respaldo.
Problemas comunes al respaldar RabbitMQ
- Síntoma
- La restauración « funcionó » pero todas las colas están vacías.
- Causa
- Definiciones y mensajes son cosas distintas. export_definitions captura la topología — vhosts, exchanges, colas, bindings, usuarios, policies —, nunca los cuerpos de mensajes encolados al momento del respaldo.
- Solución
- Es lo esperado. Trata los mensajes encolados como transitorios: productores que republiquen y consumidores que toleren el replay. Un mensaje que deba sobrevivir a la pérdida del broker se persiste en una base de datos, no en una cola.
- Síntoma
- Un broker arrancado desde una copia del directorio /var/lib/rabbitmq/mnesia se cae o no arranca.
- Causa
- Mnesia se escribe continuamente mientras el broker corre: una copia en caliente es internamente inconsistente — y el almacén está además ligado al nombre del nodo, así que rompe en un host con otro hostname.
- Solución
- No copies Mnesia como respaldo. Exporta las definiciones e impórtalas en un broker nuevo; esa es la vía soportada y restaurable.
- Síntoma
- import_definitions en un broker en marcha da error o deja una mezcla de topología vieja y nueva.
- Causa
- La importación fusiona con lo existente — argumentos de colas en conflicto, usuarios ya presentes o policies chocan con las entradas del JSON en lugar de reemplazarlas.
- Solución
- Importa en un broker nuevo siempre que puedas. Si debe ser el broker en marcha: espera una fusión, no un reinicio — borra antes las entidades en conflicto y verifica el resultado con rabbitmqctl list_queues y la UI de management.
Hazlo en un clic con Dockstash
Dockstash ejecuta exactamente el volcado de arriba, lo entrega a restic fuera del servidor y prueba la restauración con un simulacro automáticamente — sin script que mantener.
Última actualización: July 2026
Preguntas frecuentes
¿Qué parte de RabbitMQ debo respaldar?
Las definiciones: vhosts, exchanges, colas, bindings, usuarios y policies. Exportarlas como JSON captura toda la topología del broker — lo que de verdad necesitas para reconstruir tras una pérdida.
¿Puedo respaldar los mensajes que esperan en las colas?
No de forma fiable con el broker en marcha. El almacén Mnesia no es consistente a instante preciso bajo carga, y los mensajes están pensados como transitorios. Diseña consumidores que toleren el replay en lugar de confiar en un respaldo de mensajes.
¿Cómo restauro un broker RabbitMQ?
Levanta un broker nuevo y ejecuta rabbitmqctl import_definitions con tu JSON exportado. Se recrea la topología completa — exchanges, colas, bindings, usuarios, policies.
¿Copiar /var/lib/rabbitmq/mnesia es un respaldo válido?
No. Mnesia se escribe continuamente y una copia en caliente es inconsistente. Exporta las definiciones en su lugar; esa es la vía de respaldo soportada y restaurable.
¿Con qué frecuencia debo respaldar RabbitMQ?
Diario sobra para la mayoría de brokers — las definiciones solo cambian al desplegar nuevas colas, usuarios o policies. En Free los respaldos son manuales (Backup Now); Pro desbloquea hasta cada hora, Business cualquier cron.
¿Dónde viven realmente los respaldos?
En tu propio VPS de almacenamiento, como instantáneas restic cifradas enviadas por SSH. Dockstash nunca guarda tus datos en una nube de terceros — lo apuntas a una máquina que controlas, y el repositorio está cifrado con una contraseña que solo tú tienes.
¿Cómo sé que el respaldo es restaurable sin hacer una restauración manual?
Programa un simulacro de restauración. Dockstash restaura la última instantánea en un espacio de trabajo aislado, compara cada archivo byte a byte con la fuente y verifica el volcado restaurado — luego estampa una insignia de éxito/fallo en el proyecto. Un simulacro semanal significa prueba siempre fresca.