Preparações de backup
Nesta página
- A autenticação OAuth 2.0 para acesso programático ao Cloud Manager está disponível como um recurso de visualização.
- O recurso e a documentação correspondente podem mudar a qualquer momento durante o período de Pré-visualização. Para usar a 2.0 autenticação OAuth, crie uma conta de serviço para usar em suas solicitações para a API pública do Cloud Manager .
Antes de fazer o backup de seu cluster ou conjunto de réplicas, decida como fazer o backup dos dados e de quais dados fazer o backup. Esta página descreve os itens que você deve considerar antes de iniciar uma cópia de segurança.
Recomendação de dimensionamento de backup
Ao dimensionar a cópia de segurança dos seus dados, mantenha o tamanho do conjunto de réplicas para 2 TB ou menos de dados não comprimidos. Se o seu banco de dados ultrapassar 2 TB de dados não compactados:
Fragmentar o banco de dados
Mantenha cada fragmento a 2 TB ou menos de dados não compactados
Essas recomendações de tamanho são uma prática recomendada. Elas não são uma limitação do MongoDB database ou do Cloud Manager.
O backup e a restauração podem usar grandes quantidades de CPU, memória, armazenamento e largura de banda da rede.
Exemplo
A taxa de transferência de rede declarada, como 10 Gbps ou 100 Gbps, é um máximo teórico. Esse valor não leva em conta o compartilhamento ou a limitação do tráfego de rede.
Considere o seguinte cenário:
Você quer fazer backup de um banco de dados de 2 TB.
Seus hosts suportam uma conexão TCP de 10 Gbps do Cloud Manager ao armazenamento de backup.
A conexão de rede tem uma perda de pacotes muito baixa e um baixo tempo de atraso de ida e volta.
Um backup completo dos seus dados levaria mais de 30 horas para ser concluído. [1]
Isso não leva em conta as velocidades de leitura e gravação do disco, que podem ser, no máximo, leituras de 3 Gbps e gravações de 1 Gbps para um dispositivo de armazenamento NVMe único ou espelhado.
O tempo necessário para concluir cada backup incremental sucessivo depende da carga de gravação.
Se você fragmentar esse banco de dados em 4 shards, cada shard executará seu backup separadamente. Isso resulta em um backup que leva menos de 8 horas para ser concluído.
| [1] | Esses valores de taxa de transferência foram calculados usando a Calculadora de taxa de transferência de rede e não assuma nenhuma compactação de rede adicional. |
Frequência de snapshots e política de retenção
Por padrão, o Cloud Manager tira um snapshot básico de seus dados a cada 6 horas.
Se desejar, os administradores podem alterar a frequência dos snapshots de base para 6, 8, 12 ou 24 horas. Cloud Manager cria snapshots automaticamente em um cronograma; não é possível tirar snapshots sob demanda.
O Cloud Manager retém snapshots durante os períodos de tempo listados na tabela a seguir.
Se você encerrar o backup de um sistema, o Cloud Manager excluirá imediatamente os snapshots que estão dentro das datas da política de retenção atual.
Se você interromper o backup de uma implementação, o Cloud Manager deixará de tirar novos snapshots, mas manterá os snapshots existentes até a data de expiração listada.
Snapshot | Política de retenção padrão | Política de retenção máxima |
|---|---|---|
Snapshot de base | 2 dias | 5 dias (30 dias se a frequência for de 24 horas) |
Snapshot diário | 7 dias | 1 ano |
Snapshot semanal | 4 semanas | 1 ano |
Snapshot mensal | 13 meses | 7 anos |
As alterações no agendamento de snapshots afetam seus custos de armazenamento de snapshots.
Você pode alterar o agendamento de um sistema de backup por meio da opção de menu Edit Snapshot Schedule, disponível na página Backup. Os administradores podem alterar a frequência e a retenção de snapshots por meio do recurso SnapshotSchedule na API.
Você não pode alterar o tempo de referência para um snapshot no Cloud Manager.
Limites
O Cloud Manager não faz backup de deployments onde o número total de collection no deployment é igual ou superior a
100,000.O Cloud Manager não replica as opções de collection de índice.
Criptografia
Não é possível armazenar backups usando a criptografia WiredTiger. Você pode armazenar backups usando o storage engine WiredTiger se não habilitar a criptografia. Se você restaurar a partir de um backup, restaurará arquivos não criptografados.
Considerações de backup
Consistência e snapshots
Para clusters que executam MongoDB versão 4.2 ou posterior:
O Cloud 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 edb.[collection].count()podem ser imprecisas.O Cloud 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 Cloud Manager mantém snapshots consistentes com falhas.
O Cloud 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
Recursos de backup suportados no momento
funcionalidade | Bancos de dados com FCV 4.2 e posteriores | Bancos de dados com FCV 4.0 e anteriores |
|---|---|---|
Faz backup de dados usando snapshots WiredTiger | ||
Faz o backup de dados usando o Daemon de backup | ||
Faz backup de conjuntos de réplicas | ||
Faz backup de clusters fragmentados | ||
Pode filtrar usando Namespaces [2] | ||
Pode especificar banco de dados de origem de sincronização | ||
Pode restaurar dados para um ponto específico no tempo [3] | ||
Pode executar backups incrementais [4] | ||
Suporta snapshots que usam criptografiaKMIP [5] | ||
Suporta snapshots que usam criptografia de chave local [6] | ||
Suporta o salvamento no armazenamento de snapshot do S3 | ||
Oferece suporte a bancos de dados que executam o MongoDB Enterprise | ||
Suporta bancos de dados que executam o MongoDB Community | ||
Requer um MongoDB Agent com backup ativado em cada nó do cluster mongod |
| [2] | A filtragem de namespace é permitida apenas nas versões 6.0.8 e posteriores do Cloud Manager. Seus sistemas do MongoDB devem ter featureCompatibilityVersion valores de 4.0 e anteriores, ou 6.0.1 e posteriores. |
| [3] | A execução de uma restauração do PIT exige o Ops Manager 4.2.13 ou posterior. |
| [4] | O Cloud Manager requer um backup completo para seu primeiro backup, após a exclusão de um snapshot e se o tamanho do bloco blockstore tiver sido alterado. Backups incrementais reduzem os custos de transferência e armazenamento da rede. Esse recurso funciona com:
|
| [5] | A query de um snapshot criptografado requer o MongoDB Enterprise 4.2.9 e posterior ou 4.4.0 e posterior. |
| [6] | FCV Os backups 4.2 e posteriores não oferecem suporte à criptografia de chave local. |
| [7] | Os backups de um banco de dados FCV 4.2 ou posterior em um armazenamento de sistema de arquivos ignoram File System Store Gzip Compression Level. |
Requisitos e limitações
Para executar backups e restaurações se estiver executando o MongoDB 4.2 ou posterior com FCV 4.2 ou posterior, você:
Deve executar o MongoDB Enterprise.
Deve levar em conta a mudança no tamanho do bloco do blockstore. Se você não definiu o tamanho do bloco e usou o padrão, esse tamanho muda de 64 KB para 1 MB. Isso pode afetar o uso do armazenamento.
Deve garantir que os nomes de host na configuração do conjunto de réplicas correspondam aos nomes de host usados pelo MongoDB Agent ou que seus mapeamentos de host contenham os nomes de host corretos. Você pode usar rs.conf() para verificar a configuração do conjunto de réplicas.
Pode usar listas de filtros de namespace para definir os namespaces incluídos em um backup somente se você estiver executando o MongoDB 6.0 ou posterior. Os snapshots obtidos nas versões 4.2 a 5.0 do MongoDB sempre incluem todos os namespaces.
Não precisa de um reconhecimento de data center de origem de sincronização. Ao tirar um snapshot, o Cloud Manager seleciona o nó do conjunto de réplicas com o menor impacto no desempenho e a maior duplicação de dados do snapshot no nível de armazenamento.
É necessário implantar um MongoDB Agent em cada nó
mongodno cluster.
Observação
Se o Cloud Manager não managed seu cluster:
Conceda as funções
backupeclusterAdminao usuário MongoDB que executa backups.Certifique-se de que o usuário do sistema operacional que executa o MongoDB Agent tenha permissão de leitura para todos os arquivos de dados (incluindo arquivos de diário) da implantação.
Bancos de dados com FCV 4.0 e versões anteriores
Importante
Somente conjuntos de réplicas ou clusters fragmentados podem ser armazenados em backup. Para fazer backup de um processo mongod autônomo, você deve convertê-lo em um conjunto de réplicas de nó único.
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 Cloud Manager gerencia snapshots expirados usando tarefas de limpeza. Essas tarefas de limpeza agem de maneira diferente dependendo de qual armazenamento de snapshots contém os snapshots:
Armazenamento de snapshots | Como funcionam as tarefas de limpeza |
|---|---|
Loja de blocos do MongoDB | Usa disk space adicional até a quantidade de living blocks para cada tarefa. |
Armazenamentos de snapshots do sistema de arquivos | Exclui snapshots expirados |
Armazenamentos de snapshots do S3 | Pode usar espaço em disco adicional se o Cloud Manager criar um snapshot enquanto a tarefa de limpeza é executada. O Cloud Manager pode executar tarefas simultâneas de limpeza em armazenamentos de snapshots do S3. |
Observação
As tarefas de snapshot e de limpeza não podem ser executadas simultaneamente. Se você iniciar um trabalho de limpeza enquanto um trabalho de limpeza estiver em execução, o trabalho de limpeza falhará e o MongoDB Ops Manager registrará um erro e tentará automaticamente de novo o trabalho de limpeza após a conclusão do trabalho de snapshot. Se você iniciar um trabalho de snapshot enquanto uma tarefa de limpeza estiver em execução, a tarefa de snapshot falhará e o MongoDB Ops Manager registrará um erro e tentará novamente a tarefa de snapshot após a conclusão da tarefa de limpeza.
Filtro de namespaces
O filtro de namespace permite especificar quais bancos de dados e collections fazer backup. 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.
Observação
A filtragem de namespace é compatível apenas com as versões 6.0.8 e posteriores do Cloud Manager. Seus sistemas do MongoDB devem ter featureCompatibilityVersion valores de 4.0 e anteriores, ou 6.0.1 e posteriores.
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:
Com o WiredTiger, o Cloud Manager limita os backup para sistemas com menos de 100.000 arquivos. Os arquivos incluem collection 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 Cloud 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 storage engine, se quiser que o Cloud Manager forneça snapshots no novo formato de storage engine.
Construa um índice em um conjunto de réplicas de forma contínua.
Pontos de verificação
Importante
Você pode utilizar pontos de verificação para clusters que executam MongoDB com Feature Compatibility Version de 4.0 ou anterior. Os pontos de controle foram removidos das instâncias do MongoDB com FCV 4.2 ou posterior.
Para clusters fragmentados, os checkpoints fornecem pontos de restauração adicionais entre snapshots. Com os pontos de controle habilitados, o Cloud 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 Cloud Manager interrompe o balancer e insere um token no oplog de cada shard 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 Cloud Manager aplique o oplog de cada shard 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 Cloud 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 Cloud Manager tenta desabilitar o balancer, mas não consegue. Nesses casos, o Cloud 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 Cloud Manager não cria o snapshot e exibe uma mensagem de aviso.