Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Restore Overview

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 sola base de datos MongoDB, una conjunto de réplicaso todos los fragmentos de un clúster fragmentado.

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 oplog o un punto de control para un clúster particionado.

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 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

  • Restaurar a partir de un respaldo consultable

Para cancelar una restauración:

  1. Navega hasta el Backup > Restore History tab.

  2. Haga clic en Cancel.

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.

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.

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.

  • Compruebe que el clúster de destino featureCompatibilityVersion es mayor o igual que el featureCompatibilityVersion del clúster de origen.

    Ejemplo

    Ejecuta el siguiente comando para recuperar el featureCompatibilityVersion de 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 FCV
    MongoDB
    4.4
    MongoDB
    5.0
    MongoDB
    6.0
    MongoDB
    7.0
    MongoDB
    8.0

    4.4

    5.0

    6.0

    7.0

    8.0

Puede optar por restaurar en un clúster de un proyecto diferente dentro de la misma organización o en una diferente.

Para restaurar un proyecto de Ops Manager en otro proyecto, debe tener los roles de Propietario del proyecto,Administrador de automatización o Administrador de copias de seguridad para el proyecto de destino.

Nota

Si el clúster de origen utiliza cifrado de datos en reposo con un servidor KMIP, configure el clúster de destino para que utilice el mismo servidor KMIP. Si el servidor KMIP no está disponible en el clúster de destino, MongoDB no se iniciará después de la restauración.

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:

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.

Para realizar una restauración automatizada, consulta el procedimiento para la implementación que deseas restaurar:

Para realizar restauraciones manuales, debes tener el rol de Administrador de copias de seguridad en el Ops Manager.

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 realizar una restauración manual, consulte:

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.

Volver

restaurar

En esta página