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.

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 seu cenário de desastre e o seu método de recuperação afetam o RPO e o RTO alcançáveis. A arquitetura padrão de alta disponibilidade do MongoDB suporta failover automático para recuperação de interrupções temporárias do provedor de nuvem com RTO e RPO quase zero, dependendo do escopo da interrupção e do paradigma de implantação escolhido. Para aprender mais sobre as configurações de implantação que suportam failover automático, consulte Orientações para alta disponibilidade no Atlas. Para cenários de desastres que exigem restauração a partir do 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 a RPO da sua implantação precisam do seguinte:

O RPO depende do intervalo de snapshot definido na sua política de backup. Quando os backups em nuvem contínuos estão desativados, seu RPO corresponde diretamente ao intervalo entre os snapshots. Se você fizer snapshots de backup a cada quatro horas, por exemplo, poderá perder até quatro horas de dados em caso de evento de falha. Se você habilitar os backups em nuvem contínuos, poderá realizar restaurações PIT que garantem um RPO mínimo de um minuto no seu período personalizável de PITr.
O RTO depende do tamanho do seu backup e da eficiência da operação de restauração. Conjuntos de réplicas grandes (e fragmentos) demoram mais para serem restaurados. Para acelerar as restaurações, o Atlas realiza 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 snapshots. Se não houver um snapshot local disponível, ou se o cluster utilizar armazenamento NVMe em vez do armazenamento padrão geral ou de baixa CPU, então o Atlas usa por padrão restaurações mais lentas por streaming. Além disso, se você habilitar os backups contínuos em nuvem, o Atlas deverá reproduzir as operações após restaurar o último snapshot a fim de concluir uma restauração PIT. Quanto menor o tempo entre os snapshots, menos operações precisam ser reproduzidas. Portanto, você pode reduzir seu RTO ao priorizar restaurações otimizadas e exigir snapshots mais frequentes na sua política de backup.

Para uma política de backup abrangente, recomendamos a política de backup padrão abaixo. 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 Configurar o Atlas para copiar automaticamente snapshots para outras regiões.

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 point-in-time desejado e, em seguida, reproduz as alterações do oplog para restaurar 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.

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.

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
  }
}

Voltar

Resiliência

Recuperação de desastres