Docs Menu
Docs Home
/ /

FAQ: Copia de seguridad y restauración

Estas preguntas frecuentes abordan preguntas comunes sobre Cloud 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 respaldo para MongoDB 4.2 con FCV 4.2 Hemos modificado algunas de estas respuestas. Estas incluyen advertencias que explican el impacto de estas nuevas funciones en las respuestas existentes.

Si está realizando una copia de seguridad de una instancia de MongoDB que tiene la autenticación habilitada, el Agente de MongoDB requiere los privilegios descritos para la función de copia de seguridad del Agente de MongoDB.

Tip

Cloud Manager utiliza las siguientes conversiones para medir el tamaño de la instantánea y la cantidad de datos del registro de operaciones que 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, consulte Consideraciones de respaldo para bases de datos.

  • Para cualquier MongoDB con FCV 4.0 y bases de datos anteriores, Backup no admite implementaciones independientes. Backup es totalmente compatible con conjuntos de réplicas y clústeres fragmentados.

Cloud Manager copia datos del registro de operaciones para proporcionar una copia de seguridad continua con recuperación en un momento dado. Cloud Manager no admite la copia de seguridad de hosts independientes, ya que no tienen un registro de operaciones. Para realizar copias de seguridad con una sola mongod instancia, puede ejecutar un conjunto de réplicas de un solo miembro.

Nota

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

La función de copia de seguridad suele tener un impacto mínimo en las implementaciones de producción de MongoDB. Este impacto es similar al de añadir una réplica secundariaa un conjunto de réplicas.

De forma predeterminada, el agente realiza su sincronización inicial (la operación que consume más recursos para las copias de seguridad) con un miembro secundario del conjunto de réplicas para limitar su impacto. Opcionalmente, puede configurar el agente para que realice la sincronización inicial con el miembro principal del conjunto de réplicas, aunque esto aumenta el impacto de la sincronización inicial.

Sí, Cloud Manager utiliza hardware de nivel empresarial ubicado en centros de datos seguros para almacenar todos los datos de los usuarios. La copia de seguridad transmite todos los datos mediante SSL. Los datos se almacenan y procesan en volúmenes cifrados. Cloud Manager requiere autenticación de dos factores para proporcionar los datos necesarios para las restauraciones.

Actualmente no hay límite para el tamaño total de almacenamiento de instantáneas. La copia de seguridad funciona mejor en implementaciones cuyo tamaño total es inferior a 2 TB.

Si desea utilizar la función de copia de seguridad para una implementación más grande,comuníquese con nosotros para obtener más información.

La mayoría de las operaciones en un conjunto de réplicas se replican mediante el registro de operaciones y, por lo tanto, el proceso de copia de seguridad las captura. Sin embargo, algunas operaciones realizan cambios que no se replican: para estas operaciones, es necesario que Cloud Manager se sincronice de nuevo desde el conjunto de réplicas actual para incluir los cambios.

Las siguientes operaciones no se replican y, por lo tanto, requieren resincronización:

  • Renombrar o eliminar una base de datos eliminando los archivos de datos del directorio de datos. Como alternativa, elimine las bases de datos mediante una operación que MongoDB replique, como db.dropDatabase() mongoshdesde.

  • Cambiar cualquier dato mientras la instancia se ejecuta de forma independiente.

  • Construcciones de índices móviles.

  • Usando 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 Cloud Manager cambie de tamaño, lo que significa restauraciones más rápidas y menores costos.

El precio de Cloud Manager Backup se basa en el tamaño de las instantáneas, la programación y la política de retención. Consulta los precios de las copias de seguridad.

La función de copia de seguridad se ha trasladado al Agente de MongoDB con la función de copia de seguridad activada. Esto reemplaza al Agente de Copia de Seguridad individual. Esta información aborda problemas específicos del Agente de Copia de Seguridad heredado. Toda esta información se aplica a las bases de datos MongoDB que ejecutan FCV 4.0 o versiones anteriores.

Ejecuta el agente de copia de seguridad en un host:

  • Es independiente de las instancias de MongoDB. Esto evita la contención de 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 impacta aún más el rendimiento del host.

No existe ninguna restricción técnica que impida que el Agente de Backup y el de Monitoreo se ejecuten en un mismo sistema o host. Sin embargo, ambos agentes tienen requisitos de recursos, y ejecutarlos en un mismo sistema puede afectar su capacidad para soportar su implementación en Cloud 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.

Puede ejecutar varios agentes de respaldo para lograr alta disponibilidad. Si lo hace, los agentes de respaldo deben ejecutarse en hosts diferentes.

Al ejecutar varios agentes de respaldo, solo un agente por proyecto es el agente 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 Cloud Manager si deben convertirse en el agente 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.

Importante

Puede usar puntos de control para clústeres que ejecutan MongoDB con Feature Compatibility Version de 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con FCV 4.2 o posterior.

El impacto de la sincronización inicial de la copia de seguridad debería ser similar al de sincronizar un nuevo miembro del conjunto de réplicas secundario. El agente de copia de seguridad no limita su actividad e intenta realizar la sincronización lo más rápido posible.

La copia de seguridad siempre se conecta a los servidores de Cloud Manager mediante una conexión TLS (HTTPS).

La copia de seguridad puede conectarse a conjuntos de réplicas y clústeres compartidos configurados con TLS.

Nota

El filtrado de espacios de nombres solo es compatible con las versiones 6.0.8 y posteriores de Cloud Manager. Sus implementaciones de MongoDB deben tener valores featureCompatibilityVersion de 4.0 y anteriores, o 6.0.1 y posteriores.

Cloud Manager proporciona un filtro de espacios de nombres que le 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 espacios de nombres podría requerir una resincronización. En ese caso, Cloud Manager se encarga de la resincronización.

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

Al activar la restauración, Cloud Manager crea un enlace a esta instantánea. Al hacer clic, Cloud Manager recupera fragmentos del almacén de instantáneas y los transmite al host de destino.

Luego, la utilidad de restauración de copia de seguridad de MongoDB que se ejecuta en ese host descarga y aplica entradas de registro de operaciones para llegar al punto en el tiempo especificado.

Cloud Manager puede crear una restauración a cualquier punto en el tiempo dentro de un período de 24horas reproduciendo el registro de operaciones en el momento deseado.

Para aprender a restaurar conjuntos de réplicas y clústeres fragmentados, consulte Restaurar implementaciones de MongoDB.

No. Cloud 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 horario a través del Edit Snapshot Schedule Opción de menú para una implementación respaldada. Los administradores pueden cambiar la frecuencia de las instantáneas y la política de retención mediante el recurso snapshotSchedule en la API.

La personalización de la frecuencia de las instantáneas y las políticas de retención le brinda un mayor control sobre sus costos de respaldo.

Aunque solo le cobramos por una sola copia de los datos, Cloud Manager almacena al menos 3 copias de sus datos en al menos 2 ubicaciones geográficas para garantizar la redundancia.

Cloud Manager transmite todas las copias de seguridad en formato comprimido desde el host de Cloud Manager a su infraestructura.

Dentro de EE. UU., Cloud Manager envía instantáneas de 50 a 100 Mbps. Suponiendo un factor de compresión de 4x y velocidades de transmisión de 50 Mbps, transmitir una instantánea de 250 GB demora 2.5 horas.

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.

Backup realiza comprobaciones básicas de corrupción y emite una alerta si algún componente (p. ej., el agente) está inactivo o dañado, pero no realiza una validación explícita de datos. Al detectar corrupción, Cloud Manager es precavido e invalida la copia de seguridad actual y envía una alerta.

Puede solicitar una restauración a través de Cloud Manager, donde podrá elegir qué instantánea restaurar y cómo desea que Cloud Manager la entregue. Todas las restauraciones requieren autenticación de factor 2. Si ha configurado SMS, Cloud Manager le enviará un código de autorización por SMS. Debe introducir el código de autorización en la interfaz de copia de seguridad para iniciar el proceso de restauración.

Nota

Desde India, usa Google Authenticator para la autenticación de dos factores. Google Authenticator es más fiable que la autenticación mediante SMS a números de teléfono móvil de India (es decir, código de país 91).

Cloud Manager entrega restauraciones como archivos tar.gz de archivos de datos de MongoDB.

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

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

Cloud 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. Cloud 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 Cloud 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 Cloud Manager encuentra un punto común, el servicio invalida las entradas del registro de operaciones y las instantáneas posteriores a ese punto y revierte a la instantánea más reciente anterior al punto común. Cloud Manager reanuda entonces las operaciones de copia de seguridad normales.

Si Cloud Manager no puede encontrar un punto común, se requiere una resincronización.

Importante

Esta función es incompatible con MongoDB 4.2 con FCV. 4.2

Si el cursor de seguimiento del agente de respaldo no puede seguir el ritmo del registro de operaciones de su implementación, entonces deberá resincronizar sus copias de seguridad.

Este escenario podría ocurrir si:

  • Su aplicación genera periódicamente una gran cantidad de datos, lo que reduce la ventana del registro de operaciones principal hasta el punto de que los datos se escriben en el registro de operaciones más rápido de lo que Cloud Manager puede consumirlos.

  • Si el agente de copias de seguridad se ejecuta en un sistema poco aprovisionado o sobreutilizado y no alcanza a mantenerse al día con la actividad del oplog.

  • Si el agente de backup permanece inactivo durante un periodo superior al permitido por el tamaño del registro de operaciones, si desactiva sus agentes, por ejemplo, para mantenimiento, reinícielos a tiempo. Para obtener más información sobre el tamaño del registro de operaciones, consulte el registro de operaciones del conjunto de réplicas en el manual de MongoDB.

  • Si elimina todos los datos del conjunto de réplicas e implementa un nuevo conjunto de réplicas con el mismo nombre, como podría suceder en un entorno de prueba donde las implementaciones se desmantelan y reconstruyen periódicamente.

  • Si hay una reversión y Cloud Manager no puede encontrar un punto común en el registro de operaciones.

  • Si un evento de oplog intenta actualizar un documento que no existe en la copia de seguridad del conjunto de réplicas, como podría suceder si se sincroniza desde una réplica secundaria que tiene datos inconsistentes con respecto a la réplica principal.

  • Si crea un índice de forma continua.

Volver

Automatización

En esta página