Preparações de backup

Características do método de backup

* Para executar um backup incremental em um File System Store, o MongoDB Agent fatia cada arquivo do mecanismo de armazenamento no caminho especificado para backup em bloco(s) de dados e transfere apenas o(s) bloco(s) alterado(s) para o Ops Manager. O Ops Manager cria um novo snapshot do(s) bloco(s) recebido(s) e copia o(s) bloco(s) restante(s) inalterado(s) do snapshot de backup completo anterior. Cada snapshot de backup incremental armazenado em um sistema de arquivos salva a E/S da rede. Cada snapshot de backup contém uma cópia completa de todos os arquivos necessários de um sistema de backup do MongoDB e não elimina a duplicação de registros.

Limites

• O Ops Manager não faz backup de sistemas em que o número total de collections no sistema seja igual ou superior a 100,000.

• O Ops Manager não replica as opções de collection de índice.

Criptografia

O MongoDB Ops Manager pode criptografar qualquer tarefa de backup armazenado em um head database executando o MongoDB Enterprise entre FCV 3.4 e 4.0 com o mecanismo de armazenamento WiredTiger .

FCV 4.2 e, posteriormente, use cursores de backup em vez de head databases. Para obter mais informações, consulte o Serviço Backup Daemon .

Consistência e snapshots

Para clusters que executam MongoDB versão 4.2 ou posterior:

• MongoDB Ops Manager mantém a consistência causal ao tirar snapshots, exceto para estatísticas de tamanho relatadas por collStats e db.[collection].count(). As estatísticas de tamanho relatadas por collStats e db.[collection].count() podem ser imprecisas.

• O Ops Manager coordena o tempo em todos os shards para clusters fragmentados. Isso garante que os snapshots incluam todos os documentos gravados em cada shard e nó a partir do horário agendado para o snapshot.

Para clusters que executam MongoDB versão 4.0 e anterior:

• O Ops Manager mantém snapshots consistentes com falhas.

• Ops Manager tira snapshots de cada um dos shards para clusters fragmentados e dos Conjuntos de Réplicas do Servidor de Configuração aproximadamente ao mesmo tempo.

Bancos de dados com FCV 4.2 e posteriores

Bancos de dados com FCV 4.0 e versões anteriores

As seguintes considerações se aplicam quando seus bancos de dados executam qualquer versão do MongoDB 4.0 ou anterior ou quando executam o MongoDB 4.2 com "featureCompatibilityVersion" : 4.0

Coleta de lixo de snapshots expirados

O Ops Manager gerencia snapshots expirados usando tarefas de limpeza. Essas tarefas de limpeza agem de forma diferente, dependendo de qual armazenamento de snapshot contém os snapshots:

Para saber mais sobre tarefas de limpeza, consulte Tarefas de limpeza.

Filtro de namespaces

O filtro de namespace permite especificar quais bancos de dados e collections fazer backup. Você pode aplicar um filtro de namespace a qualquer banco de dados de dados, exceto admin e local , e a qualquer collection que não comece com system.

Você cria uma Blacklist dessas para excluir ou uma Whitelist delas para incluir. Você faz suas seleções ao iniciar um backup e pode editá-las posteriormente conforme necessário. Se você alterar o filtro de uma maneira que adiciona dados ao seu backup, uma ressincronização será necessária.

Use a blacklist para evitar o backup de collections que contenham dados de registro, caches ou outros dados efêmeros. Excluir esses tipos de bancos de dados e collections permitirá reduzir o tempo e os custos de backup. O uso de uma blacklist geralmente é preferível ao uso de uma whitelist, pois esta exige que você opte intencionalmente por todos os namespaces dos quais deseja fazer backup.

Mecanismo de armazenamento

Para fazer backup de clusters do MongoDB, use o mecanismo de armazenamento WiredTiger.

Se os seus bancos de dados de apoio atuais usam o MMAPv1, faça o upgrade para o WiredTiger:

• Alterar Cluster fragmentado para WiredTiger

• Alterar conjunto de réplicas para WiredTiger

Com o WiredTiger, o Ops Manager limita os backup para sistemas com menos de 100.000 arquivos. Os arquivos incluem collections e índices.

O MongoDB 4.2 remove o armazenamento MMAPv1 . Para saber mais sobre os mecanismos de armazenamento, consulte Armazenamento no manual MongoDB.

Ressincronizando sistemas de produção

Para sistemas de produção, sincronize novamente todos os conjuntos de réplicas de backup periodicamente, como uma vez por ano. Quando você sincroniza novamente, os dados são lidos de um secundário em cada conjunto de réplicas. Durante a ressincronização, nenhum novo snapshot é gerado.

Você também pode sincronizar novamente seu backup se:

• Reduza o tamanho dos dados, de modo que o tamanho da cópia dos dados em disco do Ops Manager também seja reduzido.

• Crie um índice TTL, que exclui documentos periodicamente.

• Descartar uma collection (somente MMAPv1 ).

• Execute um cluster fragmentado e mova partes de um fragmento específico.

• Troque os mecanismos de armazenamento, se quiser que o Ops Manager forneça snapshots no novo formato de mecanismo de armazenamento.

• Construa um índice em um conjunto de réplicas de forma contínua.

Pontos de verificação

Para clusters fragmentados, os checkpoints fornecem pontos de restauração adicionais entre snapshots. Com os pontos de controle habilitados, o MongoDB Ops Manager cria pontos de restauração em intervalos configuráveis de cada 15, 30 ou 60 minutos entre capturas de imagem. Para ativar os pontos de verificação, consulte ativar pontos de verificação.

Para criar um checkpoint, o Ops Manager interrompe o balanceador e insere um token no oplog de cada fragmento e servidor de configuração no cluster. Esses tokens de checkpoint são leves e não afetam o desempenho ou o uso do disco.

O backup não requer pontos de verificação e eles estão desabilitados por padrão.

A restauração a partir de um checkpoint exige que o Ops Manager aplique o oplog de cada fragmento e servidor de configuração ao último snapshot capturado antes do checkpoint. A restauração a partir de um checkpoint leva mais tempo do que a restauração a partir de um snapshot.

Snapshots quando o agente não consegue parar o balanceador

Para clusters fragmentados em execução com FCV 4.0 ou anterior, o MongoDB Ops Manager desabilita o balancer antes de obter um snapshot do cluster. Em determinadas situações, como uma migração longa ou nenhum mongos em execução, o MongoDB Ops Manager tenta desabilitar o balancer, mas não consegue. Nesses casos, o MongoDB Ops Manager continua a tirar snapshots do cluster, mas sinaliza os snapshots que podem ter dados incompletos ou inconsistentes. Os snapshots de cluster obtidos durante uma operação de balanceamento ativo correm o risco de perda de dados ou dados órfãos.

Snapshots quando o agente não consegue entrar em contato com um mongod

Para clusters fragmentados, se o backup não puder acessar um processo mongod, seja um fragmento ou um servidor de configuração, o agente não poderá inserir um token de oplog de sincronização. Nestes casos, o Ops Manager não cria o snapshot e exibe uma mensagem de aviso.