Orientación para las copias de seguridad de Atlas

MongoDB Atlas proporciona copias de seguridad totalmente gestionadas y personalizables para garantizar la retención de datos y la recuperación:

Copias de seguridad en la nube: Admite snapshots de copia completa y almacenamiento de snapshots localizado utilizando las capacidades nativas de snapshots del proveedor de nube. Estas snapshots son siempre de naturaleza incremental para permitir restauraciones rápidas y de bajo costo. Eliges una política de copia de seguridad que especifique la frecuencia y el periodo de retención de snapshots por día, por semana, por mes y por año.
Copias de Seguridad Continuas en la Nube: Potencian las copias de seguridad estándar en la nube al ofrecer recuperación en punto en el tiempo (PIT). Esta funcionalidad aditiva almacena snapshots junto con el oplog del clúster para capturar los cambios de datos entre los snapshots, permitiéndote recuperar tus datos exactamente en el momento (un punto en el tiempo) justo antes de cualquier fallo o evento. Esto admite objetivos de punto de recuperación (RPO) de hasta 1 minuto.

No recomendamos habilitar copias de seguridad para los entornos de desarrollo y prueba. Para entornos de preparación y producción, recomendamos desarrollar plantillas de implementación automatizadas que incluyan las recomendaciones de políticas de copia de seguridad descritas en esta página.

Nota

El Modelo de Responsabilidad Compartida de MongoDB Atlas define los deberes complementarios de MongoDB y sus clientes en el mantenimiento de un entorno de datos seguro y resiliente. Bajo este marco, MongoDB gestiona la seguridad y la integridad operativa de la plataforma subyacente, mientras que los clientes son responsables de la configuración, gestión y políticas de datos de sus implementaciones específicas. Para obtener un desglose detallado de la propiedad en materia de seguridad y excelencia operativa, consulta Modelo de responsabilidad compartida.

Funcionalidades de las copias de seguridad de Atlas

Atlas proporciona copia de seguridad totalmente gestionada de tus datos, incluyendo recuperación en un punto de datos y snapshots coherentes y a nivel de clúster de todos los clústeres, incluidos los clústeres fragmentados. En Atlas, puede elegir entre cinco frecuencias de snapshots, cada una con un periodo de retención propio: cada hora, día, semana, mes y año.

copias de seguridad en la nube	Esta funcionalidad proporciona almacenamiento de copia de seguridad localizado mediante la funcionalidad de snapshot nativa del proveedor de servicios en la nube de tu clúster. Los beneficios incluyen un sólido cronograma de retención de copias de seguridad por defecto de 12 meses, plena flexibilidad para personalizar los snapshots y los cronogramas de retención, así como la capacidad de establecer diferentes frecuencias de snapshots (como cada hora para recuperación, semanal o mensual para retención a largo plazo) para cumplir con las regulaciones industriales. You can access your datos de copia de seguridad instantly, which is useful for auditing, cumplimiento, or data recovery purposes.
Copias de seguridad continuas en la nube	Esta funcionalidad se puede habilitar además de las copias de seguridad en la nube para proporcionar una recuperación en un punto en el tiempo (PIT). Las copias de seguridad en la nube continuas funcionan almacenando las snapshots junto con el oplog del clúster en una ventana de restauración a un punto específico del tiempo (PITr) personalizable, lo que te permite restaurar hasta la última snapshot y luego reproducir todas las operaciones desde que se tomó la snapshot. Esto te permite recuperar tus datos al momento exacto (un punto en el tiempo) justo antes de cualquier fallo o evento de pérdida de datos, como un ciberataque.
Distribución de snapshot multirregional	Esta funcionalidad te permite aumentar la resiliencia distribuyendo copias de snapshots de copia de seguridad y oplogs por regiones geográficas, además de la región primaria por defecto. Esta configuración cumple con los requisitos de cumplimiento para almacenar copias de seguridad en diferentes ubicaciones geográficas, lo que garantiza la recuperación ante desastres en caso de interrupciones del servicio regionales. Para obtener más información, consulta Distribución de snapshots.
Política de cumplimiento de copias de seguridad	Esta funcionalidad protege aún más los datos críticos del negocio al evitar que todas las instantáneas y registros de operaciones almacenados en Atlas sean modificados o borrados, garantizando que tus copias de seguridad cumplan totalmente con la normativa WORM (guardar una vez, leer muchas veces). Solo un usuario designado y autorizado puede desactivar esta protección después de completar un proceso de verificación con el soporte de MongoDB. Existe un período de enfriamiento obligatorio para desactivar esta funcionalidad, de modo que un atacante no pueda cambiar la política de copia de seguridad y exportar los datos. Para obtener más información, consulta Configurar una política de cumplimiento de copias de seguridad.

Recomendaciones para copias de seguridad de Atlas

Recomendaciones para la estrategia de copias de seguridad

Debe alinear su estrategia de copia de seguridad con Objetivos de Punto de Recuperación (RPO) específicos y Objetivos de Tiempo de Recuperación (RTO) para cumplir con los requisitos de continuidad del negocio, especialmente para aplicaciones críticas donde se requiera RPO y tiempos rápidos de recuperación son cruciales. RPO define la cantidad máxima de pérdida de datos aceptable durante una falla o interrupción, mientras que RTO define el tiempo máximo que toma para que tu clúster o servicio se recupere. Debe calcular sus estándares para RPO y RTO basándose en la criticidad de su aplicación. Por ejemplo, los datos críticos para la misión generalmente requieren un RPO más bajo que el análisis de clickstream.

La naturaleza de tu escenario de desastre y tu método de recuperación afectan tu RPO y RTO alcanzables. La arquitectura de alta disponibilidad por defecto en MongoDB admite la conmutación por error automática para recuperarse de interrupciones temporales del proveedor de nube con un RTO y RPO casi nulos, según el alcance de la interrupción del servicio y el paradigma de implementación elegido. Para aprender más sobre las configuraciones de implementación que admiten la conmutación por error automática, consulta Orientación para la alta disponibilidad en Atlas.

Para escenarios de desastre que requieran restauración desde una copia de seguridad, como un error de código que corrompe toda la base de datos o la eliminación accidental de un clúster, el RTO y RPO de su implementación dependen de lo siguiente:

RPO depende del intervalo de instantáneas definido en la política de copia de seguridad. Cuando las copias de seguridad en la nube están deshabilitadas, tu RPO corresponde directamente a la cantidad de tiempo entre los snapshots. Si haces copias de seguridad cada cuatro horas, por ejemplo, puedes perder hasta cuatro horas de datos durante un evento de fallo. Si habilita copias de seguridad continuas en la nube, puede realizar restauraciones de PIT que garanticen un RPO tan bajo como un minuto dentro de su ventana PITr personalizable.
RTO depende del tamaño de tu copia de seguridad y de la eficiencia de tu operación de restauración. Los sets de réplicas grandes (y las particiones) tardan más en restaurarse. Para acelerar las restauraciones, Atlas realiza automáticamente restauraciones optimizadas de adjunción directa para clústeres que están basados en el mismo Proyecto y regiones donde se almacenan copias de snapshots.
Si no hay ninguna snapshot local disponible o si el clúster utiliza almacenamiento NVMe en lugar de almacenamiento General o Low CPU, Atlas utiliza por defecto restauraciones de transmisión más lentas.
Además, si habilitas las copias de seguridad en la nube continuas, entonces Atlas debe volver a ejecutar las operaciones después de restaurar la última snapshot para completar una restauración PIT. Cuanto menos tiempo haya entre snapshots, menos operaciones se deberán reproducir. Por lo tanto, puedes reducir tu RTO priorizando restauraciones optimizadas y requiriendo snapshots más frecuentes en tu política de copias de seguridad.

Para garantizar una estrategia de copia de seguridad integral, recomendamos utilizar la siguiente política de copia de seguridad por defecto como punto de partida. Ajusta esta política según las necesidades de retención de datos y recuperación ante desastres de tu empresa.

Tipo de póliza	Nivel	Copia de seguridad continua en la cloud	Snapshot Tomado	snapshot retenida
Por hora	NVMe	Activado	Cada 12 horas	7 días
Por hora	non-NVMe	Activado	Cada 6 horas	7 días
Diario	Todo	Cualquiera de los dos	Cada día	7 días
Semanal	Todo	Cualquiera de los dos	Todos los sábados	4 semanas
Mensual	Todo	Cualquiera de los dos	Último día del mes	12 meses
Anual	Todo	Cualquiera de los dos	Cada 1 de diciembre	1 año

Tip

Elegir la política de copia de seguridad de Atlas adecuada

Recomendaciones para la distribución de la copia de seguridad

Para mejorar aún más la resiliencia en una implementación de una sola región, recomendamos configurar Atlas para que copie snapshots de la región principal a una región de copia de seguridad secundaria. De esta manera, podrá restaurar versiones anteriores incluso si la región principal deja de funcionar. Para obtener más información, consulta Distribución de snapshot.

Recomendaciones para la política de cumplimiento de copias de seguridad

Recomendamos hacer cumplir la Política de cumplimiento de copias de seguridad de Atlas para evitar modificaciones o eliminaciones no autorizadas de copias de seguridad, garantizando así la protección de datos y una recuperación ante desastres.

Recomendaciones para la recuperación por PIT

Las copias de seguridad continuas en la nube permiten una recuperación precisa en un punto específico (PIT), lo que minimiza la pérdida de datos en caso de fallo. Atlas puede recuperarse rápidamente a la marca de tiempo exacta antes de un evento de falla, garantizando un RPO de al menos un minuto. Esto se debe a que Atlas restaura la snapshot más reciente anterior al punto deseado y luego reproduce los cambios del oplog para restaurar hasta ese punto en particular. Los tiempos de recuperación pueden variar debido al calentamiento del disco del proveedor de nube y a la cantidad de cambios del oplog que deben reproducirse durante la recuperación. El rendimiento del clúster puede ser lento hasta que se complete el calentamiento del disco del proveedor de nube tras una restauración. Si se puede ser flexible en los requisitos de recuperación, recomendamos diseñar plantillas que identifiquen el mejor equilibrio entre opciones razonables de recuperación y costos.

Recomendaciones para los costos de copias de seguridad

Para optimizar los costos de copia de seguridad de Atlas, puedes ajustar la frecuencia de las copias de seguridad y las políticas de retención para alinearlas con la criticidad de los datos y reducir los gastos de almacenamiento innecesarios. Por ejemplo, recomendamos desactivar las copias de seguridad en entornos inferiores, como clústeres de desarrollo o de prueba donde la recuperación de datos no es crítica. Para los entornos superiores, recomendamos equilibrar los costos de transferencia de datos entre regiones con los requisitos de alta disponibilidad al distribuir snapshots de copia de seguridad entre regiones.

Ejemplo de automatización: copias de seguridad de Atlas

Los siguientes ejemplos habilitan operaciones de copia de seguridad y restauración mediante Atlas herramientas para automatización.

Estos ejemplos solo se aplican a entornos de staging y producción donde se ha habilitado copia de seguridad para el clúster.

Ejecuta el siguiente comando para tomar una snapshot de copia de seguridad del clúster denominado myDemo y conservar la snapshot durante 7 días:

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

Habilite la política de cumplimiento de copias de seguridad para su proyecto con un usuario autorizado designado (governance@example.org) quien solo puede desactivar esta protección después de completar un proceso de verificación con el soporte de MongoDB.

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

Ejecuta el siguiente comando para crear una política de cumplimiento para las instantáneas de copia de seguridad programadas que aplica el número de veces que se deben tomar las instantáneas, establecido en cada 6 horas, y la duración para retener las instantáneas, establecida en 1 meses.

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

Los siguientes ejemplos demuestran cómo configurar copias de seguridad durante la implementación. Antes de que puedas crear recursos con Terraform, debes:

Crea tu organización pagadora y crea una clave de API para la organización pagadora. Guarde su clave API como variables de entorno ejecutando el siguiente comando en el terminal:
```
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
```
Instala Terraform.

Importante

Los siguientes ejemplos utilizan MongoDB Atlas Terraform proveedor versión 2.x (~> 2.2). Si estás actualizando desde la versión 1.x del proveedor, consulta la 2.0.0 Guía de actualización para cambios disruptivos y pasos de migración. Los ejemplos utilizan el recurso mongodbatlas_advanced_cluster con la versión v2.x sintaxis.

Archivos comunes

Debes crear los siguientes archivos para cada ejemplo. Coloca los archivos de cada ejemplo en su propio directorio. Cambia los identificadores y los nombres para usar los valores correspondientes. Luego ejecuta los comandos para inicializar Terraform, ver el plan de Terraform y aplicar los cambios.

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 el cronograma de copias de seguridad del clúster

Utilice lo siguiente para configurar un cronograma de copia de seguridad para el clúster con la siguiente frecuencia de instantáneas y retención:

Por hora: cada 12 horas, se retiene durante 7 días
Diario: una vez al día, retener durante 7 días
Semanal: Sábado, retener durante 4 semanas
Mensual: último día del mes, conservar durante 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
  ]
}

Configura la copia de seguridad y la restauración PIT para el clúster

Utilice lo siguiente para configurar las copias de seguridad en la nube snapshot y la tarea de restauración de 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
  }
}