Chat with us, powered by LiveChat
Solicitar precios
WW +41 21 641 6080 | US +1 800 256 0192 | CA +1 800 935 0725 | FR +33 261 880008 | UK +44 808 1890445
Contacto
Inicio > Software de backup corporativos > Herramientas de copia de seguridad de datos para empresas > Solución de copia de seguridad de MongoDB de nivel empresarial para implementaciones a gran escala

Solución de copia de seguridad de MongoDB de nivel empresarial para implementaciones a gran escala

Realizar copias de seguridad y restauraciones granulares de MongoDB en servidores, conjuntos de réplicas y clústeres fragmentados

Las bases de datos NoSQL como MongoDB pueden gestionar enormes cantidades de tráfico y datos gracias a un diseño escalable que las convierte en una solución inestimable para las empresas que gestionan millones de usuarios simultáneos.

Dicho esto, realizar una copia de seguridad de un clúster NoSQL plantea, por sí mismo, una serie de retos relacionados con la consistencia de los datos que las soluciones de copia de seguridad tradicionales no logran superar, ya que copiar los archivos sin procesar de la base de datos mientras el servidor está en funcionamiento puede generar un archivo inconsistente o imposible de restaurar, debido a que los archivos pueden cambiar entre una lectura y otra

El complemento de copia de seguridad y restauración de MongoDB de Bacula Enterprise se integra directamente con el motor de MongoDB y automatiza las copias de seguridad lógicas de una base de datos en funcionamiento, tanto para servidores independientes como para conjuntos de réplicas, sin interrumpir las operaciones de escritura. Sin embargo, en el caso de los clústeres fragmentados, primero es necesario cumplir varios requisitos previos para automatizar la copia de seguridad lógica.

Además, la arquitectura aislada de cinco módulos de Bacula limita el alcance de los daños en caso de que se produzca una brecha de seguridad en la base de datos de MongoDB y proporciona una rápida recuperación cuando la arquitectura se combina con la segmentación de la red, credenciales únicas y TLS mutuo.

Descargar versión de prueba

Principales ventajas de la solución de copia de seguridad y restauración de MongoDB

  • Copias de seguridad consistentes de bases de datos MongoDB activas – El complemento de MongoDB de Bacula evita los artefactos inconsistentes que genera la copia directa de archivos al utilizar directamente la propia herramienta mongodump de MongoDB. En el caso de los servidores independientes, esto genera una instantánea lógica del contenido de la base de datos. Y en el caso de los conjuntos de réplicas, el complemento genera una cadena de recuperación totalmente consistente al añadir metadatos del oplog al volcado.
  • Copia de seguridad lógica coordinada para clústeres de MongoDB fragmentados: el complemento de Bacula para MongoDB proporciona a las implementaciones de clústeres fragmentados una trayectoria de copia de seguridad lógica coordinada sin necesidad de scripts de orquestación personalizados. Captura los datos de la aplicación a través de mongos junto con los metadatos de enrutamiento para la recuperación lógica de los datos de la aplicación. Dicho esto, la coherencia entre los fragmentos depende de que el equilibrador se detenga y se impidan las escrituras mientras dura la copia de seguridad.
  • Recuperación granular de MongoDB a nivel de base de datos y colección – Con el complemento de MongoDB, puedes filtrar y recuperar bases de datos específicas o colecciones individuales sin tener que recurrir a la restauración de todo el clúster de bases de datos. A su vez, los tiempos de restauración se reducen considerablemente y el riesgo de sobrescribir datos intactos junto con los dañados se reduce de forma significativa. *La restauración granular a nivel de colección se aplica a artefactos lógicos completos y no se puede combinar con la reproducción del oplog, lo que significa que no es posible restaurar una colección específica a un momento preciso en una sola operación.
  • Recuperación a un punto en el tiempo para conjuntos de réplicas de MongoDB – Dado que una migración de esquema fallida o la eliminación accidental de una colección pueden borrar, como es bien sabido, horas de escrituras, el complemento de MongoDB de Bacula registra segmentos del registro de operaciones en cada tarea incremental y diferencial para proporcionar una recuperación precisa a un punto en el tiempo (PITR). El parámetro replay_to permite detener la reproducción en cualquier punto dentro de la ventana de oplog disponible. Esta capacidad permite recuperar el conjunto de réplicas al estado protegido más cercano anterior al incidente.

Características principales del complemento de MongoDB para Bacula

Integridad de los datos y seguridad del acceso

  • Validación de la continuidad de la cadena previa a la restauración: cada vez que se inicia una restauración, el complemento de MongoDB comprueba automáticamente la integridad de la suma de comprobación, la identidad de la cadena, el enlace con el elemento padre, la huella digital de origen y los límites del oplog. Si falta algún elemento o hay alguna discrepancia, el complemento bloqueará la restauración antes de que llegue a la base de datos.
  • Compatibilidad con la autenticación TLS y MONGODB-X509: el complemento de MongoDB se conecta a entornos de MongoDB seguros sin necesidad de renunciar a los estándares de autenticación. Es compatible con TLS tanto en la conexión del controlador de Java como en la capa de herramientas de la base de datos de MongoDB; con SCRAM para la autenticación basada en contraseña; y con MONGODB-X509 para la autenticación basada en certificados, en la que el nombre de usuario de MongoDB debe coincidir exactamente con el sujeto del certificado del cliente. Además, las credenciales de conexión se gestionan a través de un «password_file» para aislarlas de los registros de tareas y de la salida de configuración.
  • Metadatos de manifiesto y cadena para la auditabilidad: cada tarea de copia de seguridad de MongoDB genera un registro completo y verificable de lo que se ha copiado, incluyendo la versión de origen, la topología, las bases de datos seleccionadas y las sumas de comprobación. Estos archivos de metadatos se incluyen junto con los artefactos de copia de seguridad en el catálogo de Bacula, en la ruta /@mongodb, y están disponibles para la auditoría y la planificación de la restauración sin necesidad de intervenir en el entorno en producción.

Infraestructura de copias de seguridad adaptativa

  • Compatibilidad con copias de seguridad en múltiples topologías: el complemento es compatible con los tres tipos de implementación de MongoDB (a saber, servidores independientes, conjuntos de réplicas y clústeres fragmentados), y el comportamiento de las copias de seguridad se adapta automáticamente a la topología, sin necesidad de intervención manual alguna. Los servidores independientes se someten a una copia de seguridad lógica completa mediante mongodump. Los conjuntos de réplicas se someten a una copia de seguridad completa que inicia una cadena de recuperación, seguida de tareas incrementales y diferenciales que registran los segmentos del oplog. Las copias de seguridad de los clústeres fragmentados se realizan a través de mongos, y se capturan los metadatos de enrutamiento junto con los datos de la aplicación.
  • Informes de simulación para copias de seguridad y restauraciones: el comando dry_run=yes genera un informe completo de lo que implicaría la copia de seguridad o la restauración, sin escribir ni modificar nada, de modo que cualquier error de configuración o problema de compatibilidad se detecte mucho antes de que la tarea se ejecute en un entorno productivo. En el caso de las copias de seguridad, esto valida la conexión, la topología, los permisos, la compatibilidad de las herramientas y el espacio de trabajo disponible.

Conjunto completo de funciones del complemento de MongoDB

La recuperación a un momento determinado, junto con el resto de funciones mencionadas anteriormente, es solo una parte del panorama general de lo que el complemento puede aportar a la copia de seguridad y la recuperación de tu base de datos de MongoDB. A continuación puedes ver la amplia gama de funciones que el complemento ofrece a las grandes empresas con millones de usuarios simultáneos.

Capacidades de copia de seguridad

  • Copias de seguridad completas, incrementales y diferenciales: el complemento es compatible con los tres niveles de tareas. Los conjuntos de réplicas obtienen cadenas auténticas basadas en el oplog; y las implementaciones independientes y fragmentadas obtienen artefactos lógicos de tipo completo en todos los niveles.
  • Copia de seguridad lógica mediante mongodump: cada copia de seguridad es un artefacto lógico generado por la propia herramienta mongodump de MongoDB, que muestra el contenido real de la base de datos en el momento en que se ejecutó la tarea.
  • Filtrado de bases de datos y colecciones: los filtros de inclusión y exclusión te permiten limitar cualquier tarea de copia de seguridad a bases de datos específicas o colecciones individuales.
  • Captura de metadatos de enrutamiento de clústeres fragmentados: para las implementaciones fragmentadas, el complemento registra la pertenencia a fragmentos y los metadatos de enrutamiento junto con los datos de la aplicación para facilitar la planificación de la restauración a nivel de aplicación a través de mongos. Esto cubre únicamente la recuperación lógica de los datos de la aplicación.

Funcionalidades de restauración

  • Recuperación a un momento determinado para conjuntos de réplicas: el parámetro replay_to detiene la reproducción del oplog en cualquier punto dentro de la ventana de oplog disponible. La precisión de la recuperación depende de la retención del oplog, la frecuencia de las tareas y el último límite de cadena capturado con éxito.
  • Restauración en tiempo real en mongorestore: las cargas útiles completas de los archivos se transmiten directamente desde el almacenamiento de Bacula a mongorestore sin necesidad de escribir primero los archivos de volcado completos en el disco local.
  • Restauración entre hosts: el complemento transmite los artefactos a mongorestore en cualquier destino válido, lo que permite realizar pruebas en entornos aislados y migraciones de clústeres. No obstante, la portabilidad del formato lógico no garantiza que se pueda restaurar todas las combinaciones de versión del servidor, versión de Database Tools, FCV, definición de índices o características de la colección.
  • Control de la estrategia de conflictos: el parámetro conflict_strategy controla cómo gestiona el complemento los datos existentes en el destino de la restauración. Se puede establecer conflict_strategy=fail a través de la sesión de restauración de Bacula para restauraciones de validación, y conflict_strategy=drop solo cuando sea seguro sustituir los datos existentes en el destino.

Seguridad

  • Compatibilidad con conexiones TLS: TLS es compatible tanto con la conexión del controlador Java como con la capa de herramientas de la base de datos MongoDB.
  • Autenticación SCRAM y MONGODB-X509: el complemento también admite la autenticación SCRAM basada en contraseña y la autenticación MONGODB-X509 basada en certificados, en la que el nombre de usuario de MongoDB debe coincidir exactamente con el sujeto del certificado del cliente.
  • Aislamiento de credenciales mediante password_file: las credenciales de conexión se gestionan a través de un password_file. No están integradas en las URI, lo que permite mantenerlas separadas de los registros de tareas y de la salida de configuración.
  • Usuario de copia de seguridad con privilegios mínimos: el complemento está diseñado para ejecutarse bajo un usuario de copia de seguridad de MongoDB específico, al que solo se le conceden los privilegios necesarios para el modo de copia de seguridad seleccionado.

Complemento de copia de seguridad y restauración de MongoDB: comparación de topologías

El complemento de MongoDB adapta su comportamiento de copia de seguridad en función de la topología de implementación a la que esté conectado. La tabla siguiente muestra lo que admite cada topología, para que te resulte más fácil planificar tu estrategia de copia de seguridad y tus expectativas de recuperación antes de que se ejecute la primera tarea.

Capacidad Autónomo Conjunto de réplicas Clúster fragmentado
Copia de seguridad completa Sí Sí Sí
Incremental / Diferencial Artefactos lógicos de tipo completo (sin cadena de oplog) Cadena auténtica basada en el oplog Recuperación de datos de la aplicación
Recuperación en un momento determinado (PITR) No Sí — mediante replay_to No
Captura de oplog No Sí — Tareas incrementales y diferenciales No
Validación de la continuidad de la cadena No Sí — antes de cada restauración No
Captura de metadatos de enrutamiento No No Sí — pertenencia a fragmentos y configuración de enrutamiento
Se requiere Balancer Guardrail No No Sí
(1) el equilibrador debe estar detenido; (2) migraciones de fragmentos desactivadas; (3) escrituras bloqueadas mientras dure el volcado
Destino de conexión mongod primario Primar con capacidad de escritura (se prefiere el URI del conjunto de réplicas) solo mongos
Método de restauración Restauración lógica completa mediante mongorestore Repetición de la cadena validada mediante mongorestore Restauración de la aplicación a través de mongos con preparación del enrutamiento

¿Cómo protege Bacula los datos de las copias de seguridad de MongoDB frente a las ciberamenazas?

Para combatir a los ciberdelincuentes y proteger a las organizaciones frente al ransomware, Bacula Enterprise —en el que confían organizaciones a gran escala como la NASA, la Armada de los Estados Unidos y la Fuerza Aérea de los Estados Unidos— protege los datos de las copias de seguridad de MongoDB mediante la integración directa con destinos de almacenamiento inmutables y conformes con el estándar WORM, con el fin de impedir que un atacante que posea credenciales pueda modificar, renombrar o, lo que es peor, borrar los datos hasta que expire el periodo de retención configurado.

Arquitectura y control de acceso

  • Arquitectura aislada de cinco módulos: en la arquitectura de cinco módulos de Bacula, el demonio de archivos (cliente), el director, el demonio de almacenamiento, la consola y la base de datos del catálogo funcionan como componentes independientes. Este tipo de separación limita el alcance de un componente comprometido, especialmente cuando se combina con la segmentación de la red, credenciales únicas por componente, TLS mutuo y controles de acceso con el mínimo privilegio.
  • Privilegios restringidos del demonio de archivos (cliente): los administradores pueden limitar exactamente en qué directorios puede un cliente realizar copias de seguridad, restaurar datos y ejecutar scripts mediante las directivas AllowedBackupDirectories, AllowedRestoreDirectories y AllowedScriptDirectories. El demonio de archivos también puede ejecutarse en modo de solo lectura, con el fin de impedir cualquier modificación no autorizada desde ese sistema.
  • Control de acceso basado en roles: Bacula admite un control de acceso granular basado en roles (RBAC) mediante listas de control de acceso (ACL) especializadas que restringen con precisión lo que un usuario de la consola puede ver y modificar. Esta seguridad se aplica en las capas de control JobACL, CommandACL, PoolACL y ScheduleACL.
  • Autenticación multifactorial: el acceso a la consola admite la autenticación multifactorial (MFA) basada en TOTP y cumple con la norma RFC 6238, además de la autenticación estándar mediante contraseña y TLS. El acceso a la interfaz gráfica de usuario web admite por separado la autenticación mediante contraseña de un solo uso, que también incluye opciones de validación biométrica a través de smartphone.

Inmutabilidad e integridad de los datos

  • Protección de volúmenes gestionada por Bacula: Bacula establece un atributo de «solo añadir» en los volúmenes basados en archivos durante su primera tarea de copia de seguridad para evitar la pérdida de datos por sobrescritura. Una vez que un volumen se marca como «lleno», un indicador de inmutabilidad puede impedir que se vuelva a etiquetar o reutilizar hasta que expire su período de protección. Estos controles se aplican en la capa de aplicación y su resistencia frente a un atacante depende de los privilegios del sistema operativo, la compatibilidad del sistema de archivos, los privilegios del daemon de almacenamiento y la configuración de retención.
  • Inmutabilidad impuesta por el hardware y la nube: para lograr una inmutabilidad que resista incluso el acceso privilegiado a nivel del sistema operativo, Bacula se integra con la inmutabilidad controlada por dispositivos en NetApp SnapLock, DataDomain RetentionLock y HPE StoreOnce, así como con el modo de cumplimiento WORM y el bloqueo de objetos en AWS S3, Azure y Google Cloud Storage. A diferencia de los controles de la capa de aplicación, estos se aplican a nivel de hardware o del proveedor de la nube y no pueden anularse mediante credenciales del sistema operativo.
  • Verificación de tareas y comprobación de integridad basada en hash: Bacula puede detectar corrupciones silenciosas calculando firmas SHA256 o SHA512 de los datos de los archivos y comparando el estado actual de un volumen con su registro en el Catálogo. Para la validación de integridad adversaria, hay que tener en cuenta que esta comparación se basa en que el catálogo permanezca intacto junto con los volúmenes de copia de seguridad.
  • Almacenamiento aislado físicamente: Bacula Enterprise funciona totalmente fuera de línea en entornos completamente aislados, sin depender de Internet. El Director, los demonios de almacenamiento y los demonios de archivos pueden distribuirse en redes segregadas, de modo que los datos de copia de seguridad de MongoDB permanecen inaccesibles para las amenazas externas incluso en caso de una brecha a nivel de red.

Cifrado

  • Comunicaciones cifradas: los demonios de Bacula se autentican mediante SCRAM-SHA-256. El cifrado TLS debe estar habilitado para todas las comunicaciones de red en una implementación segura y es compatible con todos los componentes de Bacula.
  • Cumplimiento con la norma FIPS 140-3: Bacula Enterprise garantiza el cumplimiento de la norma FIPS 140-3 a través de su módulo criptográfico, que utiliza OpenSSL-FIPS y está certificado en múltiples plataformas. El módulo se puede utilizar en todos los componentes de Bacula.
  • Cifrado de datos en reposo: el demonio de almacenamiento puede cifrar un destino de almacenamiento completo de una sola vez, independientemente de la fuente de datos. Los administradores también pueden configurar el cifrado por separado para clientes individuales.

Detección de amenazas

  • Detección de ransomware con BGuardian: el módulo de análisis de seguridad automatizado de Bacula, BGuardian, comprueba la solidez de la configuración, el uso del cifrado, los patrones de corrupción de copias de seguridad y docenas de otros indicadores de refuerzo de la seguridad en todo el entorno, generando informes y alertas persistentes a medida que se detectan problemas.
  • Análisis de malware y antivirus: Bacula ofrece una defensa automatizada contra amenazas mediante la integración de un complemento antivirus con ClamAV para analizar los archivos copiados en busca de virus durante las tareas de verificación posteriores a la copia de seguridad.

¿Qué se obtiene al implementar Bacula Enterprise?

Cada implementación de Bacula Enterprise te ofrece las siguientes funciones en materia de recuperación, copias de seguridad, precios y administración de la plataforma.

Capacidades de copias de seguridad eficientes

  • Compresión adaptativa – Los algoritmos de compresión se pueden configurar para cada trabajo, de modo que los administradores puedan ajustar la compresión en función del tipo de datos y los recursos disponibles.
  • Copias de seguridad completas, diferenciales e incrementales – Bacula admite los niveles de copia de seguridad completa, diferencial e incremental. Una estrategia típica comienza con una copia de seguridad completa, seguida de copias de seguridad incrementales, lo que evita tener que ejecutar repetidamente copias de seguridad completas de gran tamaño según un calendario fijo.
  • Copias de seguridad completas virtuales progresivas – Bacula puede combinar una copia de seguridad completa existente con sus incrementales posteriores para crear una nueva copia de seguridad completa sintética sin necesidad de volver a contactar con el cliente. En su lugar, el proceso lee los datos del almacenamiento de copias de seguridad existente. La directiva Backups To Keep puede repetir esta consolidación de forma continua.
  • Almacenamiento temporal en disco antes de la escritura en cinta – Bacula puede escribir los datos de la copia de seguridad en un archivo temporal en disco antes de enviarlos a la cinta como un flujo continuo. Esto ayuda a evitar los movimientos intermitentes de la cinta que pueden producirse cuando los datos llegan demasiado despacio como para que la unidad pueda escribir de forma continua. Este problema es especialmente habitual en las copias de seguridad incrementales y diferenciales, que suelen generar flujos de datos más pequeños y menos constantes que las copias de seguridad completas.
  • Transferencias que tienen en cuenta el ancho de banda – Tras la copia de seguridad inicial, solo se transfieren por la red los datos modificados. Esto mantiene el tráfico de red a un nivel más bajo sin necesidad de limitar manualmente el ancho de banda ni de recurrir a soluciones alternativas de programación.
  • Programación frecuente de copias de seguridad – Las tareas de copia de seguridad pueden ejecutarse cada pocos minutos en lugar de una vez al día, lo que reduce la ventana de posible pérdida de datos de horas a minutos.
  • Protección continua de datos – La aplicación cdp-client supervisa los cambios en los archivos y los copia a un directorio de cola a medida que se producen. A continuación, FileDaemon envía esos datos a una tarea de copia de seguridad habitual de Bacula a intervalos fijos, de modo que los cambios se pueden capturar en cuestión de segundos o minutos, en lugar de esperar a la siguiente copia de seguridad programada.

Capacidades de recuperación ultrarrápidas

  • Restablecimiento completo a nivel de sistema – Bacula Enterprise puede recuperar un servidor completo, incluyendo el sistema operativo, las aplicaciones, la configuración y los datos, sin necesidad de realizar primero una instalación manual del sistema operativo.
  • Recuperación de datos multiplataforma – Los datos de copia de seguridad se pueden recuperar en un sistema operativo diferente al original. Esto ofrece a los equipos una mayor flexibilidad durante las sustituciones de hardware, las migraciones u otros escenarios de recuperación.
  • Validación automatizada de la restauración – Las pruebas automatizadas permiten verificar que los datos de copia de seguridad son recuperables sin que el administrador tenga que ejecutar un proceso de validación independiente.
  • Replicación geográfica de copias de seguridad – Bacula mantiene una única copia de seguridad de forma predeterminada. Para crear copias adicionales en otras ubicaciones, los administradores pueden configurar tareas de copia o migración. Una configuración típica podría consistir en mantener la copia principal en un almacenamiento local, crear una segunda copia en otro tipo de soporte, como el almacenamiento en la nube, y enviar luego una tercera copia a una ubicación externa o aislada físicamente. Esta configuración ayuda a garantizar que un corte de suministro en todo el centro no afecte a todas las copias de recuperación disponibles.

Control de costes y licencias de copia de seguridad predecibles

  • Deduplicación a nivel de bloque: los bloques de datos repetidos se almacenan solo una vez en el catálogo de copias de seguridad, lo que reduce el consumo de almacenamiento sin necesidad de modificar las políticas ni las programaciones de copia de seguridad.
  • Flujos de trabajo de almacenamiento por niveles: los datos de copia de seguridad pueden desplazarse automáticamente entre los distintos niveles de almacenamiento a medida que envejecen. Los puntos de recuperación recientes pueden permanecer en un almacenamiento más rápido, mientras que las copias de seguridad más antiguas se trasladan a destinos de menor coste.
  • Licencias independientes del volumen: los costes de las licencias no aumentan a medida que crecen los datos protegidos. Los equipos pueden ampliar su entorno de copias de seguridad sin tener que asumir cuotas de licencia más elevadas.
  • Costes predecibles: los precios fijos facilitan la planificación de los presupuestos de infraestructura, sin cargos variables por licencia vinculados al crecimiento del almacenamiento o a los cambios en la carga de trabajo.
  • Precios independientes de la carga de trabajo: el tamaño de las bases de datos, el número de servidores y la cantidad de almacenamiento protegido no afectan a los costes de las licencias.
  • Menores costes a gran escala: los entornos grandes o en rápido crecimiento pueden añadir datos protegidos sin aumentar las cuotas de licencia. El ahorro puede ser más significativo a medida que crecen los volúmenes de datos, en comparación con los modelos de licencia basados en la capacidad.

Gestión y administración de copias de seguridad

  • Interfaz dual: BWeb ofrece una consola gráfica para la gestión y supervisión diarias de los trabajos. Bconsole (agente de usuario) proporciona a los operadores un control total mediante la línea de comandos para la creación de scripts, la automatización y la configuración avanzada.
  • Escalabilidad sin límites: la misma arquitectura de plataforma gestiona entornos que van desde unos pocos servidores hasta implementaciones que alcanzan los miles, todo ello bajo un único plano de gestión.
  • Detección automática de recursos: la plataforma analiza la infraestructura para identificar y catalogar automáticamente los destinos de copia de seguridad. La cobertura de protección se mantiene actualizada a medida que crece el entorno.
  • Informes detallados: los informes programados recogen los resultados de las tareas, las tendencias de capacidad, el estado de cumplimiento normativo y el rendimiento operativo con una periodicidad definida.
  • Integración con sistemas externos: Bacula se conecta con herramientas de supervisión, sistemas de gestión de incidencias de TI y servicios de directorio, sin necesidad de desarrollo personalizado.

Preguntas frecuentes

¿Cómo se realiza una copia de seguridad de una base de datos MongoDB en funcionamiento sin tiempo de inactividad?

En el caso de servidores independientes y conjuntos de réplicas, el complemento Bacula Enterprise MongoDB ejecuta mongodump en una base de datos en funcionamiento sin interrumpir las lecturas ni las escrituras, y la base de datos permanece totalmente operativa durante los trabajos de copia de seguridad. No obstante, la garantía de ausencia de tiempo de inactividad no se aplica a las copias de seguridad de clústeres fragmentados, ya que estas requieren: (1) detener el equilibrador de fragmentos mediante sh.stopBalancer(), (2) desactivar a continuación las migraciones de fragmentos programadas, y (3) impedir las operaciones de escritura y las transformaciones de esquema mientras dura el volcado. Es de esperar que las operaciones de escritura se interrumpan durante la ventana de copia de seguridad. Realiza primero la copia de seguridad del conjunto de réplicas del servidor de configuración y, a continuación, captura cada conjunto de réplicas de fragmento en un intervalo de tiempo lo más breve posible.

¿Cuál es la diferencia entre una copia de seguridad lógica y una física en MongoDB?

Una copia de seguridad lógica utiliza mongodump para exportar los documentos, índices y esquemas de la base de datos a archivos BSON portátiles. Estos archivos son independientes del motor de almacenamiento subyacente y, por lo general, pueden restaurarse en un servidor diferente, aunque las restauraciones entre versiones dependen de la compatibilidad entre versiones de MongoDB, la versión de Database Tools y la versión de compatibilidad de funciones (FCV). Por lo tanto, no se garantiza que todas las combinaciones funcionen. Una copia de seguridad física, por su parte, copia los archivos de datos sin procesar del disco, lo que resulta mucho más rápido para conjuntos de datos muy grandes, pero vincula el archivo a la versión y al motor de almacenamiento originales.

¿Cómo funciona la recuperación a un momento determinado (PITR) para los conjuntos de réplicas de MongoDB?

La recuperación a un momento determinado (PITR) está disponible exclusivamente para conjuntos de réplicas. Cuando es necesaria una restauración, el parámetro `replay_to` detiene la reproducción del oplog en cualquier punto dentro de la ventana de oplog disponible y recupera el conjunto de réplicas al estado protegido más cercano dentro de esa ventana antes de que se produzca un incidente. Los servidores independientes y los clústeres fragmentados no admiten la recuperación a un punto en el tiempo (PITR) a través de este complemento, ya que no proporcionan una cadena de recuperación del oplog de la misma forma que los conjuntos de réplicas. Si necesitas recuperar una colección específica a un punto en el tiempo, lo recomendado es restaurar primero la cadena completa del conjunto de réplicas en un destino que no sea de producción y, a continuación, extraer y conciliar los datos necesarios a nivel de aplicación.

¿Se puede restaurar una sola colección de MongoDB sin recuperar toda la base de datos?

Sí. El complemento de MongoDB de Bacula admite filtros de inclusión y exclusión a nivel de base de datos y de colección, de modo que una tarea de restauración puede centrarse en una colección específica sin afectar al resto de la base de datos. Esto mantiene breves las ventanas de restauración y limita el riesgo de sobrescribir datos sanos junto con los datos dañados que necesitas sustituir. La restauración completa de la base de datos está disponible cuando sea necesario, pero nunca es la única opción.

Además, ten en cuenta que la restauración granular a nivel de colección se aplica a artefactos completos lógicos y no se puede combinar con la reproducción del oplog, lo que significa que la recuperación a un momento determinado opera en todo momento en el ámbito completo del conjunto de réplicas. Si necesitas ambas cosas, asegúrate primero de restaurar la cadena completa del conjunto de réplicas en un destino que no sea de producción y, a continuación, extrae los datos necesarios a nivel de aplicación.

¿Por qué utilizar el complemento de Bacula para MongoDB en lugar de ejecutar mongodump manualmente?

mongodump por sí solo es una herramienta eficaz para una única exportación lógica. Dicho esto, su limitación radica en que no te ofrece todo lo que viene después del volcado (programación centralizada, retención automatizada, validación de sumas de comprobación, metadatos de la cadena de recuperación, y la lista continúa). El complemento de Bacula Enterprise para MongoDB integra mongodump y mongorestore en el motor de políticas de Bacula, de modo que cada tarea de copia de seguridad de MongoDB se programa, cataloga y valida adecuadamente, y se puede recuperar desde la misma consola que gestiona el resto de tu infraestructura.

Más ayuda sobre las copias de seguridad de MongoDB:

También puede interesarle:
respaldos incrementales
respaldo de servidores
respaldos en linux