Para restaurar una implementación a partir de una copia de seguridad, selecciona una snapshot o un punto en el tiempo desde el que desees restaurar tu base de datos. Ops Manager le proporciona los archivos a partir de los cuales puede restaurar su base de datos.
Puede restaurar una única base de datos de MongoDB, una set de réplicas, o todas las particiones en un clúster.
Puedes restaurar una implementación a partir de una snapshot existente o de un momento específico. Para el punto en el tiempo, puedes especificar una fecha y hora, una marca de tiempo de registro de operaciones (oplog), o un punto de control para un clúster fragmentado.
Si estás restaurando desde un punto de tiempo, debes descargar la Utilidad de Restauración de Copia de Seguridad de MongoDB en el host de destino. La MBRU solicita y aplica las entradas oplog entre la última snapshot completa y el punto en el tiempo que usted elija.
Para restaurar tu copia de seguridad, utiliza una de estas opciones:
Restaura los archivos a otro clúster utilizando la automatización
Copie manualmente los archivos restaurados en los hosts que usted elija
Cancelar una restauración
Para cancelar una restauración:
Navega hasta el Backup > Restore History tab.
Haga clic en Cancel.
Restauración automatizada
Si eliges que la automatización de Ops Manager restaure la copia de seguridad, la Automatización elimina todos los datos existentes de los hosts de destino y los reemplaza con nuevos datos de respaldo de tu snapshot.
Limitaciones
Si estás restaurando un clúster particionado, debes restaurar todas las particiones. El proceso de recuperación falla si intentas restaurar una única partición en un clúster particionado.
Requisitos previos
Para realizar restauraciones automatizadas:
Instala un MongoDB Agent en el origen y en todos los hosts de destino, y comprueba que un MongoDB Agent de la implementación de destino pueda conectarse a todos los hosts en la implementación de destino.
Configure los roles de Admin de Copia de Seguridad y Admin 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.
Verifica que el clúster de destino
featureCompatibilityVersiones mayor o igual que elfeatureCompatibilityVersiondel clúster de origen.Ejemplo
Ejecuta el siguiente comando para recuperar el
featureCompatibilityVersionde un host determinado:db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) Para saber más, consulta setFeatureCompatibilityVersion.
Consulta la siguiente matriz de compatibilidad para el clúster de origen compatible y cada versión de MongoDB. La versión de MongoDB de cada host en el clúster de destino debe ser compatible con la compatibilidad de características entre versiones del snapshot del clúster de origen.
clúster de origen FCVMongoDB4.2MongoDB4.4MongoDB5.0MongoDB6.0MongoDB7.04.2
4.4
5.0
6.0
7.0
Restaurar a un proyecto diferente
Puede elegir restaurar en un clúster de un proyecto diferente:
Para restaurar en otro proyecto de Ops Manager, debes tener los roles de Administrador de automatización o Administrador de copias de seguridad en el proyecto de destino.
Para restaurar en otro proyecto de MongoDB Atlas, debes tener el rol de Propietario del proyecto en el proyecto de destino.
Causas potenciales del fallo de restauración automatizada
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 un intento de restauración falla, Ops Manager muestra todas las configuraciones que no coinciden. Si aún deseas la restauración de la base de datos de la copia de seguridad, corrige los ajustes que no coincidan en la base de datos de destino y luego vuelve a intentar el proceso de restauración para la base de datos de la copia de seguridad.
Importante
MongoDB eliminó el soporte para el motor de almacenamiento MMAPv1 en MongoDB 4.2. Si edita la configuración de su implementación para cambiar su motor de almacenamiento a Motor de Almacenamiento WiredTiger, Ops Manager reiniciará los procesos de MongoDB.
Una restauración automatizada falla cuando se intenta restaurar una sola partición en un clúster particionado. Si estás restaurando un clúster particionado, debes restaurar todas las particiones.
Procedimientos de restauración
Para realizar una restauración automatizada, consulta el procedimiento para la implementación que deseas restaurar:
Restauración manual
Requisitos previos
Para realizar restauraciones manuales, debes tener el rol de Administrador de copias de seguridad en el Ops Manager.
Restaurar formato de archivo
Ops Manager proporciona cada snapshot como un fichero sin comprimir (.tar) 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 un snapshot que se copia a 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 manuales de restauración
Para realizar una restauración manual, consulta:
Restaurar flujos de proceso
Puede restaurar desde una instantánea completada o desde un punto específico en el tiempo. Utiliza las siguientes páginas para aprender los flujos del proceso de restauración manual.