Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

FAQ: Copia de seguridad y restauración

Estas preguntas frecuentes abordan preguntas comunes sobre Ops Manager y cómo realiza copias de seguridad y restaura bases de datos y colecciones.

La introducción del Agente MongoDB y el nuevo proceso de copia de seguridad para MongoDB 4.2 con un FCV de 4.2 He cambiado algunas de estas respuestas. Esas respuestas cuentan con advertencias que explican el impacto de estas nuevas funcionalidades en las respuestas existentes.

Serie de lanzamientos de Ops Manager
1,6 a 1,8
2.0 a 3.2
3.4
3.6
4.0
4.2

Versión mínima de MongoDB 2.4

2.4.3

2.4.3

2.4.3

2.4.0 [1]

Versión mínima de MongoDB 2.6

2.6.0

2.6.0

2.6.0

2.6.0

2.6.0

2.6.0 [2]

Versión mínima MongoDB 3.0

3.0.0

3.0.0

3.0.0

3.0.0

3.0.0

3.0.0 [2]

Versión mínima de MongoDB 3.2

3.2.0

3.2.0

3.2.0

3.2.0

3.2.0

Versión mínima de MongoDB 3.4

3.4.0

3.4.0

3.4.0

3.4.0

Versión mínima de MongoDB 3.6

3.6.0

3.6.0

3.6.0

Versión mínima de MongoDB 4.0

4.0.0

4.0.0

Versión mínima de MongoDB 4.2

4.2.0

[1] Solo supervisión
[2](1, 2) Solo supervisión y copia de seguridad

Si estás realizando un respaldo de una instancia de MongoDB que tiene la autenticación activada, el MongoDB Agent requiere los privilegios descritos para la función de copia de seguridad del MongoDB Agent.

Tip

Ops Manager utiliza las siguientes conversiones para medir el tamaño de los snapshots y para medir cuántos datos de oplog se han procesado:

  • 1 MB = 1024 2 bytes (1 MiB)

  • 1 GB = 1024 3 bytes (1 GiB)

  • 1 TB = 1024 4 bytes (1 TiB)

  • Para MongoDB 4.2 y versiones posteriores, consulta Consideraciones de copia de seguridad para bases de datos.

  • Para cualquier MongoDB con compatibilidad de características entre versiones 4.0 y bases de datos anteriores, Copia de seguridad no admite implementaciones independientes. Copia de seguridad tiene soporte completo para conjuntos de réplicas y clústeres fragmentados.

Ops Manager copia los datos del oplog para proporcionar una copia de seguridad continua con recuperación a puntos en el tiempo. Ops Manager no admite la copia de seguridad de hosts independientes porque no tienen un oplog. Para admitir la copia de seguridad con una única mongod instancia, puedes ejecutar un set de réplicas de un solo miembro.

Para aprender sobre la funcionalidad de copia de seguridad, consulta Proceso de copia de seguridad.

Nota

Esta respuesta se aplica solo a bases de datos que ejecutan MongoDB con FCV 4.0 y versiones anteriores

La funcionalidad de copia de seguridad generalmente tiene un impacto mínimo en las implementaciones de MongoDB en producción. Este impacto se comporta de manera similar a la de agregar un nuevo secundario a un set de réplicas.

Por defecto, el agente realiza su sincronización inicial, la operación que consume más recursos para las copias de seguridad, sobre un miembro secundario del set de réplicas para limitar su impacto. Opcionalmente, puedes configurar el agente de copias de seguridad para realizar la sincronización inicial contra la primaria del conjunto de réplicas, aunque esto aumenta el impacto de la operación de sincronización inicial.

La mayoría de las operaciones en un conjunto de réplicas se replican a través del registro de operaciones y, por lo tanto, quedan capturadas por el proceso de copia de seguridad.

  • Creación de índices continua.

  • Utiliza compact o repairDatabase para recuperar una cantidad significativa de espacio.

    La resincronización no es estrictamente necesaria después de compact o repairDatabase operaciones, pero garantizará que la copia de los datos de Ops Manager cambie de tamaño, lo que significa restauraciones más rápidas.

La capacidad de copia de seguridad se ha trasladado al MongoDB Agent con la copia de seguridad activada. Esto reemplaza al Agente de copia de seguridad individual. Esta información cubre problemas únicos del antiguo agente de respaldo. Toda esta información se aplica a las bases de datos de MongoDB que ejecutan compatibilidad de características entre versiones 4.0 o una versión anterior.

Ejecuta el agente de copia de seguridad en un host:

  • Es independiente de tus instancias de MongoDB. Esto evita la disputa por recursos del sistema.

  • Puede conectarse a sus instancias de MongoDB. Compruebe la configuración de red para ver las conexiones entre el agente y los hosts de MongoDB. Para obtener una lista de los puertos necesarios, consulte los puertos abiertos para los agentes.

  • Tiene al menos 2 núcleos de CPU y 3 GB de RAM por encima de los requisitos de la plataforma. Con cada trabajo de copia de seguridad que ejecuta, el Agente de Copia de Seguridad afecta aún más el rendimiento del host.

No existe ninguna restricción técnica que impida que el agente de copias de seguridad y la Supervisión funcionen en un solo sistema o host. Sin embargo, ambos agentes tienen requisitos de recursos, y ejecutarlos en un solo sistema puede afectar la capacidad de estos agentes para soportar tu implementación en Ops Manager.

Los recursos requeridos por el Agente de Backup dependen de la velocidad y el tamaño de las nuevas entradas de oplog (es decir, el total de gigabytes/hora de oplog producidos). Los recursos que requiere el Monitoreo dependen de la cantidad de instancias monitoreadas mongod y la cantidad total de bases de datos proporcionadas por las mongod instancias.

Puedes ejecutar varios agentes de copia de seguridad para alta disponibilidad. En ese caso, los agentes de copias de seguridad deben ejecutarse en diferentes hosts.

Al ejecutar varios agentes de respaldo, solo un agente por proyecto es el principal. Este realiza las copias de seguridad. Los demás agentes permanecen completamente inactivos, excepto para registrar su estado en espera y para consultar periódicamente a Ops Manager si deben convertirse en el principal.

El Agente de Backup escribe un pequeño token, llamado punto de control, en el registro de operaciones de la base de datos de origen a intervalos regulares. Estos tokens proporcionan un latido para las copias de seguridad y no afectan la implementación de origen. Cada token ocupa menos de 100 bytes.

El impacto de la sincronización inicial de la copia de seguridad debe ser similar a la sincronización de un nuevo miembro del set de réplicas secundarias. El agente de copias de seguridad no limita su actividad y trata de realizar la sincronizar lo más rápido posible.

Nota

El filtrado de namespace sólo es compatible con versiones de Ops Manager 6.0.8 y posteriores. Tus implementaciones de MongoDB deben tener featureCompatibilityVersion valores de 4.0 y anteriores o 6.0.1 y posteriores.

Ops Manager proporciona un filtro de namespaces que te permite especificar qué colecciones o bases de datos respaldar.

Para editar el filtro, consulta Editar la configuración de una copia de seguridad. Cambiar el filtro de namespace podría requerir una resincronización. Si es así, Ops Manager gestiona la resincronización.

La razón más común por la que las tareas no se vinculan a un daemon de copias de seguridad es que ningún demonio tiene espacio para una copia local del set de réplicas respaldado.

Para aumentar la capacidad para que el trabajo de respaldo pueda vincularse, debe:

Si notas errores coherentes en applyOps comandos en tus registros de copia de seguridad, esto puede indicar que el demonio se ha quedado sin espacio.

Para aumentar el espacio en un demonio y así permitir la continuidad de las operaciones, debe:

Ops Manager produce una copia de sus archivos de datos que puede usar para iniciar una nueva implementación.

Importante

Ops Manager 4.2.13 y versiones posteriores admiten esta funcionalidad con FCV 4.2 o posterior.

Cuando activas la restauración, Ops Manager crea un enlace a este snapshot. Una vez hecho clic, Ops Manager recupera fragmentos del almacenamiento de snapshot y los transmite al host de destino.

La utilidad de copia de seguridad y restauración de MongoDB que se ejecuta en ese host luego descarga y aplica las entradas del oplog para alcanzar el punto en el tiempo especificado.

La capacidad de Ops Manager para proporcionar una restauración a un punto específico del tiempo depende de la política de retención de los snapshots y de la ventana configurada de punto en el tiempo.

Para obtener más información sobre la política de retención y la ventana de punto en el tiempo, consulta Editar el cronograma de snapshots y la política de retención.

No. Ops Manager no admite una programación de instantáneas con una frecuencia mayor a 6 horas. Para obtener más información, consulte la Política de frecuencia y retención de instantáneas.

Sí. Puedes cambiar el cronograma a través del Edit Snapshot Schedule opción de menú para una implementación respaldada. Los administradores pueden cambiar la frecuencia de snapshot y política de retención a través del recurso snapshotSchedule en la API.

Ops Manager siempre conserva al menos una instantánea restaurable para cada implementación respaldada. Si una serie de trabajos de copia de seguridad fallan y la programación de instantáneas y la política de retención configuradas provocarían la caducidad de todas las instantáneas existentes, Ops Manager pospone la optimización de la instantánea más reciente que se haya realizado correctamente hasta que se complete una nueva copia de seguridad exitosa.

Este comportamiento evita que los entornos con periodos de retención cortos pierdan su último punto de restauración válido simplemente debido a una serie de instantáneas fallidas.

Ops Manager transmite todas las copias de seguridad en forma comprimida desde el host de Ops Manager a tu infraestructura.

Además, las restauraciones en un punto en el tiempo dependen de la cantidad de entradas del registro de operaciones que su host debe aplicar a la instantánea recibida para avanzar al punto en el tiempo solicitado de la copia de seguridad.

La copia de seguridad realiza verificaciones básicas de corrupción y proporciona una alerta si algún componente (por ejemplo, el agente) está apagado o roto, pero no realiza una validación explícita de los datos. Cuando se detecta corrupción, Ops Manager actúa con cautela e invalida la copia de seguridad actual y envía una alerta.

Puedes solicitar una restauración a través de Ops Manager, donde podrás elegir qué snapshot restaurar y cómo quieres que Ops Manager realice la restauración. Todas las restauraciones requieren autenticación de dos factores. Si tienes configurado el SMS, Ops Manager enviará un código de autorización por SMS. Debes ingresar el código de autorización en la interfaz de copia de seguridad para iniciar el proceso de restauración.

Nota

Desde la India, utiliza Google Authenticator para la autenticación de dos factores. Google Authenticator es más fiable que la autenticación con mensajes de texto SMS a números de teléfono móvil indios (por ejemplo, código de país 91).

Ops Manager realiza restauraciones como tar.gz ficheros de los archivos de datos de MongoDB.

Para obtener más información sobre las restauraciones, consulta Restaurar las implementaciones de MongoDB.

Importante

En las implementaciones de MongoDB con FCV 4.2 o posterior, las reversiones no afectan a los datos respaldados en Ops Manager. A partir de 4.2 FCV, Ops Manager solo conserva las instantáneas con marcas de tiempo hasta el punto de confirmación mayoritario, incluido.

Si su implementación de MongoDB experimenta una reversión, Ops Manager también revierte los datos respaldados.

Ops Manager detecta la reversión cuando un cursor de cola encuentra una discrepancia en las marcas de tiempo o hashes de las operaciones de escritura. Ops Manager entra en estado de reversión y prueba tres puntos en el registro de operaciones del conjunto de réplicas principal para localizar un punto común en el historial. La reversión de Ops Manager se diferencia de la reversión secundaria de MongoDB en que el punto común no tiene que ser necesariamente el más reciente.

Cuando Ops Manager encuentra un punto común, el servicio invalida las entradas del oplog y los snapshots más allá de ese punto y retrocede al snapshot más reciente antes del punto común. Ops Manager luego reanuda las operaciones normales de copia de seguridad.

Si Ops Manager no puede encontrar un punto común, comuníquese con el soporte de MongoDB para obtener ayuda.

Volver

Automatización

En esta página