Cuando implementes MongoDB en producción, ten una estrategia de copia de seguridad y restauración para protegerte contra la pérdida de datos.
Esta página cubre los métodos de copia de seguridad para autogestionado deployments.
Para obtener más información sobre métodos de copia de seguridad para implementaciones alojadas en MongoDB Atlas, consulta Respaldar, restaurar y archivar datos.
Realice una copia de seguridad con MongoDB Cloud Manager o Ops Manager
MongoDB Cloud Manager es un servicio de copia de seguridad, supervisión y automatización alojado para MongoDB. MongoDB Cloud Manager admite la copia de seguridad y restauración de sets de réplicas y clústeres 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.
MongoDB Cloud Manager realiza copias de seguridad de sets de réplicas y clústeres leyendo datos de oplog de tu implementación de MongoDB. MongoDB Cloud Manager crea instantáneas en intervalos definidos y ofrece recuperación puntual.
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 de copia de seguridad que MongoDB Cloud Manager en su propia infraestructura. Ops Manager está disponible con suscripciones 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 cifrados que usan AES256-GCM El modo de cifrado, AES256-GCM requiere que cada proceso use un valor único de bloque contador con la clave.
Para el motor de almacenamiento cifrado configurado con el cifrado AES256-GCM:
- Restauración desde una copia de seguridad en caliente
- Si restauras desde archivos tomados a través de una copia de seguridad en caliente mientras el
mongodse está ejecutando, MongoDB detecta claves "sucias" al arrancar y rota automáticamente la clave de la base de datos para evitar la reutilización de IV (Initialization Vector).
- Restauración desde una copia de seguridad en frío
Sin embargo, si se restaura desde archivos obtenidos mediante una copia de seguridad "en frío" mientras
mongodno se está ejecutando, MongoDB no detecta claves "sucias" al iniciarse, y la reutilización del IV anula las garantías de confidencialidad e integridad.Para evitar la reutilización de las claves después de restaurar desde una snapshot fría del sistema de archivos, MongoDB añade 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 sale.
Si utilizas copias de seguridad basadas en el sistema de archivos para MongoDB Enterprise, utiliza la funcionalidad de copia de seguridad "en caliente".
Hacer copias de seguridad con snapshots del sistema de archivos
Si el volumen donde MongoDB almacena sus archivos de datos admite instantáneas puntuales, utiliza esas instantáneas para crear copias de seguridad en un momento exacto. Las instantáneas del sistema de archivos son una funcionalidad del gestor de volúmenes del sistema operativo y no son específicas de MongoDB. El sistema operativo toma una snapshot del volumen para utilizarla como referencia para la copia de seguridad. La mecánica de los snapshots depende del sistema de almacenamiento subyacente. Por ejemplo, en Linux, el Logical Volume Manager (LVM) puede crear instantáneas. Del mismo modo, el sistema de almacenamiento de EBS de Amazon para EC2 admite snapshot.
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.
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.
Realiza 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.
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 y mongorestore son herramientas para respaldar y restaurar implementaciones pequeñas de MongoDB. Para aprender más información, consulta Realizar copias de seguridad y restaurar una implementación autogestionada con las herramientas de MongoDB.
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.
Comparar métodos de copia de seguridad
La siguiente tabla compara los métodos de copia de seguridad para implementaciones on-premises.
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í |