Orientações para Backups do Atlas

O MongoDB Atlas oferece backups totalmente gerenciados e personalizáveis para assegurar a retenção e recuperação de dados:

Backups em nuvem: esta função oferece suporte a snapshots de cópia completa e armazenamento de snapshots localizados usando as funcionalidades nativas de snapshot do seu provedor de nuvem. Esses snapshots são sempre incrementais por natureza para viabilizar restaurações rápidas e de baixo custo. Você escolhe uma política de backup que especifica a frequência e o período de retenção de snapshots, que pode ser por hora, dia, semana e ano.
Backups contínuos na nuvem: esta função adicional aprimora os backups padrão na nuvem, oferecendo recuperação point-in-time (PIT). Armazena snapshots junto com o oplog do cluster para capturar alterações de dados entre os snapshots, permitindo recuperar seus dados para o momento exato (um ponto no tempo) imediatamente antes de qualquer falha ou evento. Essa funcionalidade permite a criação de objetivos de ponto de recuperação (RPOs) com mínimo de 1 minuto.

Não recomendamos ativar o backup para ambientes de desenvolvimento e teste. Para ambientes de homologação e produção, recomendamos desenvolver modelos de implantação automatizados que incluam as recomendações de política de backup descritas nesta página.

Observação

O Modelo de responsabilidade compartilhada do MongoDB Atlas define os direitos complementares do MongoDB e de seus clientes em manter um ambiente de dados seguro e resiliente. Nesse framework, o MongoDB gerencia a segurança e a integridade operacional da plataforma subjacente, enquanto os clientes são responsáveis pelas políticas de configuração, gerenciamento e dados de suas implantações específicas. Para obter um detalhamento detalhado da propriedade em segurança e segurança operacional, consulte Modelo de responsabilidade compartilhada.

Recursos para backups do Atlas

O Atlas fornece backups totalmente gerenciados de seus dados, incluindo recuperação de dados pontual e snapshots consistentes em todos os clusters, incluindo clusters fragmentados. No Atlas, você pode escolher entre cinco frequências de snapshot, cada uma com seu próprio período de retenção: por hora, diariamente, semanalmente, mensalmente e anualmente.

backups em nuvem	Este recurso oferece armazenamento de backup localizado usando a funcionalidade nativa de snapshot do seu fornecedor de serviços de nuvem do cluster. Os benefícios incluem um cronograma padrão robusto de retenção de backup de 12 meses, total flexibilidade para personalizar os agendamentos de snapshot e retenção e a capacidade de definir diferentes frequências de snapshot (como por hora para recuperação e semanal ou mensal para retenção de longo prazo) para cumprir as regulamentações do setor. Você pode acessar seus dados de backup instantaneamente, o que é útil para auditoria, conformidade ou recuperação de dados.
Backups contínuos da nuvem	Este recurso pode ser habilitado em combinação com os backups em nuvem para fornecer recuperação point-in-time (PIT). Os backups em nuvem contínuos funcionam armazenando snapshots junto com o oplog do cluster até um período de restauração point-in-time (PITr) personalizável, permitindo restaurar o último snapshot e reproduzir todas as operações desde a criação do último snapshot. Isso permite recuperar seus dados no momento exato (um ponto no tempo) imediatamente antes de qualquer falha ou evento de perda de dados, como um ataque cibernético.
Distribuição de snapshots multirregionais	Esse recurso permite aumentar a resiliência ao distribuir cópias de snapshots de backup e oplogs por várias regiões geográficas, além da região primária padrão. Essa configuração atende aos requisitos de compliance de armazenamento de backups em diferentes localizações geográficas para garantir a recuperação de desastres em caso de interrupções regionais. Para saber mais, consulte Distribuição de snapshots.
Política de compliance de backup	Este recurso protege ainda mais os dados críticos da empresa, impedindo que todos os snapshots e oplogs armazenados no Atlas sejam modificados ou excluídos, o que garante conformidade total dos backups com a regra WORM (Write Once Read Many). Apenas um usuário designado e autorizado pode desativar essa proteção após concluir um processo de validação com o suporte do MongoDB. Há um período de espera obrigatório para desabilitar esse recurso para que um invasor não possa alterar a política de backup e exportar os dados. Para aprender mais,consulte Configurar uma Política de Compliance de Backup.

Recomendações para Backups do Atlas

Recomendações para a estratégia de backup

Alinhe sua estratégia de backup com objetivos específicos de Objetivos do Tempo de Recuperação (RPO) e Objetivos de Tempo de Recuperação (RTO) para atender aos requisitos de continuidade dos negócios, especialmente para aplicativos críticos em que um RPO próximo de zero e tempos de recuperação rápidos são cruciais. RPO define a quantidade máxima de perda de dados aceitável durante uma falha ou interrupção, enquanto RTO define o tempo máximo necessário para que seu cluster ou serviço se recupere. Você deve calcular seus padrões de RPO e RTO com base na criticidade de seu aplicativo. Por exemplo, dados de extrema importância normalmente exigem um RPO menor do que a análise de fluxo de cliques.

A natureza do cenário de desastre e o método de recuperação afetam o RPO e o RTO realizáveis. A arquitetura de alta disponibilidade padrão do MongoDB oferece suporte a failover automático para recuperação de interrupções temporárias do provedor de nuvem com RTO e RPO próximos a zero, dependendo do escopo da interrupção e do paradigma de implantação escolhido. Para saber mais sobre as configurações de implantação que suportam failover automático, consulte Orientação 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:

O RPO depende do intervalo de snapshots definido em sua política de backup. Quando os Backups Contínuos na Nuvem estão desabilitados, seu RPO corresponde diretamente ao tempo entre os snapshots. Se você fizer snapshots de backup a cada quatro horas, por exemplo, poderá perder até quatro horas de dados durante um evento de falha. Se você ativar os backups contínuos na nuvem, poderá realizar restaurações de PIT que garantem um RPO de apenas um minuto dentro da janela PITr personalizável.
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 menos 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.

Tipo de política	Nível	Backup contínuo da nuvem	Snapshot tirado	Snapshot retido
A cada hora	NVMe	Habilitado	A cada 12 horas	7 dias
A cada hora	não NVMe	Habilitado	A cada 6 horas	7 dias
Diariamente	Todos	Qualquer	Todos os dias	7 dias
Semanalmente	Todos	Qualquer	Todos os sábados	4 semanas
Por mês	Todos	Qualquer	Último dia do mês	12 meses
Anual	Todos	Qualquer	Todo 1º de dezembro	1 ano

Dica

Escolher a política de backup certa do Atlas

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 ponto no tempo (PIT), o que minimiza a perda de dados durante falhas. O Atlas pode fazer a recuperação rapidamente para o timestamp exato antes de um evento de falha, garantindo pelo menos um RPO de um minuto. 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 estar lento até que o aquecimento do disco do provedor de nuvem seja concluído após uma restauração. Se você tiver alguma flexibilidade 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.

Exemplos de Automação: Backups do Atlas

Os exemplos a seguir permitem operações de backup e restauração usando as ferramentas do Atlas para automação.

Esses exemplos se aplicam apenas a ambientes de preparo e produção onde o backup está habilitado para o cluster.

Execute o seguinte comando para tirar um snapshot de backup do cluster chamado myDemo e manter o snapshot por 7 dias:

atlas backups snapshots create myDemo --desc "my backup snapshot" --retention 7

Habilite a política de conformidade de backup para seu projeto com um usuário designado e autorizado (governance@example.org) que, sozinho, pode desativar essa proteção após concluir um processo de validação com o suporte do MongoDB.

atlas backups compliancePolicy enable \
  --projectId 67212db237c5766221eb6ad9 \
  --authorizedEmail governance@example.org \
  --authorizedUserFirstName john \
  --authorizedUserLastName doe

Execute o comando a seguir para criar uma política de compliance para snapshots de backup agendados que impõe o número de vezes que os snapshots devem ser tirados, definido como a cada 6 horas, e a duração da retenção dos snapshots, definido como 1 mês .

atlas backups compliancePolicy policies scheduled create \
  --projectId 67212db237c5766221eb6ad9 \
  --frequencyInterval 6 \
  --frequencyType hourly \
  --retentionValue 1 \
  --retentionUnit months

Os exemplos a seguir demonstram como configurar backups durante a implantação. Antes de criar recursos com o Terraform, você deve:

Crie sua organização pagadora e uma chave de API para a organização pagadora. Armazene sua chave de API como variáveis de ambiente ao executar o seguinte comando no terminal:
```
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
```
Instalar o Terraform.

Importante

Os exemplos a seguir usam o provedor Terraform do MongoDB Atlas versão 2.x (~> 2.2). Ao migrar para a versão 1.x do provedor, consulte o Guia de Upgrade 2.0.0 para alterações interruptivas e etapas de migração. Os exemplos usam o recurso mongodbatlas_advanced_cluster com sintaxe v2.x.

Arquivos comuns

Você deve criar os seguintes arquivos para cada exemplo. Coloque os arquivos de cada exemplo em seu próprio diretório. Altere os IDs e nomes para usar seus valores. Em seguida, execute os comandos para inicializar o Terraform, visualizar o plano do Terraform e aplicar as alterações.

variables.tf

variable "org_id" {
  description = "Atlas organization ID"
  type        = string
}
variable "project_name" {
  description = "Atlas project name"
  type        = string
}
variable "cluster_name" {
  description = "Atlas Cluster Name"
  type        = string
}
variable "point_in_time_utc_seconds" {
  description = "PIT in UTC"
  default     = 0
  type        = number
}

Configurar o agendamento de backup para o cluster

Use o seguinte para configurar um agendamento de backup para o cluster com a seguinte frequência e retenção de snapshot:

Por hora: a cada 12 horas, reter por 7 dias
Diariamente: uma vez por dia, reter por 7 dias
Semanal: Sábado, manter por 4 semanas
Mensal: último dia do mês, reter por 3 meses

main.tf

locals {
 atlas_clusters = {
    "cluster_1" = { name = "m10-aws-1e", region = "US_EAST_1" },
    "cluster_2" = { name = "m10-aws-2e", region = "US_EAST_2" },
  }
}
resource "mongodbatlas_project" "atlas-project" {
  org_id = var.org_id
  name   = var.project_name
}
resource "mongodbatlas_advanced_cluster" "automated_backup_test_cluster" {
  for_each     = local.atlas_clusters
  project_id   = mongodbatlas_project.atlas-project.id
 name         = each.value.name
  cluster_type = "REPLICASET"
 replication_specs = [
   {
      region_configs = [
        {
          electable_specs = {
            instance_size = "M10"
            node_count    = 3
          }
          analytics_specs = {
            instance_size = "M10"
            node_count    = 1
          }
          provider_name = "AWS"
          region_name   = each.value.region
          priority      = 7
        }
      ]
    }
  ]
  backup_enabled = true # enable cloud backup snapshots
  pit_enabled    = true
}
resource "mongodbatlas_cloud_backup_schedule" "test" {
  for_each                 = local.atlas_clusters
  project_id               = mongodbatlas_project.atlas-project.id
  cluster_name             = mongodbatlas_advanced_cluster.automated_backup_test_cluster[each.key].name
  reference_hour_of_day    = 3  # backup start hour in UTC
  reference_minute_of_hour = 45 # backup start minute in UTC
  restore_window_days      = 7  # Restore window for near-zero RPO
  copy_settings {
    cloud_provider = "AWS"
    frequencies = ["HOURLY",
      "DAILY",
      "WEEKLY",
      "MONTHLY",
      "YEARLY",
    "ON_DEMAND"]
    region_name        = "US_WEST_1"
    zone_id            = mongodbatlas_advanced_cluster.automated_backup_test_cluster[each.key].replication_specs.*.zone_id[0]
    should_copy_oplogs = true
  }
  policy_item_hourly {
    frequency_interval = 12 # backup every 12 hours, accepted values = 1, 2, 4, 6, 8, 12 -> every n hours
    retention_unit     = "days"
    retention_value    = 7  # retain for 7 days
  }
  policy_item_daily {
    frequency_interval = 1 # backup every day, accepted values = 1 -> every 1 day
    retention_unit     = "days"
   retention_value     = 7 # retain for 7 days
  }
  policy_item_weekly {
    frequency_interval = 7 # every Sunday, accepted values = 1 to 7 -> every 1=Monday,2=Tuesday,3=Wednesday,4=Thursday,5=Friday,6=Saturday,7=Sunday day of the week
    retention_unit     = "weeks"
    retention_value    = 4 # retain for 4 weeks
  }
  policy_item_monthly {
    frequency_interval = 28 # accepted values = 1 to 28 -> 1 to 28 every nth day of the month
    retention_unit  = "months"
    retention_value = 3 # retain for 3 months
  }
  depends_on = [
    mongodbatlas_advanced_cluster.automated_backup_test_cluster
  ]
}

Configure o backup e a restauração PIT para o cluster

Use o seguinte para configurar o snapshot de backup em nuvem e a tarefa de restauração de ponto no tempo (PIT).

main.tf

# Create a project
resource "mongodbatlas_project" "project_test" {
  name   = var.project_name
  org_id = var.org_id
}
# Create a cluster with 3 nodes
resource "mongodbatlas_advanced_cluster" "cluster_test" {
  project_id   = mongodbatlas_project.project_test.id
  name         = var.cluster_name
  cluster_type = "REPLICASET"
  backup_enabled         = true # enable cloud provider snapshots
  pit_enabled            = true
  retain_backups_enabled = true # keep the backup snapshopts once the cluster is deleted
  replication_specs = [
    {
      region_configs = [
        {
          priority      = 7
          provider_name = "AWS"
          region_name   = "US_EAST_1"
          electable_specs = {
            instance_size = "M10"
            node_count    = 3
          }
        }
      ]
    }
  ]
}
# Specify number of days to retain backup snapshots
resource "mongodbatlas_cloud_backup_snapshot" "test" {
  project_id        = mongodbatlas_advanced_cluster.cluster_test.project_id
  cluster_name      = mongodbatlas_advanced_cluster.cluster_test.name
  description       = "My description"
  retention_in_days = "1"
}
# Specify the snapshot ID to use to restore
resource "mongodbatlas_cloud_backup_snapshot_restore_job" "test" {
  count        = (var.point_in_time_utc_seconds == 0 ? 0 : 1)
  project_id   = mongodbatlas_cloud_backup_snapshot.test.project_id
  cluster_name = mongodbatlas_cloud_backup_snapshot.test.cluster_name
  snapshot_id  = mongodbatlas_cloud_backup_snapshot.test.id
  delivery_type_config {
    point_in_time             = true
    target_cluster_name       = mongodbatlas_advanced_cluster.cluster_test.name
    target_project_id         = mongodbatlas_advanced_cluster.cluster_test.project_id
    point_in_time_utc_seconds = var.point_in_time_utc_seconds
  }
}