Al implementar MongoDB en producción, debes tener una estrategia para la captura y restauración de copias de seguridad en caso de eventos de pérdida de datos.
Esta página cubre los métodos de respaldo para Implementaciones autogestionadas.
Para obtener más información sobre los métodos de copia de seguridad para las implementaciones alojadas en MongoDB Atlas, consulta Copia de seguridad, restauración y archivo de datos.
Realice una copia de seguridad con MongoDB Cloud Manager o Ops Manager
MongoDB Cloud Manager es un servicio alojado de copia de seguridad, supervisión y automatización para MongoDB. MongoDB Cloud Manager es compatible con la copia de seguridad y restauración de Sets de réplicas de MongoDB y clústeres fragmentados desde una interfaz gráfica de usuario.
MongoDB Cloud Manager
Importante
Para realizar copias de seguridad de tus Sets de réplicas y clústeres particionados con MongoDB Cloud Manager, debes estar utilizando MongoDB Enterprise Server. Para obtener más información, consulta Instalación de MongoDB Enterprise.
El MongoDB Cloud Manager es compatible con la realización de copias de seguridad y Restauraciones de las implementaciones de MongoDB.
MongoDB Cloud Manager realiza copias de seguridad continuas de los sets de réplicas y clústeres fragmentados de MongoDB leyendo los datos del oplog de su implementación de MongoDB. MongoDB Cloud Manager crea snapshots de sus datos a intervalos establecidos y también puede ofrecer recuperación a un punto en el tiempo de los Set de réplicas de MongoDB y los clústeres fragmentados.
Tip
Las snapshots de clústeres fragmentados son difíciles de lograr con otros métodos de copia de seguridad de MongoDB.
Para comenzar con la copia de seguridad de MongoDB Cloud Manager, regístrate en MongoDB Cloud Manager. Para ver la documentación sobre MongoDB Cloud Manager, consulta la documentación de MongoDB Cloud Manager.
Gerente de Operaciones
Con Ops Manager, los suscriptores de MongoDB pueden instalar y ejecutar el mismo software central que impulsa MongoDB Cloud Manager en su propia infraestructura. Ops Manager es una solución on-premises que tiene una funcionalidad similar a la de MongoDB Cloud Manager y está disponible con suscripciones de Enterprise Advanced.
Para obtener más información sobre Ops Manager, consulta la página de MongoDB Enterprise Advanced y el Manual de Ops Manager.
Haz una copia de seguridad copiando los archivos de datos subyacentes
Nota
Consideraciones para motores de almacenamiento cifrados que utilizan AES256-GCM
Para motores de almacenamiento cifrado que utilizan AES256-GCM modo de cifrado, AES256-GCM requiere que cada proceso utilice un valor de bloque de contador único con la clave.
Para el motor de almacenamiento cifrado configurado con el cifrado AES256-GCM:
- Restauración desde una copia de seguridad en caliente
- A partir de la versión 4.2, si restaura desde archivos obtenidos mediante una copia de seguridad "en caliente" (es decir, mientras
mongodestá en ejecución), MongoDB puede detectar claves "sucias" en el inicio y cambiar automáticamente la clave de la base de datos para evitar la reutilización del IV (vector de inicialización).
- Restauración desde una copia de seguridad en frío
Sin embargo, si restaura desde archivos obtenidos mediante una copia de seguridad "en frío" (es decir,
mongodno está en ejecución), MongoDB no puede detectar las claves "sucias" en el inicio, y la reutilización de IV invalida las garantías de confidencialidad e integridad.A partir de la versión 4.2, para evitar la reutilización de las claves después de restaurar desde un snapshot del sistema de archivos en frío, MongoDB agrega una nueva opción de línea de comandos
--eseDatabaseKeyRollover. Al iniciarse con la opción--eseDatabaseKeyRollover, la instanciamongodcambia las claves de la base de datos configuradas con el cifradoAES256-GCMy se cierra.
En general, si utilizas copias de seguridad basadas en el sistema de archivos para MongoDB Enterprise, usa la característica de copia de seguridad "en caliente", si es posible.
Hacer copias de seguridad con snapshots del sistema de archivos
Puedes crear una copia de seguridad de una implementación de MongoDB haciendo una copia de los archivos de datos subyacentes de MongoDB.
Si el volumen donde MongoDB almacena sus archivos de datos admite instantáneas puntuales, puede usarlas para crear copias de seguridad de un sistema MongoDB en un momento preciso. Las instantáneas del sistema de archivos son una función del administrador de volúmenes del sistema operativo y no son específicas de MongoDB. Con ellas, el sistema operativo toma una instantánea del volumen para usarla como referencia para la copia de seguridad de los datos. La mecánica de las instantáneas depende del sistema de almacenamiento subyacente. Por ejemplo, en Linux, el Administrador de Volúmenes Lógicos (LVM) puede crear instantáneas. De igual forma, el sistema de almacenamiento EBS de Amazon para EC2 admite instantáneas.
Para obtener una snapshot correcta de un proceso mongod en ejecución, debes tener activado el registro en la bitácora y el diario debe residir en el mismo volumen lógico que los demás archivos de datos de MongoDB. Sin el registro en la bitácora activado, no hay garantía de que la snapshot sea coherente o válida.
Para obtener un snapshot coherente de un clúster particionado, debes desactivar el balanceador y capturar un snapshot de cada partición, así como de un servidor de configuración aproximadamente al mismo tiempo. Para realizar copias de seguridad de clústeres particionados, consulta Hacer una copia de seguridad de un clúster particionado autogestionado con un vaciado de base de datos.
Para obtener más información, consulte Realizar copias de seguridad y restaurar una implementación autoadministrada con instantáneas del sistema de archivos y Realizar copias de seguridad de un clúster fragmentado autoadministrado con instantáneas del sistema de archivos para obtener instrucciones completas sobre el uso de LVM para crear instantáneas.
Realizar una copia de seguridad con cp o rsync
Si el sistema de almacenamiento no es compatible con snapshots, se pueden copiar los archivos directamente usando cp, rsync o una herramienta similar. Dado que la copia de varios archivos no es una operación atómica, se debe detener todas las escrituras en el mongod antes de copiar los archivos. De lo contrario, se copiarán los archivos en un estado inválido.
Las copias de seguridad producidas al copiar los datos subyacentes no permiten la recuperación a un punto en el tiempo para Sets de réplicas y son difíciles de gestionar para clústeres fragmentados más grandes. Además, estas copias de seguridad son más grandes porque incluyen los índices y duplican el relleno y la fragmentación del almacenamiento subyacente. mongodump, por el contrario, crea copias de seguridad más pequeñas.
Haz una copia de seguridad con mongodump
mongodump lee datos de una base de datos MongoDB y crea archivos BSON de alta fidelidad que la herramienta mongorestore puede utilizar para poblar una base de datos MongoDB. mongodump y mongorestore son herramientas simples y eficientes para realizar copias de seguridad y restaurar implementaciones pequeñas de MongoDB, pero no son ideales para realizar copias de seguridad de sistemas más grandes.
mongodump y mongorestore operan contra un proceso mongod en ejecución y pueden manipular directamente los archivos de datos subyacentes. Por defecto, mongodump no captura el contenido de la base de datos local.
mongodump solo captura los documentos en la base de datos. La copia de seguridad resultante es eficiente en cuanto a espacio, pero mongorestore o mongod deben reconstruir los índices después de restaurar los datos.
Al conectarse a una instancia de MongoDB, mongodump puede afectar negativamente el rendimiento de mongod. Si tus datos son más grandes que la memoria del sistema, los queries expulsarán el conjunto de trabajo de la memoria, lo que causará fallos de página.
Las aplicaciones pueden seguir modificando datos mientras mongodump captura el resultado. Para los Sets de réplicas, mongodump proporciona la --oplog opción de incluir en su salida las entradas de oplog que ocurren durante la operación de mongodump. Esto permite que la operación correspondiente mongorestore reproduzca el oplog capturado. Para restaurar una copia de seguridad creada con --oplog, utiliza mongorestore con la opción --oplogReplay.
Sin embargo, para sets de réplicas, considera MongoDB Cloud Manager o Ops Manager.
Para realizar una copia de seguridad de clústeres particionados, consulta Hacer una copia de seguridad de un clúster particionado autogestionado con un volcado de base de datos.
Nota
Para utilizar mongodump y mongorestore como estrategia de respaldo para clústeres particionados, consulte Realizar una copia de seguridad de un clúster particionado autogestionado con un vaciado de base de datos.
Los clústeres particionados también pueden utilizar uno de los siguientes procesos coordinados de copia de seguridad y restauración, que mantienen las garantías de atomicidad de las transacciones entre particiones:
Consulta Cómo hacer una copia de seguridad y restauración de una implementación autogestionada con herramientas de MongoDB y Realizar copias de seguridad de un clúster autogestionado con un volcado de base de datos para obtener más información.