Restaurar desde un punto en el tiempo específico

Considerations

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 durante los cuales Ops 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 MongoDB Ops Manager complete una nueva snapshot.

• Se produce un cambio de FCV hasta que Ops 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 Ops 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.

Puedes solicitar una restauración a un punto específico del tiempo que incluya datos antiguos.

Procedimiento

1. El usuario selecciona una marca de tiempo:

   • A través de la aplicación Ops Manager:

     1. Haz clic en una marca de tiempo.

     2. Envía su solicitud.

   • A través de la API:

     1. Encuentra el clúster que deseas restaurar.

     2. Crea una nueva tarea de restauración para ese clúster.

2. Ops Manager crea un documento RestoreJob.

3. Ops Manager configura el estado del documento RestoreJob como Transferring... e inicia la transmisión del snapshot en el formato solicitado desde el almacenamiento de snapshot hasta Ops Manager. Cada almacenamiento de snapshot transmite sus componentes de snapshots a través de Ops Manager:

   1. Un almacenamiento en bloques transmite bloques.

   2. Un almacenamiento de snapshot de S3 transmite los bloques.

4. Con el estado configurado en Waiting for Customer..., el Administrador de Operaciones crea una URL.

5. El usuario hace clic en el enlace get link, luego Download en la aplicación Ops Manager para descargar la snapshot.

6. El usuario descarga la Utilidad de Restauración de Copias de seguridad de MongoDB from the Ops Manager application al host de instantáneas de destino.

   Nota

   El MBRU puede utilizarse con cualquier restauración. Si la utilidad está instalada en el host donde se desea restaurar el snapshot, el usuario no necesita descargarla de nuevo.

7. El usuario inicia una instancia temporal de MongoDB en el host del snapshot de destino. El oplog recuperado se aplica al snapshot restaurada en esta instancia.

8. El usuario ejecuta el MBRU para solicitar el oplog.

9. El MBRU recupera el oplog para la snapshot en un momento determinado.

10. La MBRU aplica el oplog a snapshot en la instancia temporal de MongoDB.

11. El usuario exporta la base de datos restaurada desde la instancia temporal de MongoDB.