Las copias de seguridad dependen de qué versión de MongoDB con la que es compatible tu base de datos. Para MongoDB 4.4, la compatibilidad de características entre versiones (compatibilidad de características entre versiones) puede ser 4.2 o 4.4. 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 programadas. Este proceso copia los archivos de datos de una implementación de MongoDB y los envía a través de la red mediante Ops Manager a su almacenamiento de instantáneas existente. Su implementación puede seguir gestionando 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
El proceso de copia de seguridad ya no utiliza sincronizaciones iniciales. Sin sincronizaciones iniciales, Ops Manager admite una gama más amplia de clientes, como aquellos que utilizan intensivamente la función renameCollection.
Nota
Integra con plataformas de copia de seguridad de terceros
Puede integrar Ops Manager con una plataforma de copia de seguridad de terceros compatible para habilitar las copias de seguridad y restauración de sus clústeres de MongoDB sin depender únicamente de las herramientas nativas de MongoDB. Para obtener más información, consulta Copia de seguridad y restauración con plataformas de terceros.
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.
Para las tareas de copia de seguridad en estado Active, Ops Manager garantiza que se conserve al menos una instantánea restaurable para cada implementación respaldada. Si las tareas de copia de seguridad recientes fallan y el período de retención configurado provocaría la expiración de todas las instantáneas existentes, Ops Manager pospone la optimización de la instantánea exitosa más reciente hasta que se complete una nueva copia de seguridad exitosa.
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. |
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 regional
Puede asignar tareas de copia de seguridad a Regiones de implementación para la regionalización de copia de seguridad para promover el aislamiento de datos. Cuando asignas una tarea de copia de seguridad a una región de implementación, Ops Manager guarda todas las snapshots, oplogs y datos de sincronización que la tarea genera en el almacenamiento relevante configurado para esa región. La copia de seguridad regional está disponible para sets de réplicas y clústeres. Para habilitar la copia de seguridad regional para un clúster particionado, se deben asignar regiones de implementación e iniciar tareas de copia de seguridad para cada partición 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.