Las copias de seguridad dependen de qué Versión de MongoDB compatible con su base de datos. Esta versión de compatibilidad de funciones abarca desde la versión actual hasta una versión anterior. Para MongoDB,4.2 la FCV puede ser... 4.0 o 4.2. Para implementaciones con FCV 4.2 o posteriores, Ops Manager requiere abrir un $backupCursor en el host fuente de copia de seguridad para copiar archivos de datos y capturar una snapshot. Esto requiere al menos un MongoDB Agent con un módulo de copia de seguridad habilitado y ubicado en los servidores que contienen datos por partición o conjunto de réplicas. El agente abre un $backupCursor a nivel del motor de almacenamiento para permitir la copia de archivos de la base de datos en un estado coherente, mientras sigue aceptando guardados.
Se requiere un seguimiento de Oplog del nodo primario para las copias de seguridad. Esta tarea normalmente es realizada por el MongoDB Agent con un módulo de copia de seguridad activado en el nodo primario de la partición de datos o el set de réplicas.
El proceso de copia de seguridad toma una instantánea del directorio de datos en su Intervalos de instantáneas programados. Este proceso copia los archivos de datos en una implementación de MongoDB y los envía por la red mediante Ops Manager a su almacenamiento de instantáneas existente. Su implementación aún puede gestionar operaciones de lectura y escritura durante el proceso de copia.
El proceso de copia de seguridad funciona de esta manera independientemente de cómo se almacenen los snapshots.
Nota
Con el nuevo proceso de copia de seguridad, ya no hay sincronización inicial. Como resultado de no tener sincronizaciones iniciales, Ops Manager puede dar soporte a un arreglo más amplio de clientes, como aquellos que hacen un uso intensivo de renameCollection.
Una vez iniciada la copia de seguridad, Ops Manager realiza una copia de seguridad de los datos de forma continua. Este proceso continúa creando instantáneas mientras la base de datos principal permanezca sincronizada con la base de datos principal.
Este proceso funciona como la sincronización de datos del set de réplicas.
El proceso de copia de seguridad:
Realiza una sincronización inicial para respaldar todos tus datos existentes en su estado actual. En clusters particionados, esto ocurre en cada partición y en los servidores de configuración.
Nota
Condiciones o acciones que reinician la sincronización inicial
Durante el proceso de sincronización inicial, ciertas acciones o condiciones pueden reiniciar el proceso de sincronización inicial. Evite las siguientes acciones y condiciones:
Acciones a Evitar durante la Sincronización Inicial:
Reiniciar, apagar o cambiar la versión o Valor compatibilidad de características entre versiones de la base de datos de origen.
Cambiar el nombre de la colección de la base de datos de origen.
Cambio del valor $out en la Pipeline de agregación de la base de datos fuente.
Reiniciar o apagar la aplicación Ops Manager o el Backup Daemon.
Reiniciar, apagar o actualizar el MongoDB Agent.
Condiciones a evitar durante la sincronización inicial:
Directorio principal está lleno.
La conectividad de red entre los componentes de Ops Manager es inestable.
Toma instantáneas del directorio
dataen una implementación tan a menudo como lo especifica tu programa de instantáneas y luego transfiere las instantáneas a un sistema de almacenamiento.Nota
Los clústeres fragmentados también pueden habilitar puntos de control para permitir restauraciones en momentos concretos entre instantáneas. Para saber cómo los clústeres fragmentados utilizan puntos de control, consulte Puntos de control.
Importante
Puedes utilizar puntos de control para clústeres que ejecuten MongoDB con la compatibilidad de características entre versiones del 4.0 o anterior. Los puntos de control se eliminaron de las instancias de MongoDB con una compatibilidad de características entre versiones de 4.2 o superior.
Monitoriza el oplog constantemente y añade nuevas operaciones de base de datos a la última copia de seguridad para mantener la copia local de Ops Manager de los datos actualizada.
El proceso de copia de seguridad funciona de esta manera independientemente de cómo se almacenen los snapshots.
Definición de copia de seguridad y estados operativos
Cada copia de seguridad se define como un tarea. Cada tarea define cuánto y con qué frecuencia se realizan copias de seguridad de los datos. Las tareas de copia de seguridad se definen por proyecto.
Estados operativos
La siguiente tabla enumera los estados de un trabajo de copia de seguridad:
Estado | Conservar snapshots antiguos | Crea nuevas snapshots |
|---|---|---|
| Sí | Sí |
| Sí | No |
| No | No |
| Sí | No |
Nota
El Misconfigured estado se aplica únicamente a la copia de seguridad regional.
Estado | Conservar snapshots antiguos | Crea nuevas snapshots | Aplicar Oplogs |
|---|---|---|---|
| Sí | Sí | Sí |
| Sí | No | No |
| No | No | No |
Cambiar estados operativos
Una vez que las tareas de copia de seguridad estén activas para un proyecto, se ejecutarán sin intervención adicional hasta que se detengan o finalicen. El operador puede cambiar el estado de una copia de seguridad de las siguientes maneras:
Estado inicial | Estado deseado | Método |
|---|---|---|
| Active | Haga clic en Start. |
| Stopped | Haga clic en Stop. |
| Active | Haga clic en Restart. |
| Inactive | Haga clic en Terminate. ADVERTENCIA: Terminate Elimina todas las copias de seguridad conservadas. |
Estado inicial | Estado deseado | Método |
|---|---|---|
| Active después | Haga clic en Start. |
| Stopped | Haga clic en Stop. |
| Active después | Haga clic en Restart. |
| Inactive | Haga clic en Terminate. ADVERTENCIA: Terminate Elimina todas las copias de seguridad conservadas. |
Importante
Es posible que reciba una Backup requires a resync alerta para sus trabajos de copia de seguridad. Esto podría requerir que resincronizar una copia de seguridad. Esto no es un estado diferente, sino la activación de un nuevo flujo de proceso de copia de seguridad. Una vez que Initial
Sync se completa, el trabajo de copia de seguridad vuelve Active a ser.
Flujos de procesos de copia de seguridad
Una vez creado, una tarea de copia de seguridad pasa por el siguiente flujo de proceso:
Cuando el clúster está listo para su snapshot programada, determina el nodo disponible óptimo para tomarla. En la mayoría de los casos,
mongoddetermina que el miembro secundario de menor prioridad es el nodo de snapshot preferido. Se pueden considerar otras métricas para determinar el nodo preferido, como el nivel de actualización del secundario respecto al primario y al nodo del snapshot previamente elegido.Una vez que el proceso determina el nodo de origen para la instantánea, el proceso de respaldo abre
mongodun$backupCursoren el nodo de destino.El
$backupCursor, un mecanismo a nivel de motor de almacenamiento, permite que los archivos de la base de datos en almacenamiento se copien en un estado coherente, mientras aún se aceptan escrituras.La función de copia de seguridad del Agente de MongoDB copia y procesa estos archivos de datos.
La función de copia de seguridad de MongoDB Agent envía los archivos de datos a Ops Manager.
El proceso de copia de seguridad recopila y transfiere estos archivos al almacén de instantáneas que elija para guardar su copia de seguridad. Según el almacén de instantáneas que elija, una instantánea puede escribirse como:
Bloques a un almacenamiento en bloques. Fragmentos binarios escritos en una base de datos MongoDB en el host de Ops Manager.
Se bloquea a un bucket de AWS S3 . Los metadatos de esos bloques se escriben en una base de datos MongoDB en el host de Ops Manager.
Archivos snapshot en un file system store. El daemon de copias de seguridad que posee la tarea de copia de seguridad para la réplica crea una snapshot completa combinando los bloques modificados y los nuevos con los bloques no cambiados de la última snapshot. Si el daemon de copias de seguridad que posee la tarea de copia de seguridad está inactivo, necesitas recuperar el daemon de copias de seguridad o mover la base de datos principal a otro demonio.
Nota
Para obtener más información sobre las características de cada método de almacenamiento, consulte Opciones de configuración de copia de seguridad.
Copia de seguridad inicial
El agente MongoDB habilitado para copia de seguridad se conecta y se autentica con las bases de datos asociadas con el trabajo de copia de seguridad.
La sincronización inicial comienza y entra en su fase
starting. La sincronización inicial es un estado de transición entre Inactive y Active. La Sincronización inicial pasa por una serie de fases que se muestran en la página Backup para mostrar el progreso. La copia de seguridad transmite los datos existentes a Ops Manager en paquetes comprimidos de documentos de 10 MB llamados "slices" (rebanadas). La copia de seguridad crea fragmentos en el momento en que se creó la snapshot. Ops Manager captura los datos insertados en la instancia por separado una vez que se inicia la snapshot.La fase
transferringcomienza cuando los fragmentos se transmiten y almacenan en el Oplog Store temporalmente en nombre del daemon de copias de seguridad. El servicio daemon de copias de seguridad no puede dedicarse exclusivamente a procesamiento el gran flujo de fragmentos de sincronización inicial en detrimento del procesamiento de otras tareas de copia de seguridad. La Oplog Store almacena los fragmentos hasta que el daemon de copias de seguridad pueda recuperarlos. La Oplog Store se crea cuando se genera el primer almacenamiento de snapshot.Mientras Backup transmite los datos, rastrea el registro de operaciones. Este rastreo recopila cualquier diferencia entre el estado de la base de datos de implementación al inicio de la copia de seguridad y su estado actual. Las entradas del registro de operaciones se envían en 10 paquetes comprimidos de MB, denominados fragmentos del registro de operaciones. Estos dos flujos de fragmentos se recopilan en paralelo para reducir el tiempo necesario para crear una instantánea completa.
La
buildingfase comienza una vez que Ops Manager recibe el primer lote de segmentos de sincronización iniciales. En esta fase, Ops Manager crea una versión local de la base de datos respaldada, denominada base de datos principal, en el host que ejecuta el servicio Backup Daemon.Ops Manager utiliza el servicio de daemon de copias de seguridad para insertar los documentos almacenados en Oplog Store en la base de datos principal.
La fase
applying oplogscomienza cuando Ops Manager aplica las entradas finales del Oplog en la base de datos principal.Durante la fase
fetching missing documents, Ops Manager ejecuta una query en la base de datos de implementación en busca de documentos que se hayan omitido durante la inserción de documentos. Ops Manager inserta los documentos faltantes encontrados en la base de datos de la implementación en la base de datos principal.Tras insertar los documentos faltantes, comienza la fase
creating indexes, en la que Ops Manager crea todos los índices encontrados en las bases de datos de implementación de la base de datos principal. Al finalizar los índices, finaliza la sincronización inicial y la fase cambia acomplete.Dependiendo de qué almacén de instantáneas elija para almacenar su instantánea, una instantánea se puede escribir como:
Bloques para un almacén de bloques.
Se bloquea a un bucket de AWS S3 . Los metadatos de esos bloques se escriben en una base de datos MongoDB en el host de Ops Manager.
Archivos de snapshot a un almacenamiento del sistema de archivos.
Nota
Las características de cada método de almacenamiento se abordan en Opciones de configuración de copia de seguridad.
Copias de seguridad posteriores
La base de datos principal funciona como una copia completa de la base de datos de implementación. Necesita que se le apliquen logs de operación de forma regular para mantener sus datos sincronizados con la base de datos de la implementación. Las snapshots se generan a partir de los datos almacenados en la base de datos principal de acuerdo con tu cronograma de snapshots.
Una vez completada la primera copia de seguridad completa, cada trabajo de copia de seguridad activo sigue este proceso:
La copia de seguridad sigue el registro de operaciones de la implementación.
La copia de seguridad agrupa rutinariamente nuevas entradas de oplog en porciones de oplog y las transfiere a Ops Manager.
Ops Manager almacena las entradas del oplog en el almacén de Oplog.
Ops Manager aplica las nuevas entradas de oplog de las particiones de oplog a la base de datos principal que almacena la copia de seguridad de la implementación.
Ops Manager crea una nueva snapshot y la almacena en el almacenamiento de snapshot según lo especificado en tu cronograma de snapshots.
Copia de seguridad regional
Puede asignar trabajos de copia de seguridad a regiones de implementación para facilitar el aislamiento de datos. Al asignar un trabajo de copia de seguridad a una región de implementación, Ops Manager escribe todas las instantáneas, registros de operaciones y datos de sincronización que genera el trabajo en el almacenamiento correspondiente configurado para esa región. La copia de seguridad regional está disponible para conjuntos de réplicas y clústeres fragmentados. Para habilitar la copia de seguridad regional en un clúster fragmentado, debe asignar regiones de implementación e iniciar trabajos de copia de seguridad para cada fragmento por separado.
Para determinar si la copia de seguridad regional está habilitada en tu implementación, puedes comprobar lo siguiente en el tablero de Continuous Backup.
Backup Region en la esquina superior derecha se muestra la región de implementación del grupo de forma predeterminada y, si el proyecto está habilitado para copia de seguridad regional, muestra la leyenda Multi-Region.
Regional Backup La columna se muestra en el tablero.