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.
Aviso
O MongoDB Ops Manager não permite mais a criação de snapshots de cluster a partir de sistemas de banco de dados que usam criptografia de chave local. Se você criptografar um sistema de banco de dados com criptografia de chave local, o snapshot falhará. Para criptografar snapshots, use criptografia baseada em KMIPcom seus sistemas de banco de dados.
Opções de configuração de backup
Os requisitos de backup e recuperação de um determinado sistema variam para atender aos padrões de custo, desempenho e proteção de dados definidos pelo proprietário do sistema.
O Ops Manager Enterprise Backup and Recovery oferece suporte a cinco arquiteturas de backup, cada uma com seus próprios pontos fortes e desvantagens. Considere a arquitetura que atende os requisitos de proteção de dados de seu sistema antes de configurar e implementar sua arquitetura de backup.
Exemplo
Considere um sistema cujos requisitos incluam baixos custos operacionais. Os proprietários do sistema podem ter limites estritos sobre o que podem gastar em armazenamento para configuração de backup e recuperação. Como resultado, eles podem aceitar um tempo de recuperação mais longo.
Por outro lado, considere um sistema cujos requisitos incluem um objetivo de tempo de recuperação baixo. Os proprietários do sistema toleram maiores custos de armazenamento se isso resultar em uma configuração de backup e recuperação que atenda aos requisitos de recuperação.
OOps Manager Enterprise Backup and Recovery oferece suporte às seguintes arquiteturas de backup:
Um sistema de arquivos em um SAN com recursos avançados para backups do sistema de arquivos, como alta disponibilidade
Um sistema de arquivos em um ou mais dispositivos NAS
Armazenamento de blocos do MongoDB em uma configuração altamente disponível
Blockstore do MongoDB em uma configuração standalone
Fornecemos as recomendações da arquitetura de backup como orientação para desenvolver suas próprias abordagens de proteção de dados. Nossas recomendações não abrangem nem representam cada cenário ou sistema.
Características do método de backup
Recurso do sistema de backup | Sistema de arquivos no SAN | Sistema de arquivos no NAS | Armazenamento de blocos do AWS S3 | MongoDB HA Blockstore | Loja de blocos do MongoDB |
|---|---|---|---|---|---|
Tipos de Snapshot | Completo * | Completo * | Muitos | Muitos | Muitos |
Eliminação de duplicação de dados de backup | Se a SAN suportar | No | Sim | Sim | Sim |
Compactação de dados de backup | Sim | No | Sim | Sim | Sim |
Replicação de dados de backup | Se a SAN suportar | No | No | Sim | No |
Custo de armazenamento de backup | Mais alto | Médio | Mais baixo | Mais alto | Mais baixo |
Tempo da equipe para gerenciar backups | Médio | Médio | Mais baixo | Mais alto | Médio |
Backup RTO | Mais baixo | Médio | Mais baixo | Mais baixo | Médio |
* To perform an incremental backup to a File System Store, the MongoDB Agent slices each storage engine file in the path specified for backup into block(s) of data and transfers only changed block(s) to Ops Manager. Ops Manager creates a new snapshot from received block(s) and copies the remaining unchanged block(s) from the previous backup snapshot. Each incremental backup snapshot stored to a file system saves network I/O. Each such backup snapshot contains a full copy of all required files from a backed up MongoDB deployment and does not de-duplicate records.
Observação
Quando você usa um método de backup específico?
Para executar backups frequentemente em grandes quantidades de dados e restaurar a partir de backups, considere fazer backup em um sistema de arquivos em um SAN, um armazenamento de snapshots compatível com o Amazon Web Services S3ou um armazenamento de blocos do MongoDB configurado como um conjunto de réplicas ou um cluster fragmentado.
Para restaurar os dados sem depender do banco de dados MongoDB, considere fazer backup em um armazenamento de snapshots compatível com AWS S3, em um ou mais dispositivos NAS ou em um sistema de arquivos em um SAN com recursos avançados para backups de sistemas de arquivos, como alta disponibilidade.
Para minimizar os custos internos de armazenamento e manutenção, considere fazer backup em um armazenamento de snapshots de armazenamento compatível com o AWS S3 ou em um armazenamento de blocos autônomo do MongoDB.
Um blockstore standalone do MongoDB oferece resiliência limitada. Se o disco ficar cheio, esse blockstore poderá ficar offline. Você pode recuperar snapshots de backup somente depois de adicionar armazenamento.
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
Recomendamos que você revise a quantidade de dados que está fazendo backup no blockstore. Se a quantidade de dados do backup afetar negativamente o desempenho do blockstore ou se você não puder atender aos requisitos de RTO com um único blockstore, distribua a carga de trabalho entre vários blockstores para equilibrar as operações de backup. Você pode até configurar um único blockstore por shard para atender às suas necessidades de dimensionamento.
Você pode criar blockstores adicionais a qualquer momento e configurar suas tarefas de backup para usar os blockstores manualmente:
Para saber mais sobre a alocação de blockstores específicos para um projeto, consulte Gerenciar recursos de backup.
Para saber mais sobre como configurar backups de shard para usar blockstores específicos, consulte Manutenção manual de blockstore.
Essas recomendações de tamanho são uma prática recomendada. Elas não são uma limitação do banco de dados MongoDB ou do Ops 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 Ops 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.
| [2] | Esses valores de taxa de transferência foram calculados usando métodos padrão do setor para medir a 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 Ops Manager tira um snapshot básico de seus dados a cada 24 horas.
Se desejar, os administradores podem alterar a frequência dos snapshots de base para 6, 8, 12 ou 24 horas. MongoDB Ops Manager cria snapshots automaticamente em um cronograma. Você também pode tirar snapshots sob demanda.
O Ops Manager retém snapshots durante os períodos de tempo listados na tabela a seguir.
Se você encerrar o backup de um sistema, o Ops Manager excluirá imediatamente os snapshots que estão dentro das datas da política de retenção atual.
Se você interromper o backup de um sistema, o Ops 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 | 0 dias | 1 ano |
Snapshot semanal | 2 semanas | 1 ano |
Snapshot mensal | 1 mês | 7 anos |
Observação
Os snapshots mensais são snapshots completos por padrão, não snapshots incrementais.
O Ops Manager sempre preserva pelo menos um snapshot restaurável para uma implantação com backup. Na prática, isso significa que, se uma série de tarefas de backup falhar e a janela de retenção configurada expirar todos os snapshots existentes, o Ops Manager adia a limpeza do snapshot bem-sucedido mais recente até que um novo backup bem-sucedido seja concluído.
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.
Alterar o horário de referência altera o horário do próximo snapshot agendado. Não é possível fazer com que o próximo snapshot agendado aconteça antes do próximo horário atual. O próximo tempo de snapshot atual é o tempo de referência atual mais o intervalo entre snapshots.
Para determinar a hora do próximo snapshot, compare a hora do próximo snapshot atual com a nova hora de referência:
Se o novo horário de referência for anterior ao horário atual do próximo snapshot, o próximo snapshot ainda ocorrerá após o horário atual do próximo snapshot. O snapshot ocorre no novo horário de referência mais o número de intervalos necessários para ultrapassar o horário atual do próximo snapshot. Se esse horário já tiver passado quando você fizer a alteração, o Ops Manager capturará o próximo snapshot na próxima ocorrência do novo horário de referência. Consulte as duas primeiras linhas da tabela a seguir para obter exemplos.
Se o novo tempo de referência for posterior ao próximo tempo de snapshot atual, o Ops Manager obtém o próximo snapshot na próxima ocorrência do novo tempo de referência. Consulte a terceira e quarta linhas da tabela a seguir para obter exemplos.
Hora da alteração | Tempo de referência atual | Intervalo entre snapshots | Hora atual do próximo snapshot | Novo horário de referência | Hora do próximo snapshot |
|---|---|---|---|---|---|
08:00 UTC | 12:00 UTC | 6 horas | 12:00 UTC | 10:00 UTC | 16:00 UTC hoje |
23:00 UTC | 12:00 UTC | 6 horas | 00:00 UTC | 10:00 UTC | 04:00 UTC amanhã |
08:00 UTC | 12:00 UTC | 6 horas | 12:00 UTC | 19:00 UTC | 19:00 UTC hoje |
20:00 UTC | 12:00 UTC | 6 horas | 00:00 UTC | 19:00 UTC | 01:00 UTC amanhã |
Se você alterar o agendamento para salvar menos snapshots, o Ops Manager não excluirá os snapshots existentes para estar em conformidade com o novo agendamento. Para excluir snapshots desnecessários, consulte Excluir um snapshot.
Limites
O Ops Manager não faz backup de sistemas em que o número total de coleções no sistema seja igual ou superior a
100,000.O Ops Manager não replica as opções de collection de índice.
Criptografia
MongoDB Ops Manager pode criptografar qualquer tarefa de backup. Use cursores de backup em vez de bancos de dados principais para criptografar tarefas de backup. Para obter mais informações, consulte o Serviço Backup Daemon .
Considerações de backup
Consistência e snapshots
Ops Manager maintains causal consistency when taking snapshots except for size statistics reported by collStats and db.[collection].count(). Size statistics reported by collStats and db.[collection].count() may be inccurate. Ops Manager coordinates the time across all shards for sharded clusters. This ensures that snapshots include all documents written to every shard and node as of the scheduled snapshot time.
Importante
Sharded clusters and replica sets are the only deployment types you can back up if your databases run MongoDB FCV 4.2 and earlier. To back up a standalone mongod process running MongoDB FCV 4.2 or earlier, you must convert it to a single-member replica set.
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 [3] | ||
Pode especificar banco de dados de origem de sincronização | ||
Can Restore Data to Specific Point in Time [2] | ||
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 blockstore | ||
Permite salvar em armazenamento compatível com Armazenamento S3 de snapshots | ||
Supports Saving to File System Storage [7] | ||
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 |
| [7] | A filtragem de namespace é permitida somente nas versões 6.0.8 e posteriores do Ops Manager. Seus sistemas do MongoDB devem ter featureCompatibilityVersion valores de 4.0 e anteriores, ou 6.0.1 e posteriores. |
| [2] | A execução de uma restaurar do PIT exige o MongoDB Ops Manager 4.2.13 ou posterior. |
| [4] | O Ops 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. 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 banco de dados de origem de sincronização. Ao tirar um snapshot, o Ops 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 gerente de operações não gerenciar 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.
Sistema de arquivos compartilhados
Se você configurar o Ops Manager para utilizar vários servidores de aplicação do Ops Manager atrás de um balanceador de carga HTTP ou HTTPS e utilizar snapshots do sistema de arquivos, FCV 6.0 ou trabalhos de captura de imagem da cópia de segurança posterior executados em paralelo em um ou mais servidores. Certifique-se de ter um sistema de arquivos compartilhado montado em cada servidor Ops Manager. O servidor do aplicação de Ops Manager pode abrir e gravar diferentes offsets dos mesmos arquivos. Certifique-se de que o sistema de arquivos compartilhados permita isso. Caso contrário, você encontrará erros de acesso.
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:
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 Ops Manager criar um snapshot enquanto a tarefa de limpeza é executada. O Ops 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.
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.
Dica
Se você aplicar filtros de namespace a um snapshot, não será possível consultar esse snapshot.
Você cria uma Deny List dessas para excluir ou uma Access List delas para incluir. Você faz suas seleções ao iniciar um backup e pode editá-las posteriormente conforme necessário.
Use a deny list 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 coleções permitirá reduzir o tempo e os custos de backup. O uso de uma deny list geralmente é preferível ao uso de uma access list, 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 Ops Manager. Seus MongoDB deployments devem ter valores featureCompatibilityVersion 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 Ops Manager limita os backup para sistemas com menos de 100.000 arquivos. Os arquivos incluem collections e índices.
MongoDB 6.0 removes MMAPv1 storage. To learn more about storage engines, see Storage Engines in the MongoDB manual.
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, Ops Manager doesn't create the snapshot and displays a warning message.
Considerações de backup regionais
Para habilitar o backup regional , você deve associar pelo menos uma das seguintes opções à região de implantação que um conjunto de réplicas ou shard visa:
Além disso, você deve associar um de cada um dos seguintes itens a uma região de sistema:
sync store (unless you set
mms.backup.noSyncStatetotrue)
Se você adicionar um shard a um cluster fragmentado depois de habilitar o backup regional para esse cluster fragmentado, deverá atribuir uma região de sistema ao novo shard para continuar as tarefas de backup para os shards existentes. Até que você atribua uma região de implantação ao novo shard, toda a tarefa de backup do cluster fragmentado terá um estado Misconfigured e não gerará novos snapshots. Um cluster fragmentado com um estado Misconfigured continua a gerar entradas de oplog.