Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/ /
Atlas 아키텍처 센터
/

Atlas 백업 지침

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

  • 클라우드 백업: cloud 제공자의 네이티브 스냅샷 기능을 사용하여 전체 사본 스냅샷과 현지화된 스냅샷 저장 지원합니다. 이러한 스냅샷은 저렴한 비용 과 빠른 복원을 위해 기본적으로 항상 증분식입니다. 시간별, 일별, 주별, 월별 및 연간 스냅샷의 빈도와 보존 기간을 지정하는 백업 정책을 선택합니다.

  • 연속 클라우드 백업: 특정 시점(PIT) 복구를 제공하여 표준 클라우드 백업 개선합니다. 이 추가 기능 스냅샷을 클러스터의 oplog 와 함께 저장하여 스냅샷 간의 데이터 변경 사항을 캡처하므로 장애나 이벤트 직전의 정확한 순간(특정 점 )으로 데이터를 복구할 수 있습니다. 이는 최소 1 분의 RPO(복구 시점 목표)를 지원합니다.

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

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

클라우드 백업

이 기능 클러스터의 cloud 서비스 제공자 의 네이티브 스냅샷 기능을 사용하여 현지화된 백업 저장 제공합니다. 12 개월의 강력한 기본값 백업 보존 예정 , 스냅샷 및 보존 일정을 사용자 지정할 수 있는 완전한 유연성, 업계 요구 사항에 맞게 다양한 스냅샷 빈도(예: 복구의 경우 시간별, 장기 보존의 경우 매주 또는 매월) 설정하다 수 있는 기능 이 있습니다. 규정. 백업 데이터에 즉시 액세스 할 수 있으므로 감사, 컴플라이언스 또는 데이터 복구 목적으로 유용합니다.

지속적인 클라우드 백업

이 기능 클라우드 백업 위에 활성화하여 특정 시점(PIT) 복구를 제공할 수 있습니다. 연속 클라우드 백업은 스냅샷을 클러스터의 oplog 와 함께 사용자 지정 가능한 특정 시점 복원(PITr) 창 까지 저장하는 방식으로 작동하며, 이를 통해 마지막 스냅샷 으로 복원 다음 스냅샷 생성 이후의 모든 작업을 재생할 수 있습니다. 이를 통해 장애 또는 데이터 손실 이벤트 (예: 사이버 공격) 직전의 정확한 순간(특정 점 )으로 데이터를 복구할 수 있습니다.

멀티 리전 스냅샷 배포

이 기능 사용하면 기본값 프라이머리 리전 외에도 여러 리전에 백업 스냅샷 및 oplog의 복사본을 배포하여 회복 탄력성 높일 수 있습니다. 이 구성은 리전 중단 시 재해 복구를 보장하기 위해 서로 다른 지리적 위치에 백업을 저장해야 하는 규정 컴플라이언스 요구 사항을 충족합니다.

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

백업 컴플라이언스 정책

이 기능 Atlas 에 저장된 모든 스냅샷과 oplog가 수정되거나 삭제되지 않도록 방지하여 비즈니스 크리티컬 데이터를 더욱 보호하고, 백업이 WORM(Write-Once Read Many)을 완전히 준수하도록 보장합니다. 지정된 권한이 있는 사용자만 MongoDB 지원 의 확인 프로세스 완료한 후에 이 보호 기능을 해제할 수 있습니다. 공격자가 백업 정책을 변경하고 데이터를 내보낼 수 없도록 이 기능 비활성화하는 필수 휴지 기간이 있습니다.

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

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

재해 시나리오의 특성과 복구 방법은 달성 가능한 RPORTO에 영향을 미칩니다. MongoDB의 기본값 고가용성 아키텍처는 중단의 범위와 선택한 배포서버 패러다임에 따라 RTORPO가 거의 0 으로 일시적인 cloud 제공자 중단을 복구할 수 있는 자동 페일오버 지원합니다. 자동 페일오버 지원 배포서버 구성에 대해 자세히 학습 Atlas 고가용성을 위한 지침을 참조하세요. 전체 데이터베이스 손상시키는 코드 오류나 실수로 클러스터 삭제하는 등 백업 에서 복원 해야 하는 재해 시나리오의 경우 배포의 RTORPO는 다음에 따라 달라집니다.

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

  • RTO는 백업 크기와 복원 작업의 효율성 에 따라 달라집니다. 대규모 복제본 세트(및 샤드)는 복원 데 시간이 더 오래 걸립니다.복원 속도를 높이기 위해 Atlas 스냅샷 복사본을 저장 동일한 프로젝트 및 리전에 기반을 둔 클러스터에 대해 최적화된 직접 연결 복원을 자동으로 수행합니다. 사용 가능한 로컬 스냅샷 없거나 클러스터 표준 일반 또는 저전력 CPU 저장 대신 NVMe 스토리지 사용하는 경우 Atlas 기본적으로 더 느린 스트리밍 복원을 사용합니다. 또한 연속 클라우드 백업을 활성화 경우 PIT 복원 완료하려면 Atlas 에서 마지막 스냅샷 으로 복원한 후 작업을 재생해야 합니다. 스냅샷 사이의 시간이 짧을수록 재생해야 하는 작업도 줄어듭니다. 따라서 최적화된 복원의 우선 순위를 지정하고 백업 정책에서 더 빈번한 스냅샷을 요구하여 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 변경 사항을 재생하여 해당 특정 점 으로 복원 때문입니다. 복구 시간은 cloud 제공자 디스크 워밍업 및 복구 중에 재생해야 하는 oplog 의 양으로 인해 달라질 수 있습니다. 복원 후 cloud 제공자 디스크 워밍업이 완료될 때까지 클러스터 성능이 저하될 수 있습니다. 복구 요구 사항을 유연하게 조정할 수 있다면 합리적인 복구 옵션과 비용 사이에서 최상의 절충안을 식별하는 템플릿을 설계하는 것이 좋습니다.

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

돌아가기

복원력

이 페이지의 내용