Restaurar um conjunto de réplicas a partir de um snapshot

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Clique na aba Overview.

Clique no sistema e, em seguida, clique Restore or Download em .

Selecione o ponto de restauração.

1. Escolha o ponto de partida do qual deseja restaurar o backup.

   Tipo de Restauração	Descrição	em ação
   Snapshot	Permite escolher um snapshot armazenado.	Selecione um snapshot existente para restaurar.
   Point In Time	Cria um snapshot personalizado que inclui todas as operações até, mas não incluindo, o horário selecionado. Por padrão, o Oplog Store armazena 24 horas de dados. Por exemplo, se você selecionar 12:00, a última operação na restauração será 11:59:59 ou anterior. IMPORTANTE: no FCV 4.0, você não pode executar uma restauração de PIT que abranja qualquer momento anterior à última ressincronização de backup. Para saber as condições que causam uma ressincronização, consulte Sincronizar novamente um backup. Esta nota não se aplica ao FCV 4.2 ou posterior.	Selecione um Date e Time.
   Oplog Timestamp	Cria um snapshot personalizado que inclui todas as operações até e incluindo o carimbo de data/hora do oplog inserido. O registro de data e hora do oplog contém dois campos: Timestamp Registro de data/hora no número de segundos decorridos desde a UNIX epoch Increment Ordem de operação aplicada naquele segundo como um ordinal de 32 bits.	Digite um oplog Timestamp e Increment. Execute uma query em local.oplog.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

2. Clique em Next.

Escolha restaurar os arquivos para outro cluster.

1. Clique em Choose Cluster to Restore to.

2. Preencha os seguintes campos:

   Campo	em ação
   Project	Selecione um projeto para o qual deseja restaurar o snapshot.
   Cluster to Restore to	Selecione um cluster no qual você deseja restaurar o snapshot. O Cloud Manager deve gerenciar o conjunto de réplicas de destino. AVISO: a automação remove todos os dados existentes do cluster. Ele preserva todos os dados de backup e snapshots do cluster existente.

2. Clique em Restore.

   O Cloud Manager observa quanto espaço de armazenamento a restauração exige.

Clique em Restore.

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Clique na aba Overview.

Clique no sistema e, em seguida, clique Restore or Download em .

Selecione o ponto de restauração.

1. Escolha o ponto de partida do qual deseja restaurar o backup.

   Tipo de Restauração	Descrição	em ação
   Snapshot	Permite escolher um snapshot armazenado.	Selecione um snapshot existente para restaurar.
   Point In Time	Cria um snapshot personalizado que inclui todas as operações até, mas não incluindo, o horário selecionado. Por padrão, o Oplog Store armazena 24 horas de dados. Por exemplo, se você selecionar 12:00, a última operação na restauração será 11:59:59 ou anterior. IMPORTANTE: no FCV 4.0, você não pode executar uma restauração de PIT que abranja qualquer momento anterior à última ressincronização de backup. Para saber as condições que causam uma ressincronização, consulte Sincronizar novamente um backup. Esta nota não se aplica ao FCV 4.2 ou posterior.	Selecione um Date e Time.
   Oplog Timestamp	Cria um snapshot personalizado que inclui todas as operações até e incluindo o carimbo de data/hora do oplog inserido. O registro de data e hora do oplog contém dois campos: Timestamp Registro de data/hora no número de segundos decorridos desde a UNIX epoch Increment Ordem de operação aplicada naquele segundo como um ordinal de 32 bits.	Digite um oplog Timestamp e Increment. Execute uma query em local.oplog.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

2. Clique em Next.

Clique Download em para restaurar os arquivos manualmente.

Configure o download do snapshot.

1. Configure as seguintes opções de download:

   Pull Restore Usage Limit	Selecione quantas vezes o link pode ser usado. Se você selecionar No Limit, o link poderá ser reutilizado até expirar.
   Restore Link Expiration (in hours)	Selecione o número de horas até que o link expire. O valor padrão é 1. O valor máximo é o número de horas até que o snapshot selecionado expire.

2. Clique em Finalize Request.

3. Se você usar 2FA, o Cloud Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Retrieve the Snapshots.

O Cloud Manager cria links para o snapshot. Por padrão, esses links estão disponíveis por uma hora e você pode usá-los apenas uma vez.

Para baixar os snapshots:

1. Clique em Restore History.

2. Quando o tarefa de restauração for concluído, clique em (get link) para cada conjunto de réplicas que aparecer.

3. Clique em:

   • O botão copiar à direita do link para copiar o link para usá-lo mais tarde, ou

   • Download para fazer o download do snapshot imediatamente.

Cancele o gerenciamento do conjunto de réplicas de destino.

Antes de tentar restaurar os dados manualmente, remova o conjunto de réplicas da automação.

Escolha a opção Unmanage this item in Ops Managers but continue to monitor .

Pare o conjunto de réplicas de destino.

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

Verifique os requisitos de hardware e software no conjunto de réplicas de destino.

Para saber mais, consulte instalação.

Mova os arquivos de dados de snapshot para o host de destino.

Antes de mover os arquivos de dados do snapshot para o host de destino, verifique se o host de destino contém algum arquivo existente e exclua todos os arquivos, exceto o arquivo automation-mongod.conf .

Descompacte os arquivos de snapshot e mova-os para o host de destino da seguinte maneira:

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

Inicie a Instância Standalone Temporária na Porta Efêmera.

Inicie o processo mongod no modo autônomo como uma medida temporária. Isso permite adicionar novos parâmetros de configuração à collection system.replset nas etapas subsequentes.

Use o <ephemeralPort> para o processo mongod autônomo temporário em todas as etapas deste procedimento em que ele for mencionado. Essa porta deve ser diferente das portas do host de origem e destino.

Execute o processo do mongod da seguinte maneira. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod .

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

Se estiver restaurando de um snapshot filtrado por namespace, use a opção --restore .

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

Depois que o processo mongod começar a aceitar conexões, continue.

Conecte-se à Instância Autônomo Temporária com mongosh.

A partir do host que executa este processo mongod , inicie mongosh. Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh.

Para se conectar ao mongod escutando localhost no mesmo <ephemeralPort> especificado na etapa anterior, execute:

mongosh  --port <ephemeralPort>

Depois que mongosh se conectar a mongod, continue.

Remova as collections relacionadas ao conjunto de réplicas do local banco de dados .

Para realizar restaurações manuais, você deve ter a função de Administrador de backup no Cloud Manager.

Execute os seguintes comandos para remover a configuração anterior do conjunto de réplicas e outras collections não oplog relacionadas à replicação.

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

Uma resposta bem-sucedida deve ser assim:

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

Adicione uma nova configuração de conjunto de réplicas.

Insira o seguinte documento na coleção system.replset no banco de dados de dados local . Altere as seguintes variáveis:

• <replaceMeWithTheReplicaSetName> ao nome do seu conjunto de réplicas. Este nome não precisa ser igual ao nome antigo.

• <host> para o host que atende a esse membro do conjunto de réplicas.

• <ephemeralPortNewReplicaSet> para a porta efêmera do novo conjunto de réplicas. Esta deve ser uma porta diferente da <ephemeralPort> que você especificou na etapa 11 deste procedimento.

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

Uma resposta bem-sucedida deve ser assim:

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

Insira o carimbo de data/hora mínimo válido.

Emitir o seguinte comando:

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

Uma resposta bem-sucedida deve ser assim:

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

Defina o ponto de restauração para os valores em Restore Timestamp de restoreInfo.txt.

Defina o documento oplogTruncateAfterPoint para os valores fornecidos no campo Restore Timestamp do arquivo restoreInfo.txt .

O campo Restore Timestamp nesse arquivo contém dois valores. No exemplo a seguir , o primeiro valor é o timestamp e o segundo valor é o 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
...

O código de exemplo a seguir usa o valor de registro de data e hora e o valor de incremento do exemplo anterior.

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

Uma resposta bem-sucedida deve ser assim:

WriteResult({ "nInserted" : 1 })

Pare a instância independente temporária.

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

Reinicie a instância para recuperar o oplog.

Inicie o mongod usando o seguinte comando, especificando estes parâmetros:

• <bind_ip> ao host que atende a esse membro do conjunto de réplicas que você especificou na etapa 14 deste procedimento.

• <port> à <ephemeralPort> que você especificou na etapa 11 deste procedimento.

O mongod repete o oplog até o Restore timestamp.

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

Pare a instância temporária na porta efêmera.

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

(Somente restauração point-in-time) Execute o utilitário de restauração de backup do MongoDB .

Esta etapa é opcional. Execute-o se precisar de restauração point-in-time. Se você precisar desta etapa, conclua-a e execute as etapas 21 e 22. Se você não precisar desta etapa, vá para a etapa 23. Nesta etapa, você baixa e executa o Utilitário de Restauração de Backup MongoDB na instância de destino do conjunto de réplicas e, em seguida, interrompe a instância.

1. Baixe o utilitário de restauração de backup do MongoDB para o seu host.

   Se você fechou o painel de restauração, clique em Continuous Backup in Deployment, More e depois em Download MongoDB Backup Restore Utility.

2. Inicie uma instância do mongod sem autenticação habilitada utilizando o diretório de captura instantânea extraído como o diretório de dados. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod .

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

   Aviso

   O Utilitário de Restauração de Backup MongoDB não oferece suporte a autenticação, portanto, você não pode iniciar esse banco de banco de dados temporário com autenticação.

3. Execute o utilitário MongoDB Backup Restore no host de destino. Execute-o uma vez para o conjunto de réplicas.

   Importante

   Comando mongodb-backup-restore-util pré-configurado

   O Cloud Manager fornece ao mongodb-backup-restore-util as opções apropriadas para sua restauração no painel de restauração em Run Binary with PIT Options.

   Você deve copiar o comando mongodb-backup-restore-util fornecido no Cloud Manager.

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --whitelist <database1.collection1, database2, etc.> \
      --blacklist <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>

   O comando mongodb-backup-restore-util utiliza as seguintes opções:

   Opção	necessidade	Descrição
   --host	Obrigatório	Forneça o nome do host, FQDN, endereço IPv4 ou endereço IPv6 do host que atende ao mongod ao qual o oplog deve ser aplicado. Se você copiou o comando mongodb-backup-restore-util fornecido no Cloud Manager, este campo será pré-configurado.
   --port	Obrigatório	Forneça a porta do host que atende ao mongod ao qual o oplog deve ser aplicado.
   --opStart	Obrigatório	Forneça o carimbo de data/ hora BSON para a primeira entrada de oplog que você deseja incluir na restauração. Essas informações aparecem na entrada "Last oplog Applied" no arquivo restoreInfo.txt fornecido com o snapshot baixado. Este valor deve ser menor ou igual ao valor de --opEnd .
   --opEnd	Obrigatório	Forneça o carimbo de data/ hora BSON para a última entrada de oplog que você deseja incluir na restauração. Esse valor não pode ser maior que o final do oplog.
   --logFile	Opcional	Forneça um caminho, incluindo o nome do arquivo, onde o log MBRU é gravado.
   --oplogSourceAddr	Obrigatório	Forneça a URL para o endpoint do recurso Cloud Manager .
   --apiKey	Obrigatório	Forneça sua chave APIdo Cloud Manager Agent.
   --groupId	Obrigatório	Forneça o ID do grupo .
   --rsId	Obrigatório	Forneça a ID do conjunto de réplicas .
   --whitelist	Opcional	Forneça uma lista de bancos de dados e/ou collections aos quais você deseja limitar a restauração.
   --blacklist	Opcional	Forneça uma lista de bancos de dados e/ou collections para os quais você deseja excluir da restauração.
   --seedReplSetMember	Opcional	Use se você precisar de um membro do conjunto de réplicas para recriar a coleção de oplog e semeá-la com o registro de data e hora correto. Exige --oplogSizeMB e --seedTargetPort.
   --oplogSizeMB	Condicional	Forneça o tamanho do oplog em MB. Obrigatório se --seedReplSetMember estiver definido.
   --seedTargetPort	Condicional	Forneça a porta para o primário do conjunto de réplicas . Isso pode ser diferente da porta efêmera usado. Obrigatório se --seedReplSetMember estiver definido.
   --ssl	Condicional	Use se precisar de TLS/SSL para aplicar o oplog ao mongod. Exige --sslCAFile e --sslPEMKeyFile.
   --sslCAFile	Condicional	Forneça o caminho para o arquivo da Autoridade de Certificação. Obrigatório se --ssl estiver definido.
   --sslPEMKeyFile	Condicional	Forneça o caminho para o arquivo de certificado PEM . Obrigatório se --ssl estiver definido.
   --sslPEMKeyFilePwd	Condicional	Forneça a senha do arquivo de certificado PEM especificado em --sslPEMKeyFile. Obrigatório se --ssl estiver definido e esse arquivo de chave PEM estiver criptografado.
   --sslClientCertificateSubject		Forneça o Assunto do Certificado do Cliente ou Nome Distinto (DN) para o processo MongoDB de destino.
   --sslRequireValidServerCertificates	Opcional	Defina um sinalizador indicando se a ferramenta deve validar os certificados que o processo MongoDB de destino apresenta.
   --sslServerClientCertificate	Opcional	Forneça o caminho absoluto para o arquivo de certificado do cliente a ser usado para se conectar ao host do Cloud Manager .
   --sslServerClientCertificatePassword	Condicional	Forneça o caminho absoluto para a senha do arquivo de Certificado do Cliente a ser usado para se conectar ao host do Cloud Manager . Necessário se --sslServerClientCertificate estiver definido e esse certificado for criptografado.
   --sslRequireValidMMSBackupServerCertificate	Opcional	Defina um sinalizador indicando se certificados válidos são necessários ao entrar em contato com o host do Cloud Manager . O valor padrão é true.
   --sslTrustedMMSBackupServerCertificate	Opcional	Forneça o caminho absoluto para os certificados confiáveis da Autoridade de Certificação no formato PEM para o host do Cloud Manager . Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada.
   --httpProxy	Opcional	Forneça a URL de um servidor proxy HTTP que a ferramenta pode usar.

   significa que, se você copiou o comando mongodb-backup-restore-util fornecido no Cloud Manager, esse campo será pré-configurado.

4. Pare o mongod na instância. Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

(Somente restauração point-in-time) Reinicie a instância para recuperar o oplog.

Esta etapa é necessária somente se você executou a etapa 20. Se você não precisou executar a etapa 20, vá para a etapa 23. Inicie o mongod utilizando o seguinte comando. O mongod repete o oplog até o Restore timestamp. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod .

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

Depois de concluir esta etapa, o processo de restauração real será concluído. Nas etapas a seguir, você restaura a configuração do conjunto de réplicas e a reimporta.

(Somente restauração point-in-time) Pare a instância na porta efêmera.

Esta etapa é necessária somente se você executou a etapa 20. Se você não precisou executar a etapa 20, vá para a etapa 23.

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

Reinicie o conjunto de réplicas como uma instância independente.

Inicie o processo mongod como uma instância autônomo usando o seguinte comando. Para <port>, use a porta real na qual esse nó no conjunto de réplicas deve ser executado. Dependendo do seu caminho, talvez seja necessário especificar o caminho para o binário mongod .

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

Depois que o processo mongod começar a aceitar conexões, continue.

Remova a Configuração Temporária do Conjunto de Réplicas.

Execute o seguinte comando:

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

Pare a instância independente.

Dependendo do seu caminho, talvez seja necessário especificar o caminho para mongosh. Executar:

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

Repita as etapas 10 a 25 para cada nó do conjunto de réplicas.

Reinicie todos os nós em um conjunto de réplicas.

Neste ponto, os arquivos de dados no conjunto de réplicas estão em um estado consistente, mas a configuração do conjunto de réplicas precisa ser atualizada para que cada nó esteja ciente uns dos outros.

Execute o seguinte comando:

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

O exemplo a seguir reinicia todos os nós com a versão 4.4.12 enterprise com o caminho de dados /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

Defina a configuração do conjunto de réplicas.

Faça login em um dos nós e execute os seguintes comandos:

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

No MongoDB Cloud Manager, Go a Deployment página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Se a página Deployment ainda não estiver exibida, clique em Deployment na barra lateral.

   A página Sistema é exibida.

Reimportar o conjunto de réplicas.

Para gerenciar o conjunto de réplicas com automação novamente, importe o conjunto de réplicas de volta para o Cloud Manager.

Clique em Add, selecione Existing MongoDB Deployment e continue adicionando Automation de volta ao seu cluster.

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Clique na aba Overview.

Clique no sistema e, em seguida, clique Restore or Download em .

Selecione o ponto de restauração.

1. Escolha o ponto de partida do qual deseja restaurar o backup.

   Tipo de Restauração	Descrição	em ação
   Snapshot	Permite escolher um snapshot armazenado.	Selecione um snapshot existente para restaurar.
   Point In Time	Cria um snapshot personalizado que inclui todas as operações até, mas não incluindo, o horário selecionado. Por padrão, o Oplog Store armazena 24 horas de dados. Por exemplo, se você selecionar 12:00, a última operação na restauração será 11:59:59 ou anterior. IMPORTANTE: no FCV 4.0, você não pode executar uma restauração de PIT que abranja qualquer momento anterior à última ressincronização de backup. Para saber as condições que causam uma ressincronização, consulte Sincronizar novamente um backup. Esta nota não se aplica ao FCV 4.2 ou posterior.	Selecione um Date e Time.
   Oplog Timestamp	Cria um snapshot personalizado que inclui todas as operações até e incluindo o carimbo de data/hora do oplog inserido. O registro de data e hora do oplog contém dois campos: Timestamp Registro de data/hora no número de segundos decorridos desde a UNIX epoch Increment Ordem de operação aplicada naquele segundo como um ordinal de 32 bits.	Digite um oplog Timestamp e Increment. Execute uma query em local.oplog.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

2. Clique em Next.

Para localizar a entrada de oplog mais recente, execute a seguinte query em mongosh:

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

Um resultado bem-sucedido deve ficar assim:

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

As partes do valor ts correspondem aos valores que você precisa para as caixas Timestamp e Increment .

Escolha restaurar os arquivos para outro cluster.

1. Clique em Choose Cluster to Restore to.

2. Preencha os seguintes campos:

   Campo	em ação
   Project	Selecione um projeto para o qual deseja restaurar o snapshot.
   Cluster to Restore to	Selecione um cluster no qual você deseja restaurar o snapshot. O Cloud Manager deve gerenciar o conjunto de réplicas de destino. AVISO: a automação remove todos os dados existentes do cluster. Ele preserva todos os dados de backup e snapshots do cluster existente.

2. Clique em Restore.

   O Cloud Manager observa quanto espaço de armazenamento a restauração exige.

Clique em Restore.

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Clique na aba Overview.

Clique no sistema e, em seguida, clique Restore or Download em .

Selecione o ponto de restauração.

1. Escolha o ponto de partida do qual deseja restaurar o backup.

   Tipo de Restauração	Descrição	em ação
   Snapshot	Permite escolher um snapshot armazenado.	Selecione um snapshot existente para restaurar.
   Point In Time	Cria um snapshot personalizado que inclui todas as operações até, mas não incluindo, o horário selecionado. Por padrão, o Oplog Store armazena 24 horas de dados. Por exemplo, se você selecionar 12:00, a última operação na restauração será 11:59:59 ou anterior. IMPORTANTE: no FCV 4.0, você não pode executar uma restauração de PIT que abranja qualquer momento anterior à última ressincronização de backup. Para saber as condições que causam uma ressincronização, consulte Sincronizar novamente um backup. Esta nota não se aplica ao FCV 4.2 ou posterior.	Selecione um Date e Time.
   Oplog Timestamp	Cria um snapshot personalizado que inclui todas as operações até e incluindo o carimbo de data/hora do oplog inserido. O registro de data e hora do oplog contém dois campos: Timestamp Registro de data/hora no número de segundos decorridos desde a UNIX epoch Increment Ordem de operação aplicada naquele segundo como um ordinal de 32 bits.	Digite um oplog Timestamp e Increment. Execute uma query em local.oplog.rs no seu conjunto de réplicas para encontrar o carimbo de data/hora desejado.

2. Clique em Next.

Para localizar a entrada de oplog mais recente, execute a seguinte query em mongosh:

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

Um resultado bem-sucedido deve ficar assim:

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

As partes do valor ts correspondem aos valores que você precisa para as caixas Timestamp e Increment .

Clique Download em para restaurar os arquivos manualmente.

Configure o download do snapshot.

1. Configure as seguintes opções de download:

   Pull Restore Usage Limit	Selecione quantas vezes o link pode ser usado. Se você selecionar No Limit, o link poderá ser reutilizado até expirar.
   Restore Link Expiration (in hours)	Selecione o número de horas até que o link expire. O valor padrão é 1. O valor máximo é o número de horas até que o snapshot selecionado expire.

2. Clique em Finalize Request.

3. Se você usar 2FA, o Cloud Manager solicitará seu código 2FA. Insira seu código 2FA e clique em Finalize Request.

No MongoDB Cloud Manager, Go a Continuous Backup página do seu projeto.

1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

3. Clique em Continuous Backup na barra lateral.

   A página Backup contínuo é exibida.

Retrieve the snapshots.

O Cloud Manager cria links para o snapshot. Por padrão, esses links estão disponíveis por uma hora e podem ser usados apenas uma vez.

Para baixar os snapshots:

1. Clique em Restore History.

2. Quando o tarefa de restauração for concluído, clique em (get link) para cada conjunto de réplicas ser exibido.

3. Clique em:

   • O botão copiar à direita do link para copiar o link para usá-lo mais tarde, ou

   • Download para fazer o download do snapshot imediatamente.

Restaure os arquivos de dados do snapshot no host de destino.

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

Execute o utilitário de restauração de backup do MongoDB (somente restauração pontual).

1. Baixe o utilitário de restauração de backup do MongoDB para o seu host.

   Observação

   Se você fechou o painel de restauração:

   1. No MongoDB Cloud Manager, Go a página Continuous Backup do seu projeto.

      1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

      2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

      3. Clique em Continuous Backup na barra lateral.

      A página Backup contínuo é exibida.

   2. Clique em More e depois em Download MongoDB Backup Restore Utility.

2. Inicie uma instância do mongod sem autenticação habilitada utilizando o diretório de captura instantânea extraído como o diretório de dados.

   Exemplo

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

   Aviso

   O Utilitário de Restauração de Backup MongoDB não oferece suporte a autenticação, portanto, você não pode iniciar esse banco de banco de dados temporário com autenticação.

3. Execute o utilitário de restauração de backup do MongoDB no host de destino. Execute-o uma vez para o conjunto de réplicas.

   Importante

   Comando mongodb-backup-restore-util pré-configurado

   O Cloud Manager fornece ao mongodb-backup-restore-util as opções apropriadas para sua restauração no painel de restauração em Run Binary with PIT Options.

   Você deve copiar o comando mongodb-backup-restore-util fornecido no Cloud Manager.

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --whitelist <database1.collection1, database2, etc.> \
      --blacklist <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>

   O comando mongodb-backup-restore-util utiliza as seguintes opções:

   Opção	necessidade	Descrição
   --host	Obrigatório	Forneça o nome do host, FQDN, endereço IPv4 ou endereço IPv6 do host que atende ao mongod ao qual o oplog deve ser aplicado. Se você copiou o comando mongodb-backup-restore-util fornecido no Cloud Manager, este campo será pré-configurado.
   --port	Obrigatório	Forneça a porta do host que atende ao mongod ao qual o oplog deve ser aplicado.
   --opStart	Obrigatório	Forneça o carimbo de data/ hora BSON para a primeira entrada de oplog que você deseja incluir na restauração. Essas informações aparecem na entrada "Last oplog Applied" no arquivo restoreInfo.txt fornecido com o snapshot baixado. Este valor deve ser menor ou igual ao valor de --opEnd .
   --opEnd	Obrigatório	Forneça o carimbo de data/ hora BSON para a última entrada de oplog que você deseja incluir na restauração. Esse valor não pode ser maior que o final do oplog.
   --logFile	Opcional	Forneça um caminho, incluindo o nome do arquivo, onde o log MBRU é gravado.
   --oplogSourceAddr	Obrigatório	Forneça a URL para o endpoint do recurso Cloud Manager .
   --apiKey	Obrigatório	Forneça sua chave APIdo Cloud Manager Agent.
   --groupId	Obrigatório	Forneça o ID do grupo .
   --rsId	Obrigatório	Forneça a ID do conjunto de réplicas .
   --whitelist	Opcional	Forneça uma lista de bancos de dados e/ou collections aos quais você deseja limitar a restauração.
   --blacklist	Opcional	Forneça uma lista de bancos de dados e/ou collections para os quais você deseja excluir da restauração.
   --seedReplSetMember	Opcional	Use se você precisar de um membro do conjunto de réplicas para recriar a coleção de oplog e semeá-la com o registro de data e hora correto. Exige --oplogSizeMB e --seedTargetPort.
   --oplogSizeMB	Condicional	Forneça o tamanho do oplog em MB. Obrigatório se --seedReplSetMember estiver definido.
   --seedTargetPort	Condicional	Forneça a porta para o primário do conjunto de réplicas . Isso pode ser diferente da porta efêmera usado. Obrigatório se --seedReplSetMember estiver definido.
   --ssl	Condicional	Use se precisar de TLS/SSL para aplicar o oplog ao mongod. Exige --sslCAFile e --sslPEMKeyFile.
   --sslCAFile	Condicional	Forneça o caminho para o arquivo da Autoridade de Certificação. Obrigatório se --ssl estiver definido.
   --sslPEMKeyFile	Condicional	Forneça o caminho para o arquivo de certificado PEM . Obrigatório se --ssl estiver definido.
   --sslPEMKeyFilePwd	Condicional	Forneça a senha do arquivo de certificado PEM especificado em --sslPEMKeyFile. Obrigatório se --ssl estiver definido e esse arquivo de chave PEM estiver criptografado.
   --sslClientCertificateSubject		Forneça o Assunto do Certificado do Cliente ou Nome Distinto (DN) para o processo MongoDB de destino.
   --sslRequireValidServerCertificates	Opcional	Defina um sinalizador indicando se a ferramenta deve validar os certificados que o processo MongoDB de destino apresenta.
   --sslServerClientCertificate	Opcional	Forneça o caminho absoluto para o arquivo de certificado do cliente a ser usado para se conectar ao host do Cloud Manager .
   --sslServerClientCertificatePassword	Condicional	Forneça o caminho absoluto para a senha do arquivo de Certificado do Cliente a ser usado para se conectar ao host do Cloud Manager . Necessário se --sslServerClientCertificate estiver definido e esse certificado for criptografado.
   --sslRequireValidMMSBackupServerCertificate	Opcional	Defina um sinalizador indicando se certificados válidos são necessários ao entrar em contato com o host do Cloud Manager . O valor padrão é true.
   --sslTrustedMMSBackupServerCertificate	Opcional	Forneça o caminho absoluto para os certificados confiáveis da Autoridade de Certificação no formato PEM para o host do Cloud Manager . Se esse sinalizador não for fornecido, a Autoridade de certificação do sistema será usada.
   --httpProxy	Opcional	Forneça a URL de um servidor proxy HTTP que a ferramenta pode usar.

   significa que, se você copiou o comando mongodb-backup-restore-util fornecido no Cloud Manager, esse campo será pré-configurado.

Cancele o gerenciamento do conjunto de réplicas.

Antes de tentar restaurar os dados manualmente, remova o conjunto de réplicas da automação.

Restaure o conjunto de réplicas manualmente.

Siga o tutorial do Manual MongoDB para restaurar o conjunto de réplicas.

Reimportar o conjunto de réplicas.

Para gerenciar o conjunto de réplicas com automação novamente, importe o conjunto de réplicas de volta para o Cloud Manager.