Restaurar un set de réplicas desde una snapshot

En MongoDB Cloud Manager, ve a Continuous Backup página para tu proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Haz clic en la pestaña Overview.

Haga clic en la implementación y luego en Restore or Download.

Selecciona el punto de restauración.

1. Elige el punto del que deseas restaurar tu copia de seguridad.

   Tipo de restauración	Descripción	Acción
   Snapshot	Permite elegir una snapshot almacenada.	Selecciona una snapshot existente para restaurar.
   Point In Time	Crea una instantánea personalizada que incluye todas las operaciones hasta, pero sin incluir, la hora seleccionada. Por defecto, Oplog Store almacena 24 horas de datos. Por ejemplo, si seleccionas 12:00, la última operación en la restauración será 11:59:59 o anterior. IMPORTANTE: En compatibilidad de características entre versiones 4.0, no se puede realizar una restauración PIT que cubra cualquier momento anterior a la última resincronización de copia de seguridad. Para conocer las condiciones que ocasionan una resincronización, consulte Resincronizar una copia de seguridad. Esta nota no se aplica a compatibilidad de características entre versiones 4.2 ni a versiones posteriores.	Seleccione un Date y un Time.
   Oplog Timestamp	Crea un snapshot personalizado que incluye todas las operaciones hasta e incluyendo la marca de tiempo Oplog ingresada. La marca de tiempo Oplog contiene dos campos: Timestamp marca de tiempo en el número de segundos que han transcurrido desde el Unix epoch Increment Orden de la operación aplicada en ese momento como un valor ordinal de 32 bits.	Escribe un Oplog Timestamp y Increment. Ejecute una query contra local.oplog.rs en su set de réplicas para encontrar la marca de tiempo deseada.

2. Haga clic en Next.

Elija restaurar los archivos en otro clúster.

1. Haga clic en Choose Cluster to Restore to.

2. Complete los siguientes campos:

   Campo	Acción
   Project	Elige un proyecto al que quieras restaurar la snapshot.
   Cluster to Restore to	Seleccione un clúster al que quiera restaurar el snapshot. Cloud Manager debe gestionar el set de réplicas objetivo. ADVERTENCIA: La automatización remueve todos los datos existentes del clúster. Preserva todas las copias de seguridad y las snapshots para el clúster existente.

2. Haga clic en Restore.

   El Cloud Manager registra la cantidad de espacio de almacenamiento que requiere la restauración.

Haga clic en Restore.

En MongoDB Cloud Manager, ir a la página Continuous Backup del proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Haz clic en la pestaña Overview.

Haga clic en la implementación y luego en Restore or Download.

Seleccionar el Punto de restauración.

1. Elige el punto del que deseas restaurar tu copia de seguridad.

   Tipo de restauración	Descripción	Acción
   Snapshot	Permite elegir una snapshot almacenada.	Selecciona una snapshot existente para restaurar.
   Point In Time	Crea una instantánea personalizada que incluye todas las operaciones hasta, pero sin incluir, la hora seleccionada. Por defecto, Oplog Store almacena 24 horas de datos. Por ejemplo, si seleccionas 12:00, la última operación en la restauración será 11:59:59 o anterior. IMPORTANTE: En compatibilidad de características entre versiones 4.0, no se puede realizar una restauración PIT que cubra cualquier momento anterior a la última resincronización de copia de seguridad. Para conocer las condiciones que ocasionan una resincronización, consulte Resincronizar una copia de seguridad. Esta nota no se aplica a compatibilidad de características entre versiones 4.2 ni a versiones posteriores.	Seleccione un Date y un Time.
   Oplog Timestamp	Crea un snapshot personalizado que incluye todas las operaciones hasta e incluyendo la marca de tiempo Oplog ingresada. La marca de tiempo Oplog contiene dos campos: Timestamp marca de tiempo en el número de segundos que han transcurrido desde el Unix epoch Increment Orden de la operación aplicada en ese momento como un valor ordinal de 32 bits.	Escribe un Oplog Timestamp y Increment. Ejecute una query contra local.oplog.rs en su set de réplicas para encontrar la marca de tiempo deseada.

2. Haga clic en Next.

Haz clic en Download para restaurar los archivos manualmente.

Configurar la descarga de la snapshot.

1. Configura las siguientes opciones de descarga:

   Pull Restore Usage Limit	Selecciona cuántas veces se puede usar el enlace. Si se selecciona No Limit, el enlace se puede reutilizar hasta que expire.
   Restore Link Expiration (in hours)	Seleccione la cantidad de horas hasta que el enlace expire. El valor por defecto es 1. El valor máximo es el número de horas hasta que caduque la snapshot seleccionada.

2. Haga clic en Finalize Request.

3. Si utilizas 2FA, Cloud Manager te solicitará tu código 2FA. Introduce tu código 2FA, y luego haz clic en Finalize Request.

En MongoDB Cloud Manager, ir a la página Continuous Backup del proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Retrieve the Snapshots.

Cloud Manager crea enlaces a la snapshot. Por defecto, estos enlaces están disponibles durante una hora y se pueden utilizar sólo una vez.

Para descargar los snapshots:

1. Haga clic en Restore History.

2. Cuando la tarea de restauración se complete, haz clic en (get link) para cada set de réplicas que aparezca.

3. Haz click:

   • El botón de copiar a la derecha del enlace para copiar el enlace y utilizarlo más tarde, o

   • Download para descargar la snapshot inmediatamente.

Desasociar el set de réplicas de destino.

Antes de intentar restaurar los datos manualmente, quita el set de réplicas de automatización.

Selecciona la opción Unmanage this item in Ops Managers but continue to monitor.

Detenga el set de réplicas objetivo.

Dependiendo de tu ruta, es posible que debas especificar la ruta a mongosh. ejecutar:

mongosh --port <port> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

Verifica los requisitos de hardware y software en el set de réplicas de destino.

Para aprender más, consulta instalación.

Mueve los archivos de datos del Snapshot al host de destino.

Antes de mover los archivos de datos de la snapshot al host de destino, verifica si el host de destino contiene archivos existentes y borra todos los archivos excepto el archivo automation-mongod.conf.

Descomprime los archivos de la snapshot y muévelos al host de destino de la siguiente manera:

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> </path/to/datafiles>

Inicie la instancia temporal autónomo en el puerto efímero.

Inicia el proceso mongod en modo autónomo como una medida temporal. Esto te permite agregar nuevos parámetros de configuración a la colección system.replset en pasos posteriores.

Utiliza el <ephemeralPort> para el proceso temporal autónomo mongod en todos los pasos de este procedimiento en que se mencione. Este puerto debe diferir de los puertos del host de origen y de destino.

Ejecute el proceso mongod como se indica a continuación. Según tu ruta, es posible que debas especificar la ruta al binario mongod.

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \

Si está restaurando a partir de una snapshot filtrada por namespace, use la opción --restore.

mongod --dbpath </path/to/datafiles> \
       --port <ephemeralPort> \
       --restore

Después de que el proceso mongod comience a aceptar conexiones, continuar.

Conéctese a la instancia temporal autónomo con mongosh.

Desde el host que ejecuta este proceso mongod, inicia mongosh. Dependiendo de tu ruta, puede que necesites especificar la ruta a mongosh.

Para conectarse al mongod escuchando en localhost en el mismo <ephemeralPort> especificado en el paso anterior, ejecute:

mongosh  --port <ephemeralPort>

Después de que mongosh se conecte a mongod, continúa.

Remueva las Colecciones relacionadas con set de réplicas de la base de datos local.

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

Ejecuta los siguientes comandos para remover la configuración anterior del set de réplicas y otras colecciones relacionadas con la replicación que no estén relacionadas con el registro de operaciones.

db.getSiblingDB("local").replset.minvalid.drop()
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
db.getSiblingDB("local").replset.election.drop()
db.getSiblingDB("local").system.replset.remove({})

Una respuesta exitosa debería verse así:

> db.getSiblingDB("local").replset.minvalid.drop()
true
> db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
true
> db.getSiblingDB("local").replset.election.drop()
true
> db.getSiblingDB("local").system.replset.remove({})
WriteResult({ "nRemoved" : 1 })

Agregar una nueva configuración de set de réplicas.

Inserta el siguiente documento en la colección system.replset de la base de datos local. Cambia las siguientes variables:

• <replaceMeWithTheReplicaSetName> al nombre de su set de réplicas. Este nombre no tiene que ser el mismo que el anterior.

• <host> al host que sirve a este miembro del set de réplicas.

• <ephemeralPortNewReplicaSet> al puerto efímero para el nuevo set de réplicas. Esto debe ser un puerto diferente del <ephemeralPort> que especificaste en el paso 11 de este procedimiento.

1
db.getSiblingDB("local").system.replset.insertOne({
2
  "_id" : "<replaceMeWithTheReplicaSetName>",
3
  "version" : NumberInt(1),
4
  "protocolVersion" : NumberInt(1),
5
  "members" : [
6
    {
7
      "_id" : NumberInt(0),
8
      "host" : "<host>:<ephemeralPortNewReplicaSet>"
9
    }
10
  ],
11
  "settings" : {
12
13
  }
14
})

Una respuesta exitosa debería verse así:

{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }

Inserte la marca de tiempo válida mínima.

Ejecutes el siguiente comando:

db.getSiblingDB("local").replset.minvalid.insertOne({
  "_id" : ObjectId(),
  "t" : NumberLong(-1),
  "ts" : Timestamp(0,1)
})

Una respuesta exitosa debería verse así:

{ "acknowledged" : true, "insertedId" : ObjectId("<yourObjectId>") }

Establecela el punto de restauración en los valores en Restore Timestamp desde restoreInfo.txt.

Establece el documento oplogTruncateAfterPoint con los valores proporcionados en el campo Restore Timestamp del archivo restoreInfo.txt.

El campo Restore Timestamp en ese archivo contiene dos valores. En el siguiente ejemplo, el primer valor es la marca de tiempo y el segundo valor es el incremento.

1
...
2
Restore timestamp:  (1609947369, 2)
3
Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1)
4
MongoDB Version: 4.2.11
5
...

El siguiente código de ejemplo utiliza el valor de marca de tiempo y el valor de incremento del ejemplo anterior.

truncateAfterPoint = Timestamp(1609947369,2)
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.insertOne({
   "_id": "oplogTruncateAfterPoint",
   "oplogTruncateAfterPoint": truncateAfterPoint
})

Una respuesta exitosa debería verse así:

WriteResult({ "nInserted" : 1 })

Detener la instancia temporal autónoma.

Dependiendo de tu ruta, es posible que debas especificar la ruta a mongosh. ejecutar:

mongosh --port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

Reinicia la instancia para recuperar el Oplog.

Inicie el mongod utilizando el siguiente comando y especifique estos parámetros:

• <bind_ip> al host que sirve a este miembro del set de réplicas que especificaste en el paso 14 de este procedimiento.

• <port> al <ephemeralPort> que especificaste en el paso 11 de este procedimiento.

El mongod vuelve a ejecutar el oplog hasta el/la Restore timestamp.

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \
        --bind_ip <host-serving-this-replica-set-member> \
        --replSet <replaceMeWithTheReplicaSetName>

Detén la instancia temporal en el puerto efímero.

Dependiendo de tu ruta, es posible que debas especificar la ruta a mongosh. ejecutar:

mongosh --port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

(Solo restauración a un punto específico del tiempo) Ejecute la utilidad de restauración de copias de seguridad de MongoDB.

Este paso es opcional. Ejecutalo si necesitas restauración a un punto específico del tiempo. Si necesitas este paso, complétalo y luego ejecuta los pasos 21 y 22. Si no necesitas este paso, continúa con el paso 23. En este paso, debes descargar y ejecutar la utilidad MongoDB copia de seguridad restauración Utility en la instancia destino del set de réplicas, y luego detener la instancia.

1. Descarga la herramienta de copia de seguridad y restauración de MongoDB en tu host.

   Si cerró el panel de restauración, haga clic en Continuous Backup in Deployment, More, y luego en Download MongoDB Backup Restore Utility.

2. Inicie una instancia de mongod sin que la autenticación esté habilitada utilizando el directorio de instantáneas extraído como el directorio de datos. Dependiendo de tu trayecto, es posible que necesites especificar la ruta del binario mongod.

   mongod  --port <ephemeralPort> \
           --dbpath </path/to/datafiles> \
           --setParameter ttlMonitorEnabled=false

   Advertencia

   La Utilidad de restauración de copia de seguridad de MongoDB no admite la autenticación, por lo que no puede iniciar esta base de datos temporal con autenticación.

3. Ejecuta la utilidad de restauración de copias de seguridad de MongoDB en tu host de destino. Ejecute una vez para el set de réplicas.

   Importante

   Comando preconfigurado para la utilidad mongodb-copia de seguridad-restauración-util

   Cloud Manager proporciona al mongodb-backup-restore-util las opciones adecuadas para su restauración en el panel de restauración bajo Run Binary with PIT Options.

   Debes copiar el comando mongodb-backup-restore-util proporcionado en el Cloud Manager.

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --accessList <database1.collection1, database2, etc.> \
      --denyList <database1.collection1, database2, etc.> \
      --seedReplSetMember \
      --oplogSizeMB <size> \
      --seedTargetPort <port> \
      --ssl \
      --sslCAFile </path/to/ca.pem> \
      --sslPEMKeyFile </path/to/pemkey.pem>
      --sslClientCertificateSubject <distinguishedName> \
      --sslRequireValidServerCertificates <true|false> \
      --sslServerClientCertificate </path/to/client.pem> \
      --sslServerClientCertificatePassword <password> \
      --sslRequireValidMMSBackupServerCertificate <true|false> \
      --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
      --httpProxy <proxyURL>

   El comando mongodb-backup-restore-util utiliza las siguientes opciones:

   Opción	Necesidad	Descripción
   --host	Requerido	Proporcione el nombre de host, FQDN, la dirección IP IPv4 o la dirección IP IPv6 para el host que sirve a mongod al que se debe aplicar el oplog. Si copiaste el mongodb-backup-restore-util comando proporcionado en el Cloud Manager, este campo está preconfigurado.
   --port	Requerido	Indique el puerto del host que sirve al mongod al que se debe aplicar el oplog.
   --opStart	Requerido	Proporciona la marca de tiempo BSON para la primera entrada de oplog que deseas incluir en la restauración. Esta información aparece en la entrada "Último Oplog aplicado" en el archivo restoreInfo.txt proporcionado con el snapshot descargado. Este valor debe ser menor o igual al valor --opEnd.
   --opEnd	Requerido	Proporcione la marca de tiempo BSON de la última oplog que desee incluir en la restauración. Este valor no puede ser mayor que el final del opLog.
   --logFile	Opcional	Proporcione una ruta, incluido el nombre del archivo, donde se escribe el registro MBRU.
   --oplogSourceAddr	Requerido	Proporcione el URL al endpoint del recurso del Cloud Manager.
   --apiKey	Requerido	Proporcione su clave API del agentede Cloud Manager.
   --groupId	Requerido	Proporcione el ID del grupo.
   --rsId	Requerido	Proporcione el ID del set de réplicas.
   --accessList	Opcional	Proporcione una lista de bases de datos y/o colecciones a las que quiera limitar la restauración.
   --denyList	Opcional	Proporcione una lista de bases de datos y/o colecciones que desea excluir de la restauración.
   --seedReplSetMember	Opcional	Utilice esto si necesita que un miembro del conjunto de réplicas vuelva a crear la colección oplog y la inicialice con la marca de tiempo correcta. Requiere --oplogSizeMB y --seedTargetPort.
   --oplogSizeMB	Condicional	Proporcione el tamaño de oplog en MB. Requerido si --seedReplSetMember está configurado.
   --seedTargetPort	Condicional	Proporciona el puerto para el set de réplicas primario. Esto puede diferir del puerto efímero utilizado. Requerido si --seedReplSetMember está configurado.
   --ssl	Condicional	Úsalo si necesitas TLS/SSL para aplicar el oplog al mongod. Requiere --sslCAFile y --sslPEMKeyFile.
   --sslCAFile	Condicional	Proporcione la ruta al archivo de la Autoridad Certificadora. Requerido si --ssl está configurado.
   --sslPEMKeyFile	Condicional	Proporciona la ruta al archivo del certificado PEM. Requerido si --ssl está configurado.
   --sslPEMKeyFilePwd	Condicional	Proporcione la contraseña para el archivo de certificado PEM especificado en --sslPEMKeyFile. Obligatorio si --ssl está configurado y el archivo de clave PEM está cifrado.
   --sslClientCertificateSubject		Proporcione el Sujeto del Certificado de Cliente o Nombre Distinguido (DN) para el proceso de destino de MongoDB.
   --sslRequireValidServerCertificates	Opcional	Establezca una bandera que indique si la herramienta debe validar los certificados que presenta el proceso objetivo de MongoDB.
   --sslServerClientCertificate	Opcional	Proporcione la ruta absoluta al archivo del certificado de cliente que se utilizará para conectarse al host de Cloud Manager.
   --sslServerClientCertificatePassword	Condicional	Proporcione la ruta absoluta al archivo de contraseña del certificado de cliente que se va a utilizar para conectarse al host de Cloud Manager. Obligatorio si --sslServerClientCertificate está configurado y ese certificado está cifrado.
   --sslRequireValidMMSBackupServerCertificate	Opcional	Establecer una bandera que indique si se requieren certificados válidos al contactar con el host de Cloud Manager. El valor por defecto es true.
   --sslTrustedMMSBackupServerCertificate	Opcional	Proporcione la ruta absoluta a los certificados de la Autoridad Certificadora confiable en formato PEM para el host de Cloud Manager. Si no se proporciona esta bandera, se utiliza la Autoridad de certificación del sistema.
   --httpProxy	Opcional	Proporcione la URL de un HTTP servidor proxy que la herramienta pueda usar.

   significa que si copiaste el comando mongodb-backup-restore-util proporcionado en Cloud Manager, este campo está preconfigurado.

4. Detén el mongod en la instancia. Dependiendo de tu trayecto, puede que necesites especificar la ruta a mongosh. ejecutar:

   mongosh --port <ephemeralPort> \
         --eval "db.getSiblingDB('admin').shutdownServer()"

(Solo restauración a un punto específico del tiempo) Reinicie la Instancia para Recuperar el Oplog.

Este paso es necesario sólo si se ha ejecutado el paso 20. Si no necesitabas ejecutar el paso 20, entonces continúa con el paso 23. Inicie el mongod usando el siguiente comando. El mongod reproduce el oplog hasta el Restore timestamp. Dependiendo de la ruta, es posible que deba especificar la ruta al binario de mongod.

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \
        --replSet <replaceMeWithTheReplicaSetName>

Una vez que completes este paso, el proceso real de restauración se completará. En los siguientes pasos, restaure la configuración del set de réplicas y vuelva a importarlo.

(Solo restauración a un punto específico del tiempo) Detén la instancia en el puerto efímero.

Este paso solo es necesario si ejecutó el paso 20. Si no necesitó ejecutar el paso 20, entonces proceda al paso 23.

Dependiendo de tu ruta, es posible que debas especificar la ruta a mongosh. ejecutar:

mongosh--port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

Reinicie el set de réplicas como una instancia autónoma.

Inicie el proceso mongod como una instancia autónomo utilizando el siguiente comando. Para <port>, use el puerto real en el que se supone que este nodo del set de réplicas debe ejecutarse. Dependiendo de tu ruta, es posible que necesites especificar la ruta al binario de mongod.

mongod  --dbpath </path/to/datafiles> \
        --port <port>

Después de que el proceso mongod comience a aceptar conexiones, continuar.

Elimine la Configuración temporal del conjunto de réplicas.

Ejecuta el siguiente comando:

mongosh --port <port> \
      --eval db.getSiblingDB("local").system.replset.remove({})

Detener la instancia autónoma.

Dependiendo de tu ruta, es posible que debas especificar la ruta a mongosh. ejecutar:

mongosh --port <port> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

Repite los pasos 10 a 25 para cada nodo del set de réplicas.

Reinicie todos los nodos en un set de réplicas.

En este momento, los archivos de datos en el set de réplicas están en un estado coherente pero la configuración del set de réplicas necesita ser actualizada para que cada nodo sea consciente del otro.

Ejecuta el siguiente comando:

sudo -u mongod <path/to/target_mongod_binary> -f /path/to/datafiles/automation-mongod.conf

El siguiente ejemplo reinicia todos los nodos con la versión 4.4.12 empresa con la ruta de datos /data6/node3:

sudo -u mongod /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.12-ent/bin/mongod -f /data6/node3/automation-mongod.conf

Configura tu set de réplicas.

Inicie sesión en uno de los nodos y ejecute los siguientes comandos:

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )

En MongoDB Cloud Manager, ir a la página Processes del proyecto.

1. Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Processes en la sección Database.

Se muestra la página Procesos.

Vuelva a importar el set de réplicas.

Para gestionar el set de réplicas con automatización nuevamente, importa el set de réplicas de regreso en Cloud Manager.

Haz clic en Add, selecciona Existing MongoDB Deployment y procede a añadir Automation nuevamente a tu clúster.

En MongoDB Cloud Manager, ir a la página Continuous Backup del proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Haz clic en la pestaña Overview.

Haga clic en la implementación y luego en Restore or Download.

Selecciona el punto de restauración.

1. Elige el punto del que deseas restaurar tu copia de seguridad.

   Tipo de restauración	Descripción	Acción
   Snapshot	Permite elegir una snapshot almacenada.	Selecciona una snapshot existente para restaurar.
   Point In Time	Crea una instantánea personalizada que incluye todas las operaciones hasta, pero sin incluir, la hora seleccionada. Por defecto, Oplog Store almacena 24 horas de datos. Por ejemplo, si seleccionas 12:00, la última operación en la restauración será 11:59:59 o anterior. IMPORTANTE: En compatibilidad de características entre versiones 4.0, no se puede realizar una restauración PIT que cubra cualquier momento anterior a la última resincronización de copia de seguridad. Para conocer las condiciones que ocasionan una resincronización, consulte Resincronizar una copia de seguridad. Esta nota no se aplica a compatibilidad de características entre versiones 4.2 ni a versiones posteriores.	Seleccione un Date y un Time.
   Oplog Timestamp	Crea un snapshot personalizado que incluye todas las operaciones hasta e incluyendo la marca de tiempo Oplog ingresada. La marca de tiempo Oplog contiene dos campos: Timestamp marca de tiempo en el número de segundos que han transcurrido desde el Unix epoch Increment Orden de la operación aplicada en ese momento como un valor ordinal de 32 bits.	Escribe un Oplog Timestamp y Increment. Ejecute una query contra local.oplog.rs en su set de réplicas para encontrar la marca de tiempo deseada.

2. Haga clic en Next.

Para encontrar la última entrada de Oplog, ejecute la siguiente consulta en mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

Un resultado exitoso debe verse así:

{
  "ts": Timestamp(1537559320, 1),
  "h": NumberLong("-2447431566377702740"),
  "v": 2,
  "op": "n",
  "ns": "",
  "wall": ISODate("2018-09-21T19:48:40.708Z"),
  "o": {
    "msg": "initiating set"
  }
}

Las partes del valor ts corresponden a los valores que necesitas para los cuadros Timestamp y Increment.

Elija restaurar los archivos en otro clúster.

1. Haga clic en Choose Cluster to Restore to.

2. Complete los siguientes campos:

   Campo	Acción
   Project	Elige un proyecto al que quieras restaurar la snapshot.
   Cluster to Restore to	Seleccione un clúster al que quiera restaurar el snapshot. Cloud Manager debe gestionar el set de réplicas objetivo. ADVERTENCIA: La automatización remueve todos los datos existentes del clúster. Preserva todas las copias de seguridad y las snapshots para el clúster existente.

2. Haga clic en Restore.

   El Cloud Manager registra la cantidad de espacio de almacenamiento que requiere la restauración.

Haga clic en Restore.

En MongoDB Cloud Manager, ir a la página Continuous Backup del proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Haz clic en la pestaña Overview.

Haga clic en la implementación y luego en Restore or Download.

Selecciona el punto de restauración.

1. Elige el punto del que deseas restaurar tu copia de seguridad.

   Tipo de restauración	Descripción	Acción
   Snapshot	Permite elegir una snapshot almacenada.	Selecciona una snapshot existente para restaurar.
   Point In Time	Crea una instantánea personalizada que incluye todas las operaciones hasta, pero sin incluir, la hora seleccionada. Por defecto, Oplog Store almacena 24 horas de datos. Por ejemplo, si seleccionas 12:00, la última operación en la restauración será 11:59:59 o anterior. IMPORTANTE: En compatibilidad de características entre versiones 4.0, no se puede realizar una restauración PIT que cubra cualquier momento anterior a la última resincronización de copia de seguridad. Para conocer las condiciones que ocasionan una resincronización, consulte Resincronizar una copia de seguridad. Esta nota no se aplica a compatibilidad de características entre versiones 4.2 ni a versiones posteriores.	Seleccione un Date y un Time.
   Oplog Timestamp	Crea un snapshot personalizado que incluye todas las operaciones hasta e incluyendo la marca de tiempo Oplog ingresada. La marca de tiempo Oplog contiene dos campos: Timestamp marca de tiempo en el número de segundos que han transcurrido desde el Unix epoch Increment Orden de la operación aplicada en ese momento como un valor ordinal de 32 bits.	Escribe un Oplog Timestamp y Increment. Ejecute una query contra local.oplog.rs en su set de réplicas para encontrar la marca de tiempo deseada.

2. Haga clic en Next.

Para encontrar la última entrada de Oplog, ejecute la siguiente consulta en mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

Un resultado exitoso debe verse así:

{
  "ts": Timestamp(1537559320, 1),
  "h": NumberLong("-2447431566377702740"),
  "v": 2,
  "op": "n",
  "ns": "",
  "wall": ISODate("2018-09-21T19:48:40.708Z"),
  "o": {
    "msg": "initiating set"
  }
}

Las partes del valor ts corresponden a los valores que necesitas para los cuadros Timestamp y Increment.

Haz clic en Download para restaurar los archivos manualmente.

Configurar la descarga de la snapshot.

1. Configura las siguientes opciones de descarga:

   Pull Restore Usage Limit	Selecciona cuántas veces se puede usar el enlace. Si se selecciona No Limit, el enlace se puede reutilizar hasta que expire.
   Restore Link Expiration (in hours)	Seleccione la cantidad de horas hasta que el enlace expire. El valor por defecto es 1. El valor máximo es el número de horas hasta que caduque la snapshot seleccionada.

2. Haga clic en Finalize Request.

3. Si utilizas 2FA, Cloud Manager te solicitará tu código 2FA. Introduce tu código 2FA, y luego haz clic en Finalize Request.

En MongoDB Cloud Manager, ir a la página Continuous Backup del proyecto.

1. Si aún no se muestra, se debe seleccionar la organización que contiene el proyecto deseado en el menú Organizations de la barra de navegación.

2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

   Se muestra la página de copia de seguridad continua.

Retrieve the snapshots.

Cloud Manager crea enlaces a la snapshot. Por defecto, estos enlaces están disponibles durante una hora y solo se pueden utilizar una vez.

Para descargar los snapshots:

1. Haga clic en Restore History.

2. Cuando se complete la tarea de restauración, haz clic en (get link) para cada set de réplicas que aparezca.

3. Haz click:

   • El botón de copiar a la derecha del enlace para copiar el enlace y utilizarlo más tarde, o

   • Download para descargar la snapshot inmediatamente.

Restaure los archivos de datos de la snapshot en el host de destino.

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>

Ejecutar la Utilidad de copia de seguridad de MongoDB (solo restauración a un punto específico del tiempo).

1. Descarga la herramienta de copia de seguridad y restauración de MongoDB en tu host.

   Nota

   Si cerraste el panel de restauración:

   1. En MongoDB Cloud Manager, ve a la página Continuous Backup de tu proyecto.

      1. Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.

      2. Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.

      3. En la barra lateral, haz clic en Continuous Backup en la sección Database.

      Se muestra la página de copia de seguridad continua.

   2. Haz clic en More y luego en Download MongoDB Backup Restore Utility.

2. Inicie una instancia de mongod sin autenticación habilitada, utilizando el directorio de instantáneas extraído como directorio de datos.

   Ejemplo

   mongod --port <port number> \
     --dbpath <temp-database-path> \
     --setParameter ttlMonitorEnabled=false

   Advertencia

   La Utilidad de restauración de copia de seguridad de MongoDB no admite la autenticación, por lo que no puede iniciar esta base de datos temporal con autenticación.

3. Ejecute el MongoDB Copia de seguridad Restauración Utility en su host de destino. Ejecutar una vez para el set de réplicas.

   Importante

   Comando preconfigurado para la utilidad mongodb-copia de seguridad-restauración-util

   Cloud Manager proporciona al mongodb-backup-restore-util las opciones adecuadas para su restauración en el panel de restauración bajo Run Binary with PIT Options.

   Debes copiar el comando mongodb-backup-restore-util proporcionado en el Cloud Manager.

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --accessList <database1.collection1, database2, etc.> \
      --denyList <database1.collection1, database2, etc.> \
      --seedReplSetMember \
      --oplogSizeMB <size> \
      --seedTargetPort <port> \
      --ssl \
      --sslCAFile </path/to/ca.pem> \
      --sslPEMKeyFile </path/to/pemkey.pem>
      --sslClientCertificateSubject <distinguishedName> \
      --sslRequireValidServerCertificates <true|false> \
      --sslServerClientCertificate </path/to/client.pem> \
      --sslServerClientCertificatePassword <password> \
      --sslRequireValidMMSBackupServerCertificate <true|false> \
      --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
      --httpProxy <proxyURL>

   El comando mongodb-backup-restore-util utiliza las siguientes opciones:

   Opción	Necesidad	Descripción
   --host	Requerido	Proporcione el nombre de host, FQDN, la dirección IP IPv4 o la dirección IP IPv6 para el host que sirve a mongod al que se debe aplicar el oplog. Si copiaste el mongodb-backup-restore-util comando proporcionado en el Cloud Manager, este campo está preconfigurado.
   --port	Requerido	Indique el puerto del host que sirve al mongod al que se debe aplicar el oplog.
   --opStart	Requerido	Proporciona la marca de tiempo BSON para la primera entrada de oplog que deseas incluir en la restauración. Esta información aparece en la entrada "Último Oplog aplicado" en el archivo restoreInfo.txt proporcionado con el snapshot descargado. Este valor debe ser menor o igual al valor --opEnd.
   --opEnd	Requerido	Proporcione la marca de tiempo BSON de la última oplog que desee incluir en la restauración. Este valor no puede ser mayor que el final del opLog.
   --logFile	Opcional	Proporcione una ruta, incluido el nombre del archivo, donde se escribe el registro MBRU.
   --oplogSourceAddr	Requerido	Proporcione el URL al endpoint del recurso del Cloud Manager.
   --apiKey	Requerido	Proporcione su clave API del agentede Cloud Manager.
   --groupId	Requerido	Proporcione el ID del grupo.
   --rsId	Requerido	Proporcione el ID del set de réplicas.
   --accessList	Opcional	Proporcione una lista de bases de datos y/o colecciones a las que quiera limitar la restauración.
   --denyList	Opcional	Proporcione una lista de bases de datos y/o colecciones que desea excluir de la restauración.
   --seedReplSetMember	Opcional	Utilice esto si necesita que un miembro del conjunto de réplicas vuelva a crear la colección oplog y la inicialice con la marca de tiempo correcta. Requiere --oplogSizeMB y --seedTargetPort.
   --oplogSizeMB	Condicional	Proporcione el tamaño de oplog en MB. Requerido si --seedReplSetMember está configurado.
   --seedTargetPort	Condicional	Proporciona el puerto para el set de réplicas primario. Esto puede diferir del puerto efímero utilizado. Requerido si --seedReplSetMember está configurado.
   --ssl	Condicional	Úsalo si necesitas TLS/SSL para aplicar el oplog al mongod. Requiere --sslCAFile y --sslPEMKeyFile.
   --sslCAFile	Condicional	Proporcione la ruta al archivo de la Autoridad Certificadora. Requerido si --ssl está configurado.
   --sslPEMKeyFile	Condicional	Proporciona la ruta al archivo del certificado PEM. Requerido si --ssl está configurado.
   --sslPEMKeyFilePwd	Condicional	Proporcione la contraseña para el archivo de certificado PEM especificado en --sslPEMKeyFile. Obligatorio si --ssl está configurado y el archivo de clave PEM está cifrado.
   --sslClientCertificateSubject		Proporcione el Sujeto del Certificado de Cliente o Nombre Distinguido (DN) para el proceso de destino de MongoDB.
   --sslRequireValidServerCertificates	Opcional	Establezca una bandera que indique si la herramienta debe validar los certificados que presenta el proceso objetivo de MongoDB.
   --sslServerClientCertificate	Opcional	Proporcione la ruta absoluta al archivo del certificado de cliente que se utilizará para conectarse al host de Cloud Manager.
   --sslServerClientCertificatePassword	Condicional	Proporcione la ruta absoluta al archivo de contraseña del certificado de cliente que se va a utilizar para conectarse al host de Cloud Manager. Obligatorio si --sslServerClientCertificate está configurado y ese certificado está cifrado.
   --sslRequireValidMMSBackupServerCertificate	Opcional	Establecer una bandera que indique si se requieren certificados válidos al contactar con el host de Cloud Manager. El valor por defecto es true.
   --sslTrustedMMSBackupServerCertificate	Opcional	Proporcione la ruta absoluta a los certificados de la Autoridad Certificadora confiable en formato PEM para el host de Cloud Manager. Si no se proporciona esta bandera, se utiliza la Autoridad de certificación del sistema.
   --httpProxy	Opcional	Proporcione la URL de un HTTP servidor proxy que la herramienta pueda usar.

   significa que si copiaste el comando mongodb-backup-restore-util proporcionado en Cloud Manager, este campo está preconfigurado.

Desgestionar el set de réplicas.

Antes de intentar restaurar los datos manualmente, quita el set de réplicas de automatización.

Restaurar el set de réplicas manualmente.

Sigue el tutorial del manual de MongoDB para restaurar el set de réplicas.

Vuelva a importar el set de réplicas.

Para gestionar el set de réplicas con automatización nuevamente, importa el set de réplicas de regreso en Cloud Manager.