Orientações para Backups do Atlas

Recomendações para a estratégia de backup

Você deve alinhar sua estratégia de backup com Recovery Point Objectives (RPO) e Recovery Time Objectives (RTO) específicos para atender aos requisitos de continuação dos negócios, especialmente para aplicativos críticos em que RPO próximo de zero e tempos de recuperação rápidos são cruciais. O RPO define a quantidade máxima de perda de dados aceitável durante uma falha ou interrupção, enquanto o RTO define o tempo máximo necessário para que seu cluster ou serviço se recupere. Você deve calcular seus padrões para RPO e RTO com base na criticidade do seu aplicação. Por exemplo, dados de função crítica normalmente exigem um RPO mais baixo do que a análise de fluxo de cliques.

A natureza do seu cenário de desastre e o seu método de recuperação afetam o RPO e o RTO alcançáveis. A arquitetura de alta disponibilidade padrão do MongoDB faz failover automático para recuperação de interrupções temporárias do provedor de nuvem com um RTO e RPO quase zero, dependendo da extensão da interrupção e do paradigma de implantação escolhido. Para saber mais sobre as configurações de implantação que aceitam failover automático, consulte Orientações para alta disponibilidade do Atlas.

Para cenários de desastres que exigem restauração a partir de backup, como um erro de código que corrompe todo o seu banco de dados ou uma exclusão acidental de cluster, o RTO e o RPO da sua implantação dependem do seguinte:

• RPO depends on the snapshot interval defined in your backup policy. When Continuous Cloud Backups is disabled, your RPO directly corresponds to the amount of time between snapshots. If you take backup snapshots every four hours, for example, then you can lose up to four hours of data during a failure event. If you enable Continuous Cloud Backups, then you can perform PIT restores that guarantee an RPO as low as one minute within your customizable PITr window.

• RTO depende do tamanho do seu backup e da eficiência da sua operação de restauração. Conjuntos de réplicas grandes (e fragmentos) demoram mais para serem restaurados. Para acelerar as restaurações, o Atlas executa automaticamente restaurações otimizadas de anexação direta para clusters que estão no mesmo projeto e nas regiões onde você armazena cópias de snapshot.

  Se não houver snapshot local disponível, ou se o cluster utilizar armazenamento NVMe em vez de armazenamento padrão Geral ou de Baixa CPU, o Atlas usará por padrão restaurações de streaming mais lentas.

  Além disso, se você ativar os backups em nuvem contínuos, o Atlas precisa reproduzir as operações após restaurar o último snapshot para concluir uma restauração de PIT. Quanto menor o tempo entre os snapshots, menos operações precisam ser reproduzidas. Portanto, você pode diminuir seu RTO ao priorizar restaurações otimizadas e exigir snapshots mais frequentes em sua política de backup.

Para garantir uma estratégia de backup abrangente, recomendamos a seguinte política de backup padrão como ponto de partida . Ajuste a política conforme as necessidades de retenção de dados e recuperação de desastres da sua empresa.

Recomendações para distribuição de backup

Para aumentar ainda mais a resiliência em uma implantação de região única, recomendamos configurar o Atlas para copiar snapshots da região primária para uma região de backup secundária, garantindo que ainda seja possível restaurar versões anteriores caso a região primária fique indisponível. Para saber mais, consulte Distribuição de snapshots.

Recomendações para a política de compliance de backup

Recomendamos impor a Política de Conformidade de Backup do Atlas para evitar modificações ou exclusões não autorizadas de backups, garantindo assim a proteção de dados e viabilizando uma recuperação de desastre robusta.

Recomendações para a recuperação de PIT

Os backups em nuvem contínuos permitem a recuperação precisa do point-in-time (PIT), o que minimiza a perda de dados durante falhas. O Atlas pode rapidamente recuperar para o point-in-time exato antes de um evento de falha, garantindo pelo menos um minuto de RPO. Isso ocorre porque o Atlas restaura o snapshot mais recente de antes do ponto no tempo desejado e, em seguida, reproduz as alterações do oplog para restaurar a esse ponto específico. Os tempos de recuperação podem variar devido ao aquecimento do disco do provedor de nuvem e à quantidade de dados do oplog que devem ser reproduzidos durante a recuperação. O desempenho do cluster pode ficar lento até que o aquecimento do disco do provedor de nuvem seja concluído após uma restauração. Se você puder ser flexível em seus requisitos de recuperação, recomendamos projetar modelos que identifiquem a melhor relação entre opções razoáveis de recuperação e custo.

Recomendações para Custos de Backup

Para otimizar os custos de backup do Atlas, você pode ajustar a frequência de backup e as políticas de retenção conforme a criticidade dos dados e reduzir despesas de armazenamento desnecessárias. Por exemplo, recomendamos desativar os backups em ambientes de desenvolvimento ou teste, como clusters em que a recuperação de dados não é crítica. Para ambientes superiores, recomendamos equilibrar os custos de transferência de dados entre regiões com os requisitos de alta disponibilidade ao distribuir snapshots de backup entre regiões.