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.
Dica
Para saber como funciona o Backup, consulte Backup.
Recomendação de dimensionamento de backup
When sizing the backup of your data, keep the replica set size to 2 TB or less of uncompressed data. If your database increases beyond 2 TB of uncompressed data:
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.
A full backup of your data would take more than 30 hours to complete. [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 pressupõem 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 a programação de um sistema com 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 SnapshotSchedulena 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:
Cloud Manager maintains causal consistency when taking snapshots except for size statistics reported by
collStatsanddb.[collection].count(). Size statistics reported bycollStatsanddb.[collection].count()may be inccurate.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 | ||
Can Filter using Namespaces [2] | ||
Pode especificar banco de dados de origem de sincronização | ||
Can Restore Data to Specific Point in Time [3] | ||
Can Perform Incremental Backups [4] | ||
Suporta snapshots que usam criptografia KMIP [5] | ||
Supports Snapshots that use Local Key Encryption [6] | ||
Suporta o processo de salvar 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 | ||
Requires a MongoDB Agent with backup enabled on every |
| [6] | 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 restaurar do PIT exige o MongoDB Ops Manager 4.2.13 ou posterior. |
| [4] | O Cloud Manager requer um backup completo para seu primeiro backup, após excluir um snapshot e se o tamanho do bloco blockstore tiver sido alterado. Backups incrementais reduzem os custos de transferência e armazenamento da rede. Este recurso funciona com:
|
| [5] | Querying an encrypted snapshot requires MongoDB Enterprise 4.2.9 and later or 4.4.0 and later. |
| [6] | FCV 4.2 and later backups don't support local key encryption. |
| [ 7 ] | Backups to a FCV 4.2 or later database to a File System Store ignore File System Store Gzip Compression Level. |
Requisitos e limitações
To run backups and restores if you are running MongoDB 4.2 or later with FCV 4.2 or later, you:
Must run 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.
Must ensure the hostnames in your replica set configuration match the hostnames that the MongoDB Agent uses, or that your host mappings contain the correct hostnames. You can use
rs.conf()to verify your replica set configuration.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.
Must deploy a MongoDB Agent with every
mongodnode in the cluster.
Observação
Se o Cloud Manager não managed seu cluster:
Grant the
backupandclusterAdminroles to the MongoDB user that runs 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
Only sharded clusters or replica sets can be backed up. To back up a standalone mongod process, you must convert it to a single-member replica set.
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 Deny List 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 lista de bloqueio para evitar o backup de coleções 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 lista de bloqueios geralmente é preferível ao uso de uma lista de permissões, pois esta exige que você opte intencionalmente por todos os namespace 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
To back up MongoDB clusters, use the WiredTiger storage engine storage engine.
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.
MongoDB 4.2 removes MMAPv1 storage. To learn more about storage engines, see Storage Engines in the MongoDB manual.
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.
Drop a collection(Somente MMAPv1).Run a sharded cluster, and move chunks from a particular shard.
Troque os storage engine, se quiser que o Cloud Manager forneça snapshots no novo formato de storage engine.
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.
For sharded clusters, checkpoints provide additional restore points between snapshots. With checkpoints enabled, Cloud Manager creates restoration points at configurable intervals of every 15, 30 or 60 minutes between snapshots. To enable checkpoints, see enable checkpoints.
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.
Restoring from a checkpoint requires Cloud Manager to apply the oplog of each shard and config server to the last snapshot captured before the checkpoint. Restoration from a checkpoint takes longer than restoration from a snapshot.
Snapshots quando o agente não consegue parar o balanceador
For sharded clusters running with FCV 4.0 or earlier, Cloud Manager disables the balancer before taking a cluster snapshot. In certain situations, such as a long migration or no running mongos, Cloud Manager tries to disable the balancer but cannot. In such cases, Cloud Manager continues to take cluster snapshots but flags the snapshots that may have incomplete or inconsistent data. Cluster snapshots taken during an active balancing operation run the risk of data loss or orphaned data.
Snapshots quando o agente não consegue entrar em contato com um mongod
For sharded clusters, if the Backup can't reach a mongod process, whether a shard or config server, then the agent can't insert a synchronization oplog token. In these cases, Cloud Manager doesn't create the snapshot and displays a warning message.