Perguntas frequentes: backup e restauração

Quais permissões do MongoDB o Backup exige?

Se você estiver fazendo backup de uma instância do MongoDB que tenha a autenticação habilitada, o MongoDB Agent exigirá o privilégio descritos para a função de backup do MongoDB Agent.

Como o Cloud Manager mede o tamanho dos dados?

O Cloud Manager usa as seguintes conversões para medir o tamanho do snapshot e a quantidade de dados do oplog que foram processados:

• 1 MB = 1024 ² bytes (1 MiB)

• 1 GB = 1024 ³ bytes (1 GiB)

• 1 TB = 1024 ⁴ bytes (1TiB)

O backup funciona com todos os tipos de sistemas?

• Para o MongoDB 4.2 e posterior, consulte Considerações de backup para reconhecimento de data center.

• Para qualquer MongoDB com FCV 4.0 e bancos de dados anteriores, o Backup não oferece suporte a autônomo . O Backup tem suporte completo para conjuntos de réplica e clusters fragmentados.

Por que o recurso de backup não suporta sistemas autônomo?

O Cloud Manager copia dados do oplog para fornecer um backup contínuo com recuperação point-in-time. O Cloud Manager não oferece suporte ao backup de hosts autônomo porque eles não têm um oplog. Para oferecer suporte ao backup com uma única instância mongod , você pode executar um conjunto de réplicas de um membro.

O backup terá impacto no meu reconhecimento de data center de produção?

O recurso de backup normalmente tem impacto mínimo nas implantações de produção do MongoDB. Este impacto tem desempenho semelhante ao da adição de um novo secundário a um conjunto de réplicas.

Por padrão, o agente executa sua sincronização inicial, a operação que mais consome recursos para backups, em um membro secundário do conjunto de réplicas para limitar seu impacto. Opcionalmente, você pode configurar o agente para executar a sincronização inicial com o primary do conjunto de réplicas, embora isso aumente o impacto da operação de sincronização inicial .

Como faço para manter um conjunto de réplicas com o Backup habilitado?

A maioria das operações em um conjunto de réplicas é replicada por meio do oplog e, portanto, capturada pelo processo de backup. Algumas operações, no entanto, fazem alterações que não são replicadas: para essas operações, você deve fazer com que o Cloud Manager seja ressincronizado a partir do seu conjunto de réplicas atual para incluir as alterações.

As seguintes operações não são replicadas e, portanto, exigem ressincronização:

• Renomeando ou excluindo um banco de dados de dados excluindo os arquivos de dados no diretório de dados de dados. Como alternativa, remova bancos de dados usando uma operação que o MongoDB replicará, como db.dropDatabase() de mongosh.

• Alterar quaisquer dados enquanto a instância está sendo executada como um arquivo autônomo.

• Compilações de índice contínuo.

• Usando compact ou repairDatabase para recuperar uma quantidade significativa de espaço.

  A ressincronização não é estritamente necessária após operações compact ou repairDatabase , mas garantirá que a cópia dos dados do Cloud Manager seja redimensionada, o que significa restaurações mais rápidas e custos mais baixos.

Onde devo executar o agente de backup?

Execute o agente de backup em um host que:

• É separado de suas instâncias do MongoDB. Isso evita a contenção de recursos do sistema.

• Pode se conectar às suas instâncias MongoDB. Verifique as configurações de rede para conexões entre o agente e os hosts MongoDB. Para obter uma lista das portas necessárias, consulte as portas abertas para os agentes.

• Tem pelo menos 2 núcleos de CPU e 3 GB de RAM acima dos requisitos da plataforma. Com cada tarefa de backup executada, o agente de backup impacto ainda mais o desempenho do host.

Posso executar o agente de backup e agente de monitoramento em um único sistema?

Não há restrição técnica que impeça o agente de backup e o Monitoring de serem executados em um único sistema ou host. No entanto, ambos os agente têm requisitos de recursos, e a execução de ambos em um único sistema pode afetar a capacidade desses agente de oferecer suporte à sua implantação no Cloud Manager.

Os recursos exigidos pelo agente de backup dependem da taxa e do tamanho das novas entradas de oplog (ou seja, total de gigabyte de oplog/hora produzido). Os recursos que o monitoramento exige dependem do número de instâncias mongod monitoradas e do número total de bancos de dados fornecidos pelas instâncias mongod .

Posso executar vários agentes de backup para obter alta disponibilidade?

Você pode executar vários agentes de backup para alta disponibilidade. Se você fizer isso, os agentes de backup deverão ser executados em hosts diferentes.

Quando você executa vários agentes de backup, apenas um agente por projeto é o agente principal. O agente primary executa os backups. Os agente restantes estão completamente ociosos, exceto para registrar seu status como standbys e perguntar periodicamente ao Cloud Manager se eles devem se tornar o primary.

O agente de backup modifica meu reconhecimento de data center?

O agente de backup grava um pequeno token chamado checkpoint no oplog do reconhecimento de data center em um intervalo regular. Esses tokens fornecem uma pulsação para backups e não afetam o sistema de origem. Cada token tem menos de 100 bytes.

Como a sincronização de backup inicial impacto o desempenho do reconhecimento de data center?

O impacto da sincronização do backup inicial deve ser semelhante à sincronização de um novo membro do conjunto de réplicas secundário. O agente de backup não limita sua atividade e tenta realizar a sincronização o mais rápido possível.

Como posso impedir que o Cloud Manager faça backup de uma collection?

O Cloud Manager fornece um filtro de namespace que permite especificar quais collection ou reconhecimento de data center fazer backup.

Como posso alterar quais namespaces são armazenados em backup?

Para editar o filtro, consulte Editar as configurações de um backup. Alterar o filtro de namespaces pode exigir uma ressincronização. Em caso afirmativo, o Cloud Manager lida com a ressincronização.

Como o Cloud Manager fornece restaurações de ponto no tempo?

Quando você trigger a restauração, o Cloud Manager cria um link para esse snapshot. Uma vez clicado, o Cloud Manager recupera blocos do Snapshot Store e os transmite para o host de destino.

O utilitário MongoDB Backup Restore em execução nesse host baixa e aplica as entradas do oplog para atingir o ponto especificado no tempo.

O Cloud Manager pode fazer uma restauração para qualquer point-in-time dentro de um período de 24 horas, reproduzindo o oplog no horário desejado.

Para saber como restaurar conjuntos de réplicas e clusters fragmentados, consulte Restaurar implementações do MongoDB.

Posso tirar snapshots com mais frequência do que a cada 6 horas?

Não. O Cloud Manager não suporta um agendamento de snapshot mais frequente do que a cada 6 horas. Para obter mais informações, consulte frequência de snapshots e política de retenção.

Posso definir minha própria política de retenção de snapshots?

Sim. Você pode alterar o agendamento por meio da opção de menu Edit Snapshot Schedule para um sistema de backup. Os administradores podem alterar a frequência de snapshots e política de retenção por meio do recurso snapshotSchedule na API.

A personalização da frequência de snapshots e as políticas de retenção oferecem a você maior controle sobre os custos de backup.

Quanto tempo leva para criar um snapshot de restauração?

O Cloud Manager transmite todos os backups de forma compactada do host do Cloud Manager para a sua infraestrutura.

Dentro dos EUA, o Cloud Manager envia snapshots de 50 a 100 Sync. Assumindo um fator de compressão de 4x e velocidades de transmissão de 50 MX, a transmissão de um instantâneo de 250 GB leva 2,5 horas.

Além disso, as restaurações point-in-time dependem da quantidade que as entradas de oplog que seu host deve aplicar ao snapshot recebido para avançar para o point-in-time solicitado do backup.

O recurso de backup executa alguma validação de dados?

O backup realiza verificações básicas de corrupção e fornece um alerta se algum componente (por exemplo, o agente) estiver inativo ou quebrado, mas não executa validação de dados explícita. Ao detectar corrupção, o Cloud Manager comete um erro por excesso de cautela, invalida o backup atual e envia um alerta.

Como faço para restaurar um snapshot?

Você pode solicitar uma restauração por meio do Cloud Manager, onde pode escolher qual snapshot restaurar e como deseja que o Cloud Manager forneça a restauração. Todas as restaurações exigem autenticação de dois fatores. Se você tiver o SMS configurado, o Cloud Manager enviará um código de autorização por SMS. Você deve inserir o código de autorização na interface de backup para iniciar o processo de restauração.

O que é entregue quando restauro um snapshot?

O Cloud Manager fornece restaurações como arquivos tar.gz de Data Federation MongoDB.

Para saber mais sobre restaurações, consulte Restaurar implementações do MongoDB.

Como o Cloud Manager reverte os dados de backup?

Se o sistema do MongoDB sofrer um rollback, o Cloud Manager também reverterá os dados de backup.

O Cloud Manager detecta a reversão quando um cursor de cauda encontra uma incompatibilidade em carimbos de data/hora ou hashes de operações de gravação. O Cloud Manager entra em um estado de rollback e testa três pontos no oplog do primary do seu conjunto de réplicas para localizar um ponto comum no histórico. A reversão do Cloud Manager difere da reversão secundária do MongoDB porque o ponto comum não precisa necessariamente ser o ponto comum mais recente .

Quando o Cloud Manager encontra um ponto, o serviço invalida as entradas de oplog e snapshots além desse ponto e reverte para o snapshot mais recente antes do ponto. O Cloud Manager retoma as operações normais de backup.

Se o Cloud Manager não conseguir encontrar um ponto comum, será necessária uma ressincronização .

Quais condições exigem uma ressincronização?

Se o cursor tailing do agente de backup não conseguir acompanhar o oplog do seu sistema, você deverá sincronizar novamente os backups.

Esse cenário pode ocorrer se:

• Sua aplicação gera periodicamente muitos dados, reduzindo a oplog window do primary a ponto de os dados serem gravados no oplog mais rápido do que o Cloud Manager consegue consumi-los.

• Se o agente de backup estiver sendo executado em uma máquina com provisionamento insuficiente ou usado em excesso e não conseguir acompanhar a atividade de oplog.

• Se o agente de backup estiver inativo por um período de tempo maior do que o tamanho do oplog permite. Se você desligar seus agentes, como para manutenção, reinicie-os em tempo hábil. Para obter mais informações sobre o tamanho do oplog , consulte Conjunto de réplicas do oplog no manual do MongoDB .

• Se você excluir todos os dados do conjunto de réplicas e implantar um novo conjunto de réplicas com o mesmo nome, o que poderá acontecer em um ambiente de teste em que as implantações são regularmente desativadas e reconstruídas.

• Se houver uma reversão, e o Cloud Manager não conseguir encontrar um ponto comum no oplog.

• Se um evento oplog tentar atualizar um documento que não existe no backup do conjunto de réplicas, como poderá acontecer se sincronizar a partir de um secundário que tenha dados inconsistentes com o primário.

• Se você criar um índice de forma contínua.