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.
This page covers backup methods for self-managed deployments.
To learn more about Backup Methods for deployments hosted in MongoDB Atlas, see Back Up, Restore, and Archive Data.
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 es compatible con snapshots en un punto determinado en el tiempo, puedes utilizar estas snapshots para crear copias de seguridad de un sistema MongoDB en un momento exacto. Las snapshots del sistema de archivos son una característica del administrador de volúmenes del sistema operativo y no son específicas de MongoDB. Con las snapshots del sistema de archivos, el sistema operativo toma una snapshot del volumen para usarla como referencia para la copia de seguridad de datos. La mecánica de las snapshots depende del sistema de almacenamiento subyacente. Por ejemplo, en Linux, el Logical Volume Manager (LVM) puede crear snapshots. De manera similar, el sistema de almacenamiento EBS de Amazon para EC2 es compatible con snapshots.
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, consulta Hacer copia de seguridad de una implementación autogestionada con snapshots del sistema de archivos y Hacer copia de seguridad de un clúster autogestionado con snapshots del sistema de archivos para obtener instrucciones completas sobre el uso de LVM para crear snapshots.
Back Up with cp or 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.
Comparar métodos de copia de seguridad
La siguiente tabla compara los métodos de copia de seguridad para implementaciones on-premises. Puedes usarlo como orientación para desarrollar tus propios enfoques de protección de datos.
Consideraciones sobre copias de seguridad | Cloud Manager/Ops Manager | snapshot del sistema de archivos | |
|---|---|---|---|
Backup RTO | Bajo/depende del tipo de almacenamiento de snapshot | Bajo | Alto |
RPOde copia de seguridad | Bajo | Alto | Alto |
Costo de almacenamiento de copia de seguridad | Bajo/depende del tipo de almacenamiento de snapshot | Intermedio | Alto |
Tiempo del personal para gestionar las copias de seguridad | Ninguno/depende del tipo de almacenamiento de snapshot | Alto | Alto |
Copia de seguridad y restauración continuas hasta un punto en el tiempo. | Sí | No | No |
Complejidad de la restauración | Baja si la implementación está bajo automatización | Alto para un clúster particionado | Bajo |
Complejidad de la copia de seguridad de un clúster con particiones. | Bajo | Alto, requiere pasos extra | Alto, requiere pasos extra |
Impacto de la copia de seguridad en la implementación del clúster particionado de origen | Bajo | Alto, requiere un bloqueo de escritura | Alto, requiere un bloqueo de escritura |
Coherencia en la copia de seguridad del clúster particionado | Garantizado | No está garantizado, utiliza | No está garantizado, utiliza |
Copia de seguridad incremental | Sí, copias de seguridad incrementales diarias y copias de seguridad completas semanales | Depende del almacenamiento y de la herramienta | No |
Defina el alcance de las copias de seguridad | Sí, con filtro de namespace | No | Sí |