Docs Menu
Docs Home
/ /

Atlas 백업 지침

MongoDB Atlas는 데이터 보존 및 복구를 보장하기 위해 완전 관리형 및 맞춤화가 가능한 백업을 제공합니다.

  • 클라우드 백업: 클라우드 공급자의 네이티브 스냅샷 역량을 사용해 전체 복사본 스냅샷과 로컬화된 스냅샷 저장을 지원합니다. 이러한 스냅샷은 항상 증분 방식으로 실행되어 비용이 저렴하고 복원이 빠릅니다. 시간별, 일별, 주별, 월별, 연간 스냅샷의 빈도와 보존 기간을 지정하는 백업 정책을 선택할 수 있습니다.

  • 지속적인 클라우드 백업: 특정 시점(Point In Time, PIT) 복구를 제공하여 표준 클라우드 백업을 향상시킵니다. 이 추가 기능은 클러스터의 oplog와 함께 스냅샷을 저장하여 스냅샷 사이의 데이터 변경 사항을 캡처하고, 데이터를 장애 또는 이벤트 직전의 정확한 시점(특정 시점)으로 복구할 수 있게 합니다. 이 기능은 최소 1분의 복구 시점 목표(RPO)를 지원합니다.

개발 및 테스트 환경에서는 백업 활성화를 권장하지 않습니다. 스테이징 및 프로덕션 환경에서는 이 페이지에 설명된 백업 정책 권장사항을 포함하는 자동화된 배포서버 템플릿을 개발하는 것이 좋습니다.

Atlas는 특정 시점의 데이터 복구와 샤드 클러스터를 포함한 모든 클러스터의 일관적인 클러스터 전체 스냅샷을 포함하여 데이터의 완전 관리형 백업을 제공합니다. Atlas에서는 스냅샷 주기를 시간별, 일별, 주별, 월별, 연간 등 5가지 중에서 선택할 수 있으며, 각각 고유한 보존 기간을 지정할 수 있습니다.

클라우드 백업

이 기능은 클러스터의 클라우드 서비스 제공자의 네이티브 스냅샷 기능을 사용하여 로컬화된 백업 저장소를 제공합니다. 이점으로 12개월의 강력한 기본 백업 보존 일정과 스냅샷 및 보존 일정을 완전히 사용자 지정할 수 있는 유연성이 포함됩니다. 또한 다양한 스냅샷 빈도(예: 복구를 위한 시간별 스냅샷이나 장기 보존을 위한 주별 또는 월별 스냅샷)를 설정하여 산업 규정을 충족할 수 있는 기능을 갖추고 있습니다. 백업 데이터에 즉시 접근할 수 있으며 이는 감사, 컴플라이언스 또는 데이터 복구 목적에 유용합니다.

지속적인 클라우드 백업

이 기능을 클라우드 백업에 추가해 특정 시점(PIT) 복구를 활용할 수 있습니다. 지속적인 클라우드 백업은 스냅샷을 클러스터의 oplog와 함께 사용자 지정 가능한 특정 시점 복원(PITr) 창에 저장하여 마지막 스냅샷으로 복원하고 스냅샷을 찍은 이후의 모든 작업을 재생할 수 있도록 지원합니다. 덕분에 사이버 공격과 같은 장애나 데이터 손실 이벤트 직전의 정확한 시점(특정 시점)으로 데이터를 복구할 수 있습니다.

멀티 리전 스냅샷 배포

이 기능은 기본 리전 외에도 여러 지리적 리전에 백업 스냅샷과 oplog 사본을 분산하여 회복 탄력성을 높일 수 있습니다. 이 구성은 지역적 장애 발생 시 재해 복구를 보장하기 위해 백업을 여러 지리적 위치에 저장해야 하는 컴플라이언스 요구 사항을 충족합니다.

자세한 내용은 스냅샷 배포를 참조하세요.

백업 컴플라이언스 정책

이 기능을 통해 Atlas에 저장된 모든 스냅샷과 oplog가 수정되거나 삭제되는 것을 방지함으로써 비즈니스 핵심 데이터를 더욱 안전하게 보호할 수 있습니다. 이는 백업이 WORM(Write Once Read Many) 규정을 완전히 준수하도록 보장합니다. 지정된 권한이 있는 사용자만 MongoDB 지원팀과 인증 절차를 완료한 후 이 보호 기능을 해제할 수 있습니다. 공격자가 백업 정책을 변경하고 데이터를 내보낼 수 없도록 이 기능을 비활성화하려면 필수 쿨다운 기간이 적용됩니다.

자세히 알아보려면 백업 컴플라이언스 정책 구성을 참조하세요.

비즈니스 연속성 요구사항을 충족하기 위해 백업 전략을 특정 복구 시점 목표(RPO)와 복구 시간 목표(RTO)에 맞춰야 합니다. 이는 특히 거의 0에 가까운 RPO와 빠른 복구 시간이 중요한 핵심 애플리케이션에서 더욱 중요합니다. RPO는 장애나 중단 시 허용되는 최대 데이터 손실량을 정의하며, RTO는 클러스터나 서비스가 복구되는 데 걸리는 최대 시간을 정의합니다. RPORTO에 대한 기준은 애플리케이션의 중요도에 따라 계산해야 합니다. 예를 들어 미션 크리티컬 데이터에는 일반적으로 클릭스트림 분석보다 낮은 RPO가 필요합니다.

재해 시나리오의 성격과 복구 방법에 따라 달성 가능한 RPORTO가 달라질 수 있습니다. MongoDB의 기본값 고가용성 아키텍처는 일시적인 클라우드 공급자 장애로부터 자동 페일오버를 통해 복구를 지원하며, 장애의 범위와 선택한 배포서버 패러다임에 따라 거의 0에 가까운 RTORPO를 제공합니다. 자동 페일오버를 지원하는 배포서버 구성에 대한 자세한 내용은 Atlas 고가용성 지침을 참조하세요. 전체 데이터베이스를 손상시키는 코드 오류나 실수로 클러스터가 삭제되는 등, 백업에서 복원해야 하는 재해 시나리오의 경우에는 배포서버의 RTORPO가 다음에 따라 달라집니다.

  • RPO는 백업 정책에 정의된 스냅샷 간격에 따라 달라집니다. 지속적인 클라우드 백업이 비활성화되면 RPO는 스냅샷 사이의 시간에 직접적으로 대응합니다. 예를 들어, 4시간마다 백업 스냅샷을 생성하면 이벤트가 발생했을 때 최대 4시간 분량의 데이터를 잃을 수 있습니다. 지속적인 클라우드 백업을 활성화하면 사용자 지정 가능한 PITr 창에서 1분 정도의 낮은 RPO를 보장하는 PIT 복원을 수행할 수 있습니다.

  • RTO는 백업의 크기와 복원 작업의 효율성에 따라 달라집니다. 대규모 복제본 세트(및 샤드)는 복원하는 데 시간이 더 오래 걸립니다. 복원 속도를 높이기 위해 Atlas는 스냅샷 사본이 저장된 동일한 프로젝트와 리전에 속한 클러스터에 대해 자동으로 최적화된 직접 연결 복원을 수행합니다. 로컬 스냅샷이 없거나 클러스터가 표준 일반 또는 저성능 CPU 저장 대신 NVMe 스토리지를 사용하는 경우, Atlas는 기본적으로 더 느린 스트리밍 복원을 사용합니다. 또한 연속 클라우드 백업을 활성화하면 Atlas는 PIT 복원을 완료하기 위해 마지막 스냅샷으로 복원한 후 작업을 다시 실행해야 합니다. 스냅샷 간의 시간이 짧을수록 다시 실행해야 하는 작업이 줄어듭니다. 따라서 최적화된 복원을 우선시하고 백업 정책에서 더 자주 스냅샷을 수행하도록 요구하면 RTO를 낮출 수 있습니다.

포괄적인 백업 정책을 위해 아래의 기본 백업 정책을 권장합니다. 이 정책은 데이터 보존 및 재해 복구 요구 사항에 따라 조정해야 합니다.

정책 유형
계층
지속적인 클라우드 백업
스냅샷 생성
스냅샷 보존

시간별

NVMe

활성화됨

12시간마다

7일

시간별

NVMe

활성화됨

6시간마다

7일

매일

모두

다음 중 1가지:

매일

7일

매주

모두

다음 중 1가지:

매주 토요일

4주

월간

모두

다음 중 1가지:

매월 마지막 날

12개월

연간

모두

다음 중 1가지:

매년 12월 1일

1년

단일 리전 배포서버의 회복 탄력성을 더욱 강화하기 위해 Atlas가 기본 리전의 스냅샷을 보조 백업 리전으로 복사하도록 구성할 것을 권장합니다. 이를 통해 기본 리전이 중단되더라도 이전 버전으로 복원할 수 있습니다. 자세한 내용은 Atlas를 구성하여 스냅샷을 다른 리전에 자동으로 복사하는 방법을 참조하세요.

Atlas의 백업 컴플라이언스 정책을 적용하여 백업의 무단 수정이나 삭제를 방지하고 이를 통해 데이터 보호 및 강력한 재해 복구를 보장하는 것이 좋습니다.

연속 클라우드 백업은 정밀한 시점(PIT) 복원을 가능하게 하여 장애 발생 시 데이터 손실을 최소화합니다. Atlas는 장애 이벤트 전의 정확한 타임스탬프로 신속하게 복원할 수 있으며 최소 1분의 RPO를 보장합니다. 이는 Atlas가 원하는 시점 이전의 가장 최근 스냅샷을 복원한 후 oplog 변경 사항을 재적용하여 특정 시점으로 복원하기 때문입니다. 복구 시간은 클라우드 제공자의 디스크 워밍 및 복구 중 재적용해야 하는 oplog의 양에 따라 달라질 수 있습니다. 복원 후 클라우드 공급자의 디스크 워밍이 완료될 때까지 클러스터 성능이 저하될 수 있습니다. 복구 요구 사항에 조정이 가능한 경우 합리적인 복구 옵션과 비용 간의 최적의 절충점을 찾을 수 있는 템플릿을 설계할 것을 권장합니다.

Atlas 백업 비용을 최적화하기 위해, 데이터 중요도에 맞게 백업 주기와 보존 정책을 조정하여 불필요한 저장 비용을 줄일 수 있습니다. 예를 들어 데이터 복구가 중요하지 않은 개발 또는 테스트 클러스터와 같은 하위 환경에서는 백업을 비활성화하는 것이 좋습니다. 상위 환경에서는 여러 리전에 백업 스냅샷을 배포할 때 고가용성 요구 사항과 리전 간 데이터 전송 비용을 균형 있게 고려할 것을 권장합니다.

다음 예시는 Atlas 자동화 도구를 사용하여 백업 및 복원 작업을 활성화합니다.

이 예시는 클러스터 백업이 활성화된 스테이징 및 프로덕션 환경에만 적용됩니다.

다음 명령을 실행하여 myDemo라는 클러스터의 백업 스냅샷을 생성하고 스냅샷을 7일 동안 보관합니다.

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

프로젝트에 대한 백업 준수 정책을 활성화하고 지정된 권한 있는 사용자(governance@example.org)를 설정합니다. 이 사용자만이 MongoDB 지원팀과의 검증 과정을 완료한 후 보호 기능을 해제할 수 있습니다.

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

다음 명령을 실행하여 스냅샷을 생성해야 하는 횟수(6 시간마다 설정하다 )와 스냅샷 보존 기간(1 개월으로 설정하다 )을 시행하는 예약된 백업 스냅샷에 대한 컴플라이언스 정책을 생성합니다. .

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

다음 예시는 배포 중 백업을 구성하는 방법을 보여줍니다. Terraform으로 리소스를 생성하기 전에 다음을 수행해야 합니다.

각 예시 에 대해 다음 파일을 만들어야 합니다. 각 예시 에 대한 파일을 자체 디렉토리 에 배치합니다. 값을 사용하려면 ID와 이름을 변경합니다. 그런 다음 명령을 실행 Terraform을 초기화하고, Terraform 계획을 확인한 다음 변경 사항을 적용 .

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
}

다음 설정을 사용하여 아래와 같은 스냅샷 빈도 및 보존 기간으로 클러스터의 백업 일정을 구성하세요.

  • 시간별: 12시간마다, 7일 동안 보존

  • 매일: 하루에 한 번, 7일 동안 보존

  • 주별: 매주 토요일, 4주 동안 보존

  • 월별: 매월 마지막 날, 3개월 동안 보존

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

다음을 사용하여 클라우드 백업 스냅샷 및 PIT 복원 작업을 구성하세요.

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

돌아가기

복원력

이 페이지의 내용