Cómo respaldar un contenedor Docker de MongoDB (2026)
Respaldar MongoDB con seguridad se resume en una regla: volcar, no copiar. `mongodump --archive --oplog` produce un volcado consistente y restaurable desde el contenedor en ejecución, que restic cifra después fuera del servidor. --oplog registra las operaciones durante el volcado para que mongorestore --oplogReplay reconstruya una instantánea consistente a un instante preciso. Todo lo que copie /data/db en caliente arriesga un respaldo irrecuperable.
Qué detecta Dockstash
| Claves de entorno detectadas | MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE |
|---|---|
| Puerto por defecto | 27017 |
| Rutas de datos vivas (nunca copiadas en caliente) | /data/db |
| Imágenes de ejemplo | mongo:7, mongo:6, mongo:5, mongo |
Respalda MongoDB 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 MongoDB
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 MongoDB. Aún no se respalda nada — solo le indicas a Dockstash dónde vive el proyecto.
Comprueba que MongoDB fue detectado
Abre el proyecto y mira la pestaña Plan. Dockstash lee docker-compose.yml, reconoce la imagen mongo y añade una capa de base de datos con el comando de volcado correcto — más el nombre del contenedor resuelto y las claves encontradas (MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE). Puedes activar o desactivar archivos, bases y configuraciones de proxy antes de guardar.
Opcional: comprueba el volcado a mano
Si quieres una prueba antes de automatizar, ejecuta el mismo volcado que ejecutará Dockstash — mongodump escribiendo un archivo único a stdout, redirigido a un contador de bytes. Un total de bytes grande y distinto de cero prueba que el archivo fluye limpio. Ese archivo es lo que se respalda, nunca el directorio vivo /data/db.
docker exec <mongo-container> sh -c 'mongodump --archive --oplog' | wc -cConfirma 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 a una hora tranquila es el valor por defecto correcto para la mayoría de proyectos MongoDB. Añade un prune semanal con tu política de retención.
Ejecuta el primer respaldo ahora
Haz clic en Backup Now en la tarjeta del proyecto. Dockstash ejecuta mongodump con --archive y --oplog dentro del contenedor y envía el archivo directamente a restic — sigue la salida en vivo en el panel de logs.
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
mongodump --archive --oplogEl comando de restauración
mongorestore --archive --oplogReplay --drop--oplog registra las operaciones durante el volcado para que mongorestore --oplogReplay reconstruya una instantánea consistente a un instante preciso.
Restaura un respaldo de MongoDB y prueba que funciona
Un respaldo de MongoDB solo es real una vez restaurado. Las restauraciones de Dockstash nunca sobrescriben tu base viva por defecto — primero restauras a un staging nuevo, reproduces allí el archivo, verificas los datos y promocionas deliberadamente.
Elige un punto de restauración
Abre Snapshots, selecciona el proyecto y recorre la línea de tiempo. Cada fila es un archivo mongodump completo — todas las bases y colecciones, más las entradas de oplog capturadas durante el volcado — junto a 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 los datos restaurados
En el contenedor de prueba, lista las bases con mongosh, confirma que cada una volvió y sondea las colecciones de tu aplicación. Recuentos de documentos y registros recientes son la prueba más rápida.
docker exec <mongo-container> mongosh --quiet --eval "db.adminCommand({ listDatabases: 1 })"Promociona 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
- Nunca ejecutes restic sobre los archivos WiredTiger vivos de /data/db — copiados a mitad de checkpoint son inconsistentes y a menudo irrecuperables.
- --oplog exige que el servidor sea miembro de un replica set (aunque sea de un solo nodo); en un mongod standalone es un no-op sin garantía point-in-time.
- Al restaurar, --oplogReplay debe acompañar a los volcados con --oplog o se pierde la consistencia point-in-time.
Problemas comunes al respaldar MongoDB
- Síntoma
- El volcado falla con « --oplog mode only supported on replica set members » (o similar).
- Causa
- Tu mongod corre en standalone. --oplog necesita un oplog que leer, y solo los miembros de un replica set lo mantienen — en un servidor standalone no hay nada que capturar.
- Solución
- Convierte a replica set de un solo nodo: arranca mongod con --replSet rs0 y ejecuta rs.initiate() una vez. Mismo contenedor, mismos datos, y ganas la garantía point-in-time.
- Síntoma
- mongodump falla con « Authentication failed » aunque compose define MONGO_INITDB_ROOT_USERNAME.
- Causa
- Las variables MONGO_INITDB_* solo crean el usuario en la primera inicialización de un volumen /data/db vacío. Si el volumen ya existía, o las credenciales cambiaron después, los valores del compose ya no reflejan la realidad.
- Solución
- Autentícate con las credenciales que realmente existen en la base (compruébalo con mongosh), o recrea el usuario, y alinea después el env del compose.
- Síntoma
- mongorestore en un contenedor de prueba falla con un error de versión no soportada o de archivo inválido.
- Causa
- El archivo viene de un servidor o mongodump más nuevo de lo que entiende el destino — restaurar un archivo de mongo:7 en mongo:5 no está soportado.
- Solución
- Restaura en la misma versión mayor del volcado (por ejemplo mongo:7) y mantén mongodump/mongorestore de la misma versión de Database Tools. Subir de versión lo hace el servidor tras la restauración, no mongorestore.
- Síntoma
- Una ejecución de respaldo falla con un candado restic obsoleto tras un fallo o reinicio.
- Causa
- Un job anterior murió a mitad de ejecución y dejó el repositorio bloqueado.
- Solución
- No hay nada que hacer a mano: la siguiente ejecución detecta el candado huérfano y ejecuta restic unlock automáticamente antes de continuar. Si las ejecuciones siguen fallando, revisa el panel de logs en vivo para ver el error de fondo.
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é hace --oplog exactamente?
Registra las entradas del log de operaciones producidas mientras corre mongodump y las guarda en el archivo. Al restaurar, --oplogReplay las aplica para que el volcado refleje un único instante consistente en lugar de un difuminado sobre la ventana del volcado.
¿Necesito un replica set para respaldos consistentes?
Para consistencia point-in-time, sí — --oplog solo funciona en un miembro de replica set. Muchos despliegues de un solo nodo corren como replica set de un miembro precisamente por esta garantía.
¿Por qué no copiar /data/db directamente?
WiredTiger escribe checkpoints continuamente. Una copia de archivos a mitad de checkpoint captura un estado inconsistente que con frecuencia no arranca. mongodump lee una instantánea lógica y restaurable.
¿Cómo restauro en una base limpia?
mongorestore --archive --oplogReplay --drop elimina las colecciones existentes antes de restaurar para no mezclar datos viejos y nuevos. Dockstash restaura primero a un destino de staging por defecto.
¿Con qué frecuencia debo respaldar MongoDB?
Diario es el valor por defecto práctico para la mayoría de proyectos; cada hora si perder un día de escrituras es inaceptable. En el plan Free los respaldos son solo manuales; Pro permite programaciones hasta cada hora, Business cualquier cron. Combina la programación con un simulacro de restauración semanal.
¿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.