MongoDB Ops Manager puede almacenar copias de seguridad, incluidos snapshots y oplogs, en un almacenar de objetos compatible con S3 o S3escribiendo los datos de copia de seguridad como bloques en un cubo S3 y realizando un seguimiento de los metadatos en la base de datos de la aplicación de MongoDB Ops Manager. Con copias de seguridad inmutables de S3, MongoDB Ops Manager se integra con S3 bloqueo de objetos o un equivalente para proporcionar las siguientes capacidades:
Almacene los datos de la copia de seguridad y los metadatos de la copia de seguridad juntos en el cubo S3.
Proteger los objetos de copia de seguridad contra la eliminación o modificación hasta que expire un período de retención definido, aplicado al almacenar objetos.
Importe una cadena completa de restauración a un punto específico del tiempo, snapshot y oplog juntos, desde un bucket con bloqueo de objetos habilitado en una implementación nueva o reconstruida de MongoDB Ops Manager para recuperación ante desastres o migración.
Usa esta funcionalidad para proteger las copias de seguridad contra supresiones maliciosas o accidentales, como ataques de ransomware o errores del operador. Puede restaurar las copias de seguridad en una nueva instancia de Ops Manager utilizando solo lo que almacene en S3.
Esta guía cubre copias de seguridad inmutables S3 para implementaciones de MongoDB Ops Manager que instala y gestiona directamente en un host. Si implementa MongoDB Ops Manager mediante el MongoDB Controllers for Kubernetes operador (MCK), consulte el ejemplo de especificación de recurso de Ops Manager.
Importante
MongoDB Ops Manager admite snapshots inmutables S3 a partir de la versión 8.0.19. Los oplogs inmutables S3, que amplían esta protección para admitir la restauración a un punto específico del tiempo a partir de una copia de seguridad totalmente inmutable e importable, requieren la versión 9.0 o la 8.0.28.
Cómo funciona la copia de seguridad inmutable S3
Después de configurar un almacenamiento de snapshot S3 con un bucket habilitado para Object-Lock y activar copias de seguridad inmutables:
Ops Manager escribe bloques de instantáneas y los metadatos necesarios para la restauración en el bucket S3, en lugar de mantener los metadatos solo en la base de datos de la aplicación Ops Manager.
Si se configura, Ops Manager amplía la retención de Object Lock para cada snapshot para que el almacenamiento de objetos evite la eliminación o modificación antes de que finalice la ventana de retención de la tarea de copia de seguridad.
Ops Manager puede descubrir e importar estas instantáneas inmutables desde un bucket previamente llenado a otra instancia de Ops Manager leyendo solo lo que almacena el bucket S3.
Si también configura un almacén oplog S3 con el bloqueo de objeto habilitado:
MongoDB Ops Manager guarda segmentos de oplog y los metadatos necesarios para la restauración en el bucket del almacenar de oplog S3, de la misma manera que lo hace con los datos de snapshot.
El MongoDB Agent solo rastrea entradas de oplog confirmadas por la mayoría para esa tarea de copia de seguridad, por lo tanto, MongoDB Ops Manager nunca realiza una copia de seguridad de una entrada de oplog que un rollback posterior podría remover.
MongoDB Ops Manager puede detectar e importar estos oplogs inmutables, junto con un snapshot inmutable importado, en otra instancia de MongoDB Ops Manager para admitir la restauración a un punto específico del tiempo desde la copia de seguridad importada.
Requisitos previos
Para usar copias de seguridad inmutables de S3, asegúrese de tener lo siguiente:
Ops Manager 8.0.19 o posterior para snapshots inmutables. Los oplogs inmutables adicionalmente requieren la versión 9.0 o 8.0.28.
S3 almacenamiento de snapshot (almacenamiento en bloques) configurado en Ops Manager. Los snapshots inmutables admiten únicamente almacenes de snaps S3; no admiten bloqueos de MongoDB ni almacenes de snaps de sistema de archivos.
Almacenar objetos que admita objeto bloqueo, como AWS S3 o dispositivos compatibles, con objeto bloqueo habilitado en el bucket que utilice para el almacenamiento. La mayoría de los proveedores de S3 requieren el control de versiones de objetos para que funcione el bloqueo de objetos, y algunos proveedores solo permiten el bloqueo de objetos durante la creación de depósitos.
Requisitos estándar de copia de seguridad, como un MongoDB Agent con copia de seguridad habilitada en nodos adecuados y un oplog (registro de operaciones) para almacenar PITR.
Un bucket S3 con bloqueo de objetos habilitado para su almacenamiento de snapshot. El bucket no necesita ser nuevo y no necesita estar dedicado a este almacenar, aunque se recomienda un bucket dedicado. No puede habilitar el bloqueo de objetos en la configuración de un almacenamiento de snapshot S3 existente en MongoDB Ops Manager cambiando su configuración. Debe configurar un nuevo almacenamiento de snapshot S3 que apunte a un bucket con el bloqueo de objetos habilitado.
Si utiliza oplogs inmutables: un cubo S3 con control de versiones y bloqueo de objetos habilitado para su almacenar de oplog. El bucket no necesita ser nuevo y no necesita estar dedicado a este almacenar, aunque se recomienda un bucket dedicado. No se puede habilitar el bloqueo de objetos en la configuración de un almacén de oplog S3 existente en MongoDB Ops Manager cambiando su configuración. Debe configurar un nuevo almacenar de oplog S3 que punto a un cubo con control de versiones y Bloqueo de objetos habilitados.
Considerations
Cuando planifica copias de seguridad inmutables de S3, considere los siguientes elementos:
No retroactividad de inmutabilidad. Ops Manager solo protege los snapshots almacenados en un bucket con Object Lock después de que actives la copia de seguridad inmutable. Ops Manager no aplica Object Lock a los objetos de snapshot existentes.
Configuración de Object Lock. Ops Manager no proporciona inmutabilidad para los buckets de S3 que no admiten Object Lock. Debe configurar Object Lock en el bucket por separado. Configurar los ajustes de Bloqueo de Objetos en Ops Manager o actualizar la configuración del bucket después de su creación no habilita el Bloqueo de Objetos en el bucket.
No hay migración automática de los datos existentes. La funcionalidad Migrar copia de seguridad entre almacenes S3 permite cambiar el almacenamiento de snapshot S3 que una tarea de copia de seguridad utiliza para snapshots futuros. No se copian ni mueven los datos de instantáneas existentes entre los buckets.
Retención y bloqueo de objetos en almacenes gestionados. Cuando una instantánea caduca según la política de retención de trabajos de copia de seguridad, Ops Manager deja de mostrarla e intenta eliminar los objetos relacionados. Ops Manager solo puede eliminar los objetos una vez que expire el período de retención del bloqueo de objetos. Si el almacén de objetos rechaza una eliminación, por ejemplo, porque un objeto aún está en retención, el trabajo de mantenimiento no falla. Ops Manager pone en cola los objetos que no puede eliminar, y el demonio de copia de seguridad vuelve a intentar la eliminación cada
mms.backup.groom.failedDeleteRetryDelayHourshoras hasta que el almacén de objetos lo permita.Retención en almacenes importados. Ops Manager nunca borra datos del cubo S3 del que importó. MongoDB Ops Manager puede borrar los metadatos que importó en su propia base de datos de la aplicación. La retención solo afecta a la visibilidad de los metadatos en MongoDB Ops Manager.
No inmutabilidad retroactiva del oplog. Puede habilitar el bloqueo de objetos solo cuando cree un almacenar oplog S3. No puede habilitar el Bloqueo de objetos en un almacenar oplog S3 existente cambiando su configuración; debe crear un nuevo almacenar en su lugar.
El anclaje de versión de oplog está desactivado por defecto. Por defecto, MongoDB Ops Manager no utiliza la versión exacta del objeto S3 que registró cuando lee un oplog slice de vuelta de un almacenar de oplog inmutable. La configuración de la aplicación
brs.oplogStoreFallBackToLatestVersionpor defecto estrue, lo que hace que Ops Manager siempre recupere la última versión del objeto en lugar de la versión que registró. Para exigir que MongoDB Ops Manager utilice la versión exacta registrada, un administrador global debe establecerbrs.oplogStoreFallBackToLatestVersionenfalse.Requisito de topología de confirmación por mayoría para el seguimiento de oplog. Ops Manager solo sigue entradas de oplog confirmadas por la mayoría para almacenar oplog habilitado para bloqueo de objetos, ya que el bloqueo de objetos significa que Ops Manager nunca puede deshacer o cambiar datos ya escritos en almacenar. En una topología PSA con el secundario inactivo, o una topología PAA, la cola del oplog nunca puede alcanzar la confirmación de la mayoría, por lo tanto, el seguimiento se detiene hasta que la topología se recupere. MongoDB Ops Manager genera una alerta indicando la causa y la solución cuando esto ocurre.
Advertencia
Ops Manager no lee la moda o período de retención real de su bucket, para los almacenes de snapshot o oplog. Si los valores de retención que configuró en MongoDB Ops Manager no coinciden con la configuración de retención que configuró directamente en el bucket S3, sus copias de seguridad podrían no estar protegidas contra la eliminación o modificación, y las tareas de limpieza de MongoDB Ops Manager pueden fallar si el bucket aplica una retención que MongoDB Ops Manager desconoce.
Configurar almacenamiento de snapshots inmutables
Para configurar el almacenamiento de snapshot inmutable, complete las siguientes tareas:
Activa las copias de seguridad inmutables en Ops Manager.
Prepare un cubo S3 habilitado para objeto-bloqueo.
Configure un nuevo almacenamiento de snapshot S3 en Ops Manager.
Habilitar copias de seguridad inmutables
Un ajuste de la aplicación controla las copias de seguridad inmutables. Un administrador global debe habilitar esta configuración antes de configurar un almacenamiento de snapshot S3 con bloqueo de objetos.
Agregar la configuración de la aplicación de copia de seguridad inmutable.
Haz clic en la pestaña Custom.
Haga clic en + Add Option.
En el campo Key, introduce
brs.immutableBackupEnabled.En el campo Value, introduce
true.Haga clic en Save.
Esta configuración habilita la inmutabilidad de los snapshots S3 para los almacenar respaldados por cubos habilitados para objeto-bloqueo. Ops Manager aplica esta configuración inmediatamente. No es necesario reiniciar MongoDB Ops Manager.
Nota
También puede establecer brs.immutableBackupEnabled en true en conf-mms.properties en lugar de usar la Interfaz de Usuario de Administración. Si configura el ajuste en ambos lugares, MongoDB Ops Manager utiliza el valor conf-mms.properties.
Preparar un cubo S3 habilitado para bloqueo de objetos
Habilitar el bloqueo de objetos.
Habilite el bloqueo de objetos en el bucket. Según su proveedor, puede hacerlo durante la creación del bucket o después. La mayoría de los proveedores de S3 requieren el versionado de objetos para que funcione el bloqueo de objetos, y algunos proveedores permiten el bloqueo de objetos solo durante la creación de depósitos.
(Opcional) Configurar guardados condicionales en el bucket.
Ops Manager utiliza por defecto el soporte de guardar condicional de su bucket para reducir el espacio de almacenamiento que utilizan los metadatos de snapshot inmutables. Configure su bucket para que admita escrituras condicionales.
Importante
Es recomendable la compatibilidad con guardar condicional, pero no es obligatoria. Si su cubo no admite guardar condicionales, MongoDB Ops Manager sigue protegiendo sus snapshot con bloqueo de objetos, pero el cubo puede crecer a un ritmo inesperado.
Configurar la retención por defecto.
Configure una moda de retención por defecto (GOVERNANCE o COMPLIANCE) y un período en su almacén de objetos. MongoDB Ops Manager no establece encabezados de retención de bloqueo de objetos en objetos individuales, por lo tanto, la configuración de retención por defecto de su bucket es lo que realmente protege sus datos. Sin una retención por defecto configurada en el cubo, Bloqueo de objetos no protege sus objetos de la eliminación o modificación.
Nota
No puede habilitar el bloqueo de objetos para una configuración existente de almacenamiento de snapshot S3 en MongoDB Ops Manager. Si ya utiliza un bucket S3 para copias de seguridad, pero necesita snapshot inmutables, habilite el bloqueo de objetos en ese bucket si su proveedor lo permite, o apunte a un bucket diferente que ya tenga el bloqueo de objetos habilitado, y configure un nuevo almacenamiento de snapshot S3.
Configure un nuevo almacenamiento de snapshot S3 en Ops Manager
Cree un nuevo almacenamiento de snapshot S3.
Siga el procedimiento Agregar un almacenamiento de snapshot compatible con S3 para crear un nuevo almacenamiento de snapshot S3 que apunta al bucket con bloqueo de objetos habilitado. Especifique el nombre del bucket, el punto final, la región y las credenciales según lo requiera su proveedor de S3.
Establecer Object Retention Mode.
Seleccione el modo de retención de Bloqueo de objetos, GOVERNANCE o COMPLIANCE, que Ops Manager aplica a los objetos de este almacén de instantáneas. Al guardar el almacén, Ops Manager valida el comportamiento de Bloqueo de objetos del bucket mediante objetos de prueba temporales. Sin embargo, Ops Manager no lee la configuración de Bloqueo de objetos del bucket, por lo que no puede detectar una discrepancia entre el modo que seleccione aquí y el modo configurado en el bucket. Debe configurar manualmente este campo para que coincida con el modo de retención configurado en el bucket.
Importante
Puede seleccionar Object Lock Enabled solo cuando cree un nuevo almacenamiento de snapshot S3. No puede cambiar esta configuración después de guardar el almacenar. Puede cambiar Object Retention Period (Days) y Object Retention Mode en cualquier momento.
Este almacenamiento de snapshot sirve como objetivo para snapshots inmutables. Ops Manager escribe tanto los bloques de snapshot como los metadatos para las copias de seguridad que utilizan este almacenamiento en el bucket.
Nota
Si gestiona MongoDB Ops Manager con MongoDB Enterprise Kubernetes Operator, también debe habilitar el bloqueo de objetos en la entrada s3Stores correspondiente de su recurso MongoDBOpsManager. Establezca el campo spec.backup.s3Stores[].objectLockEnabled en true para que Kubernetes operador concilie Ops Manager con la detección de bloqueo de objetos.
Sigue siendo necesaria una instancia de MongoDB que funcione como almacén de metadatos para las operaciones de Ops Manager.
Configurar almacenamiento oplog inmutable
Para configurar almacenamiento oplog inmutable, complete las siguientes tareas:
Habilite las copias de seguridad inmutables en MongoDB Ops Manager, si aún no lo ha hecho.
Preparar un bucket S3 versionado y habilitado para bloqueo de objetos.
Configure un nuevo almacenar de oplog S3 en MongoDB Ops Manager.
Cambiar las tareas de copia de seguridad existentes al almacenar de oplog S3 inmutable.
Habilitar copias de seguridad inmutables
Este paso utiliza la misma configuración de la aplicación MongoDB Ops Manager que el almacenamiento de snapshots inmutables. Si ya ha completado Habilitar copias de seguridad inmutables mientras configura el almacenamiento de snapshot inmutable, omita este paso.
Preparar un bucket S3 con versiones y con bloqueo de objetos habilitado
Prepare un bucket para su almacenar de oplog inmutable.
Habilitar el control de versiones y el bloqueo de objetos.
A diferencia de un almacenar oplog estándar, un almacenar oplog inmutable requiere que tanto el control de versiones como el bloqueo de objeto estén habilitados en el bucket. Según su proveedor, puede habilitar estas opciones durante la creación del bucket o después.
(Opcional) Configurar guardados condicionales en el bucket.
MongoDB Ops Manager utiliza por defecto la compatibilidad de guardar condicional de su bucket para reducir el espacio de almacenamiento que utilizan los metadatos inmutables de la copia de seguridad. Configure su bucket para que admita escrituras condicionales.
Importante
Es recomendable la compatibilidad con guardar condicional, pero no es obligatoria. Si su cubo no admite guardar condicionalmente, MongoDB Ops Manager sigue protegiendo sus oplogs con bloqueo de objetos, pero el cubo puede crecer a un ritmo inesperado.
Configurar la retención por defecto.
Configure una moda de retención por defecto (GOVERNANCE o COMPLIANCE) y un período en su almacén de objetos. MongoDB Ops Manager no establece encabezados de retención de bloqueo de objetos en objetos individuales, por lo tanto, la configuración de retención por defecto de su bucket es lo que realmente protege sus datos. Sin una retención por defecto configurada en el cubo, Bloqueo de objetos no protege sus objetos de la eliminación o modificación.
Nota
No puede habilitar el bloqueo de objetos para la configuración para almacenar oplog S3 existente en MongoDB Ops Manager. Si ya utiliza un bucket S3 para el almacenamiento de oplog, pero necesita oplogs inmutables, habilite el control de versiones y el bloqueo de objetos en ese bucket si su proveedor lo permite, o apunte a un bucket diferente que ya tenga ambos habilitados, y configure un nuevo almacén de oplog S3.
Configurar un nuevo repositorio de oplog S3 en MongoDB Ops Manager
Configure el nuevo bucket como un S3 oplog almacenar.
Cree un nuevo almacenar de oplog S3.
Siga el procedimiento Agregar un almacenar de oplog compatible con S3 para crear un nuevo almacenar de oplog S3 que punto al bucket con versiones y con bloqueo de objetos habilitado. Especifique el nombre del bucket, el punto de conexión, la región y las credenciales según lo requiera su proveedor de S3.
Establecer Object Retention Period (Days).
Introduzca el número de días que Ops Manager protege los objetos de cada segmento de oplog con Bloqueo de objetos. Este valor debe coincidir con el período de retención que configuró directamente en el bucket. Este campo no modifica la configuración de retención del bucket S3, y Ops Manager no lee la configuración de Bloqueo de objetos del bucket, por lo que no puede detectar una discrepancia entre este campo y el período de retención del bucket. Debe configurar manualmente este campo para que coincida con el modo de retención que configuró en el bucket.
Importante
Recomendamos establecer este campo. Si lo deja en blanco, MongoDB Ops Manager no tiene registro de cuándo expira realmente el período de retención de su bucket. MongoDB Ops Manager intenta borrar un objeto tan pronto como su propia lógica de depuración lo considere apto, y el depósito S3 rechaza ese borrado hasta que finalice su período de retención. MongoDB Ops Manager sigue reintentando borrar hasta que el bucket lo permita.
Establecer Object Retention Mode.
Seleccione el modo de retención de Bloqueo de objetos, GOVERNANCE o COMPLIANCE, que Ops Manager aplica a los objetos de este almacén de oplog. Recomendamos configurar este campo. Al guardar el almacén, Ops Manager valida el comportamiento de Bloqueo de objetos del bucket mediante objetos de prueba temporales. Sin embargo, Ops Manager no lee la configuración de Bloqueo de objetos del bucket, por lo que no puede detectar una discrepancia entre el modo que configure aquí y el modo configurado en el bucket. Debe configurar manualmente este campo para que coincida con el modo de retención configurado en el bucket.
Importante
Puede seleccionar Object Lock Enabled solo cuando cree un nuevo almacenar de oplog S3. No puede cambiar esta configuración después de guardar el almacenar. Puede cambiar Object Retention Period (Days) y Object Retention Mode en cualquier momento.
Este almacenar de oplog sirve como destino para copias de seguridad inmutables de oplog. MongoDB Ops Manager guarda tanto las porciones de oplog como los metadatos para las copias de seguridad que utilizan para almacenar en el bucket.
Cambiar trabajos de copia de seguridad existentes al almacenar de oplog inmutable S3
Para reasignar una tarea de copia de seguridad existente al almacenar de oplog inmutable S3, utilice etiquetas de asignación:
Añadir una etiqueta al almacenar de oplog inmutable S3.
Siga el procedimiento Editar un almacenar oplog compatible con S3existente para agregar una etiqueta al almacenar oplog inmutable S3.
Importante
Las restauraciones de PIT no están disponibles hasta que MongoDB Ops Manager tome el siguiente snapshot después de la reasignación.
Verificar inmutabilidad
MongoDB Ops Manager guarda automáticamente los datos de cada snapshot y los metadatos de Objeto Bloqueo que los protegen en el bucket S3. No necesita exportar los datos manualmente. Utilice el siguiente procedimiento para confirmar que un snapshot específico está protegido por el bloqueo de objetos.
Para confirmar que un almacenar oplog S3 tiene el bloqueo de objetos habilitado, vaya a la página de almacenamiento oplog y compruebe la configuración de ese almacenar.
Importar instantáneas para recuperación ante desastres
Si necesita restaurar datos desde un bucket S3 preexistente que contiene snapshots inmutables y metadatos de copia de seguridad, puede importar esos snapshots a una implementación de Ops Manager. Utilice este flujo de trabajo para escenarios de recuperación ante desastres, como restaurar copias de seguridad tras reconstruir Ops Manager.
Importante
Las instantáneas importadas son solo para operaciones de restauración única. Ops Manager no gestiona el ciclo de vida de las snapshots importadas ni las incluye en los cronogramas de copia de seguridad activos.
Seleccione o añada el cubo S3 externo.
Seleccione un bucket existente o seleccione Add S3 bucket para definir uno nuevo. El nombre del bucket y el punto de conexión S3 deben coincidir con los valores configurados en el almacenar S3 del snapshot.
Importante
El formulario Add S3 bucket solicita los mismos campos que el procedimiento Agregar un almacenamiento de snapshot compatible con S3, incluido un tipo de almacén de datos y una lista de hosts de MongoDB o URI. Estos campos deben apuntar al almacén de metadatos dedicado para este bucket, no a la implementación de MongoDB que está restaurando.
Seleccione los snapshot para importar.
Seleccione los snapshot o clustershots que desea importar del bucket.
Importante
Para un clustershot con particiones almacenadas en diferentes depósitos, importe el depósito de cada partición por separado. Agregue cada bucket adicional y seleccione las particiones de ese bucket, un bucket a la vez, hasta que importe todas las particiones del clustershot.
MongoDB Ops Manager no hace restaurable la instantánea de clúster y no la muestra en la página Continuous Backup hasta que importe todas sus particiones.
Una vez finalizada la importación, los snapshot importados aparecerán en la página Continuous Backup en el Proyecto al que los asignó. MongoDB Ops Manager muestra solo clustershots que se han importado por completo.
MongoDB Ops Manager nunca borra ni realiza la limpieza de datos del bucket S3 desde el que importó. Usted controla el ciclo de vida de los objetos snapshot importados en la capa de almacenamiento de objetos. MongoDB Ops Manager puede borrar los metadatos que importó en su propia base de datos de la aplicación.
Importar Oplogs para la recuperación ante desastres
Si necesita restaurar datos a un punto específico del tiempo desde un bucket S3 preexistente que contenga oplogs inmutables, puede importar esos oplogs en una implementación de MongoDB Ops Manager. Debe importar primero el snapshot correspondiente. Ops Manager solo puede detectar oplogs para un clúster que ya tiene un snapshot importado.
Importante
Si falta un archivo de metadatos que aparece en el bucket cuando Ops Manager intenta importarlo, Ops Manager omite ese archivo, registra una advertencia y sigue informando de la tarea de importación como SUCCEEDED. Esto puede dejar una brecha en el rango de tiempo restaurable que solo aparece más tarde, como un rechazo, cuando intente una restauración a un punto específico del tiempo a través de esa brecha.
Haga clic en Import Oplogs en la fila correspondiente.
Go a la página Imported Snapshots (Admin, Backup, Imported Snapshots).
Para la fila del snapshot que ya importó, haga clic en el menú de puntos suspensivos (Actions).
Haga clic en Import Oplogs.
Esto abre el cuadro de diálogo Import Oplogs en la pestaña S3 Buckets.
Seleccione o añada el bucket S3 que contiene los oplogs.
Seleccione un bucket existente de la lista Select an S3 bucket y, a continuación, haga clic en Next. O seleccione Add S3 bucket para registrar uno nuevo, luego haga clic en Save para registrar el bucket y continuar.
Importante
El formulario Add S3 bucket solicita los mismos campos que el procedimiento Agregar un almacenamiento de snapshot compatible con S3, incluidos un tipo de almacén de datos y un URI de MongoDB.
También debe marcar la casilla de verificación que reconoce que MongoDB no admite problemas causados por su solución de almacenamiento compatible con S3antes de que MongoDB Ops Manager guarde el bucket.
Una vez finalizada la importación, MongoDB Ops Manager muestra una acción Manage Oplogs en esa fila, donde puede ver o borrar los oplogs importados.
Interacciones con PITR
PITR combina un snapshot de línea de base con datos de oplog almacenados en un almacenar de oplog. Los snapshots inmutables solo afectan al componente de snapshot de referencia:
Cuando cambie a un almacenamiento de snapshot S3 inmutable, PITR sigue funcionando a partir de snapshots existentes y datos de oplog. Las snapshot antiguas permanecen en su almacén original, y la configuración del almacén oplog no cambia.
Una vez que el primer snapshot inmutable completo se haya completado en el nuevo almacenar, PITR puede utilizar ese snapshot como base y seguir rastreando oplogs desde su almacenar de oplogs configurado.
PITR de un snapshot importado solo está disponible si también importa los oplogs inmutables correspondientes. De lo contrario, solo puede realizar una restauración de un snapshot importado hasta el punto exacto en que Ops Manager creó el snapshot.
Importante
Para una protección completa de inmutabilidad, utilice un almacenamiento de oplog con bloqueo de objetos habilitado junto con un almacenamiento de snapshot con bloqueo de objetos habilitado. Por defecto, Ops Manager no aplica este emparejamiento: una tarea de copia de seguridad puede usar un almacenamiento de snapshot inmutable con un almacenamiento de oplog estándar, y PITR sigue funcionando con esa combinación. Para requerir el emparejamiento, un administrador global debe habilitar la configuración de la aplicación mms.backup.enforceObjectLockOplogsOnObjectLockSnapshot. MongoDB Ops Manager desactiva esta configuración por defecto. Para crear un almacenar de oplog habilitado para bloqueo de objetos, siga el procedimiento Agregar un almacenar de oplog compatible con S3.
Cuando habilita el Bloqueo de objetos en un almacenar de oplog, el MongoDB Agent solo sigue las entradas de oplog confirmadas por la mayoría para esa tarea de copia de seguridad. Una entrada confirmada por la mayoría no se puede revertir, por lo que este comportamiento evita que MongoDB Ops Manager haga una copia de seguridad de una entrada de oplog que un rollback posterior podría remover.
Escenarios de falla y recuperación
Los instantáneos inmutables S3 no generan escenarios adicionales de pérdida de datos cuando se cambia de almacén de instantáneos. Cada snapshot se restaura desde una única tienda, por lo que la lógica de restauración no requiere datos de múltiples buckets para un solo snapshot.
Fallo antes de la primera snapshot en la nueva tienda
Todas las instantáneas existentes permanecen en el almacén S3 original y se pueden restaurar completamente.
PITR funciona a partir del snapshot completado más reciente y los datos de oplog.
Fallo durante el primer Snapshot completo en la nueva tienda
Ops Manager marca la snapshot en curso para la nueva almacenar como fallida o incompleta y no la utiliza para restauraciones.
La última snapshot exitosa en el almacenamiento original sigue siendo la última snapshot que se puede restaurar.
Después de que Ops Manager y el clúster se recuperen, Ops Manager programa una nueva snapshot completa en el almacén inmutable en la próxima ventana de snapshot.
Debido a que la primera snapshot en la nueva tienda es siempre una snapshot completa y cada snapshot se restaura desde una sola tienda, la lógica de restauración no depende de la mezcla de datos de múltiples ''S3 buckets'' para una sola snapshot.