Para restaurar una implementación desde una copia de seguridad, seleccione una instantánea o un punto en el tiempo desde el que desee restaurar la base de datos. Ops Manager le proporciona los archivos desde los que puede restaurar la base de datos.
Puede restaurar una sola base de datos MongoDB, un conjunto de réplicas o todos los fragmentos en un clúster fragmentado.
Puede restaurar una implementación desde una instantánea existente o desde un punto específico en el tiempo. Para el punto específico en el tiempo, puede especificar una fecha y hora, una marca de tiempo del registro de operaciones o una punto de control para un clúster fragmentado.
Si está restaurando desde un punto en el tiempo, debe descargar la Utilidad de restauración de copia de seguridad de MongoDB en su host de destino. MBRU solicita y aplica entradas de oplog entre la última instantánea completa y el punto en el tiempo que usted elija.
Para restaurar tu copia de seguridad, utiliza una de estas opciones:
Restaurar los archivos a otro clúster mediante automatización
Copie manualmente los archivos restaurados a los hosts que elija
Cancelar una restauración
Para cancelar una restauración:
Navegar hasta el Backup > pestaña Restore History.
Haga clic en Cancel.
Restauración automatizada
Si elige que la automatización de Ops Manager restaure su copia de seguridad, la automatización elimina todos los datos existentes de los hosts de destino y reemplaza esos datos con nuevos datos de copia de seguridad de su instantánea.
Limitaciones
Si está restaurando un clúster fragmentado, debe restaurar todos los fragmentos. El proceso de restauración falla si intenta restaurar un solo fragmento en un clúster fragmentado.
Requisitos previos
Para realizar restauraciones automáticas:
Instale un agente MongoDB en el origen y en todos los hosts de destino, y verifique que un agente MongoDB en la implementación de destino pueda conectarse a todos los hosts en la implementación de destino.
Configure los roles de administrador de respaldo y administrador de automatización en Ops Manager.
Para clústeres fragmentados que ejecutan compatibilidad de características entre versiones 4.0 o anteriores, habilite puntos de control.
Compruebe que el clúster de destino
featureCompatibilityVersiones mayor o igual que elfeatureCompatibilityVersiondel clúster de origen.Ejemplo
Ejecute el siguiente comando para recuperar el
featureCompatibilityVersionde un host determinado:db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) Para obtener más información, consulte setFeatureCompatibilityVersion.
Revise la siguiente matriz de compatibilidad para cada versión de MongoDB del clúster de origen compatible. La versión de MongoDB de cada host del clúster de destino debe ser compatible con la FCV de la instantánea del clúster de origen.
Clúster de origen FCVMongoDB3.4MongoDB3.6MongoDB4.0MongoDB4.2MongoDB4.4MongoDB5.0MongoDB6.03.2
3.4
3.6
4.0
4.2
4.4
5.0
6.0
Restaurar a un proyecto diferente
Puede optar por restaurar a un clúster de un proyecto diferente:
Para restaurar a otro proyecto de Ops Manager, debe tener roles de administrador de automatización o administrador de respaldo para el proyecto de destino.
Para restaurar a otro proyecto de MongoDB Atlas, debe tener el rol de Propietario del proyecto para el proyecto de destino.
Posibles causas de fallos en la restauración automática
Una restauración automática puede fallar cuando determinada configuración de almacenamiento de la base de datos de copia de seguridad y la base de datos de destino no coinciden:
storage.mmapv1.nsSizestorage.mmapv1.smallFiles
No existe ningún método para comprobar si hay discrepancias antes de intentar una restauración. Si falla un intento de restauración, Ops Manager muestra las configuraciones no coincidentes. Si aún desea restaurar la base de datos de la copia de seguridad, corrija las configuraciones de la base de datos de destino que no coincidan con la de la copia de seguridad y vuelva a intentar la restauración de la base de datos de la copia de seguridad.
Importante
MongoDB eliminó la compatibilidad con el1 motor de almacenamiento MMAPv en 4.2 MongoDB. Si edita la configuración de su implementación para cambiar el motor de almacenamiento a WiredTiger Storage Engine, Ops Manager reinicia los procesos de MongoDB.
Una restauración automática falla al intentar restaurar un solo fragmento en un clúster fragmentado. Si está restaurando un clúster fragmentado, debe restaurar todos los fragmentos.
Procedimientos de restauración
Para realizar una restauración automatizada, consulte el procedimiento para la implementación que desea restaurar:
Restauración manual
Requisitos previos
Para realizar restauraciones manuales, debe tener el rol de administrador de respaldo en Ops Manager.
Restaurar formato de archivo
Ops Manager proporciona cada instantánea como un archivo sin.tar comprimir () o comprimido.tar.gz () que contiene una copia de los archivos de su base de datos.
Elegir snapshots comprimidas resulta en una entrega más rápida, pero se requiere espacio suficiente en el host de destino tanto para la snapshot comprimida como para los archivos de base de datos extraídos.
Para un conjunto de réplicas, Ops Manager proporciona una instantánea que se copia en cada miembro del conjunto de réplicas.
Para un clúster, Ops Manager proporciona un snapshot para los servidores de configuración y un snapshot para cada partición.
Procedimientos de restauración manual
Para realizar una restauración manual, consulte:
Restaurar flujos de procesos
Puede restaurar desde una instantánea completa o desde un punto específico. Utilice las siguientes páginas para conocer los flujos del proceso de restauración manual.