Restore Overview

Rangos de tiempo restaurables y brechas de oplog

Cuando solicita una restauración a un punto específico del tiempo, el cuadro de diálogo de restauración muestra el restorable time ranges para la implementación seleccionada. Estos rangos representan los períodos para los que Cloud Manager tiene un historial de oplog completo y continuo. Solo puede elegir un tiempo de restauración que se encuentre dentro de uno de estos rangos.

Las brechas de Oplog pueden ocurrir en las siguientes situaciones:

• El seguimiento del oplog se detiene por un problema con una tarea de copia de seguridad que sigue el oplog y el oplog se reinicia antes de que el MongoDB Agent lo siga de nuevo.

• Se produce un cambio de topología hasta que Cloud Manager complete una nueva snapshot.

• Se produce un cambio de compatibilidad de características entre versiones hasta que Cloud Manager complete una nueva snapshot. No puedes aplicar una restauración a un punto específico del tiempo en los cambios de versión de MongoDB.

• Una restauración se completa hasta que Cloud Manager completa una nueva snapshot.

Si el tiempo de restauración que necesita no está disponible en el cuadro de diálogo, investigue los cambios recientes de topología o compatibilidad de características entre versiones y revise el historial de tareas de copia de seguridad para comprender por qué ese período no se puede restaurar.

Por ejemplo, el cuadro de diálogo de restauración podría mostrar estos rangos de tiempo restaurables:

• June 8th 13:45:03 to June 8th 17:45:03

• June 8th 19:45:03 to June 9th 07:45:03

En este caso, no puede restaurar en ningún momento entre June 8th 17:45:03 y June 8th 19:45:03 porque existe una brecha de oplog durante ese período.

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.

• Configura los roles de Administrador de copia de seguridad y Administrador de Automatización en Cloud Manager.

• Para clústeres fragmentados que ejecutan compatibilidad de características entre versiones 4.0 o anteriores, habilite puntos de control.

• Compruebe que el featureCompatibilityVersion del clúster de destino sea 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.

• Revisa la siguiente matriz de compatibilidad para el clúster de origen compatible compatibilidad de características entre versiones de cada versión de MongoDB. La versión de MongoDB de cada host en el clúster de destino debe soportar la compatibilidad de características entre versiones del snapshot del clúster de origen.

Restaurar a un proyecto diferente

Puede elegir restaurar en un clúster de un proyecto diferente:

• Para restaurar en otro proyecto de Cloud Manager, debes tener los roles de Administrador de automatización o Administrador de copias de seguridad para el proyecto objetivo.

• 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.engine
• storage.directoryPerDB

• storage.mmapv1.nsSize

• storage.mmapv1.smallFiles

• storage.wiredTiger.collectionConfig.blockCompressor
• storage.wiredTiger.engineConfig.directoryForIndexes

No existe ningún método para comprobar si hay discrepancias antes de intentar una restauración. Si un intento de restauración falla, Cloud Manager muestra cualquier configuración no coincidente. 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.

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:

• Set de réplicas
• Clúster fragmentado

Requisitos previos

Para realizar restauraciones manuales, debe tener el rol de administrador de Copias de seguridad en Cloud Manager.

Restaurar formato de archivo

Cloud Manager proporciona cada snapshot como un fichero no comprimido (.tar) que contiene una copia completa del directorio de datos.

• Para un conjunto de réplicas, Cloud Manager proporciona una snapshot que debes copiar en cada miembro del conjunto de réplicas.

• Para un clúster en particiones, Cloud 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 una única base de datos o colección utilizando un respaldo consultable
• Restaurar un set de réplicas
• Restaurar una restauración de un clúster

Restaurar flujos de proceso

Puedes restaurar a partir de una snapshot 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.