Preparações de backup
Nesta página
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.
Aviso
O MongoDB Ops Manager não suporta mais a criação de snapshots de cluster a partir de sistemas de banco de dados que utilizamcriptografia de chave local do . Se você criptografar um sistema de banco de dados com criptografia de chave local, o snapshot falhará. Para criptografar snapshots, use criptografia baseada emKMIPcom 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 custos de armazenamento maiores 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, compactação ou eliminação de duplicação
Um sistema de arquivos em um ou mais dispositivos NAS
Um AWS S3 blockstore
Armazenamento de blocos do MongoDB em uma configuração altamente disponível
Blockstore do MongoDB em uma configuração standalone
Importante
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 | Armazenamento de blocos HA do MongoDB | Loja de blocos do MongoDB |
|---|---|---|---|---|---|
Tipos de Snapshot | Concluir [1] | Concluir [1] | Muitos | Muitos | Muitos |
Eliminação de duplicação de dados de backup | Se a SAN suportar | Não | Sim | Sim | Sim |
Compactação de dados de backup | Sim | Não | Sim | Sim | Sim |
Replicação de dados de backup | Se a SAN suportar | Não | Não | Sim | Não |
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 |
| [1] | (1, 2) Para executar um backup incremental em um File System Store, o MongoDB Agent fatia cada arquivo do storage engine no caminho especificado para backup em bloco(s) de dados e transfere apenas o(s) bloco(s) alterado(s) para MongoDB Ops Manager. O MongoDB 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. |
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 blockstore 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 o backup em um armazenamento de snapshots compatível com o 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, compactação ou deduplicação.
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
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 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.
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.
| [2] | 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 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. O Ops Manager cria snapshots automaticamente em um cronograma; não é possível 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 |
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.
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 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 .
Observação
O FCV FCV 4.2 e posterior utilizam cursores de backup em vez de head databases. Para obter mais informações, consulte o Serviço Backup Daemon.
Considerações de backup
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 edb.[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
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 [1] | ||
Pode especificar banco de dados de origem de sincronização | ||
Pode restaurar dados para um ponto específico no tempo [2] | ||
Pode executar backups incrementais [3] | ||
Compatível com instantâneos que usam a criptografia KMIP [4] | ||
Oferece suporte a snapshots que usam criptografia de chave local [5] | ||
Suporta o processo de salvar no armazenamento de snapshot do blockstore | ||
Permite salvar em armazenamento compatível com Armazenamento S3 de snapshots | ||
Permite salvar no armazenamento do sistema de arquivos [6] | ||
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 |
| [3] | 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. |
| [4] | A execução de uma restauração do PIT exige o Ops Manager 4.2.13 ou posterior. |
| [5] | 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. Os backups incrementais reduzem os custos de transferência e armazenamento de rede. Esse recurso funciona com:
|
| [6] | A query de um snapshot criptografado requer o MongoDB Enterprise 4.2.9 e posterior ou 4.4.0 e posterior. |
| [7] | FCV 4.2 e backups posteriores não oferecem suporte à criptografia de chave local. |
| [8] | 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 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.
É necessário implantar um MongoDB Agent em cada nó
mongodno cluster.
Observação
Se o gerente de operações não gerenciar 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.
Sistema de arquivos compartilhados
Se você configurar o MongoDB Ops Manager para usar vários servidores de aplicativos do MongoDB Ops Manager atrás de um balancer de carga HTTP ou HTTPS e usar snapshots do sistema de arquivos, FCV 4.2 ou tarefas de snapshot de backup posterior executadas em paralelo em um ou mais servidores. Certifique-se de ter um sistema de arquivos compartilhado montado em cada servidor MongoDB Ops Manager. O servidor do aplicativo MongoDB 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.
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 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, 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.
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
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 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
Importante
Você pode usar checkpoints em clusters que executam o MongoDB com feature compatibility version do 4.0 ou anterior. Os pontos de controle foram removidos das instâncias do MongoDB com FCV de 4.2 ou posterior.
Para clusters fragmentados, os checkpoints fornecem pontos de restauração adicionais entre snapshots. Com os pontos de controle habilitados, o Gerente de Operações 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.