Lv.2 초급MongoDB

2026.05.0428분 읽기Lv.2 초급

시리즈MongoDB 백업/복구 완벽 가이드 · 파트 3/3시리즈 허브 보기

MongoDB 백업/복구 완벽 가이드 Part 3 — Atlas 클라우드 백업·PITR·재해복구 플레이북

Part 1에서 mongodump, Part 2에서 LVM·EBS 스냅샷과 PBM을 다뤘다면, Part 3는 모든 운영 부담을 관리형으로 흡수하는 MongoDB Atlas 클라우드 백업을 다룬다. Oplog 기반 Point-in-Time Recovery(PITR)로 초 단위 복구 시점을 설계하고, Snapshot Distribution과 Backup Compliance Policy로 멀티 리전 DR과 불변 백업을 구성하는 방법을 설명한다. 컬렉션 실수 삭제부터 랜섬웨어 공격, 리전 전체 장애까지 시나리오별 대응 플레이북과 RPO/RTO 설계 원칙을 정리하고, 3부작을 닫는 최종 체크리스트와 환경별 백업 전략 선택 가이드를 제공한다.

시리즈 구성

• Part 1 — RTO·RPO·Oplog부터 mongodump/mongorestore 실전까지
• Part 2 — 파일시스템 스냅샷(LVM·EBS)·PBM·자동화 파이프라인
• Part 3 — Atlas 클라우드 백업·PITR·재해복구 플레이북 (현재 편)

목차

1. 왜 Atlas 백업인가? — 관리형 서비스의 가치
2. Atlas 백업 아키텍처 전체 구조
3. Cloud Backup 설정 — UI · API · Terraform
4. 스냅샷 보존 정책 설계 가이드
5. Point-in-Time Recovery(PITR) 완전 정복
6. 멀티 리전 스냅샷 배포(Snapshot Distribution)
7. Backup Compliance Policy — 삭제 불가 잠금
8. 재해복구(DR) 시나리오별 대응 플레이북
9. 3-2-1 백업 원칙과 MongoDB 적용법
10. 시리즈 최종 체크리스트 & 백업 전략 선택 가이드
11. 3부작 마치며

1. 왜 Atlas 백업인가? — 관리형 서비스의 가치

Part 1에서는 mongodump, Part 2에서는 LVM/EBS 스냅샷과 PBM을 다뤘습니다.

모두 검증된 도구이지만, 하나의 공통점이 있습니다. 직접 설치하고, 설정하고, 유지보수해야 한다는 것입니다.

MongoDB Atlas의 클라우드 백업은 이 운영 부담을 관리형으로 흡수합니다.

대부분의 조직에서 샤딩 클러스터의 신뢰할 수 있는 백업 자동화를 직접 구축하는 엔지니어링 비용은 Atlas 같은 관리형 서비스 비용을 훌쩍 넘어섭니다.

Atlas 클라우드 백업의 핵심 가치는 다음과 같습니다.

• 완전 자동화: 스케줄 설정만 하면 백업 생성·보존·삭제까지 모두 자동
• 증분 스냅샷: 클라우드 프로바이더의 네이티브 스냅샷 기능을 활용해 항상 증분 방식으로 비용 효율적
• 샤딩 클러스터 완전 지원: 모든 샤드에 걸친 클러스터 전체 일관성 스냅샷 자동 보장
• PITR: Oplog를 연속으로 캡처하여 1분 이하의 RPO 달성 가능
• 다중 클라우드 리전 배포: 클릭 한 번으로 DR 리전에 스냅샷 자동 복제
• M10+ 전용: 모든 전용 클러스터(M10 이상)에서 사용 가능, Free/Flex 클러스터는 미지원

2. Atlas 백업 아키텍처 전체 구조

Atlas 클라우드 백업의 내부 동작 흐름을 이해하면 정책 설계가 훨씬 명확해집니다.

스냅샷은 클라우드 프로바이더의 오브젝트 스토리지에 증분 방식으로 저장됩니다. Oplog Store가 연속 캡처한 Oplog와 결합하면 임의 시점 복구가 가능하며, Snapshot Distribution을 활성화하면 Primary Region의 스냅샷이 DR Region으로 자동 복제됩니다.

3. Cloud Backup 설정 — UI · API · Terraform

3.1 Atlas UI에서 활성화

1. Atlas 대시보드에서 클러스터 선택
2. Edit Configuration → Additional Settings 탭 이동
3. Turn on Cloud Backup 토글 → On
4. Continuous Cloud Backup 토글 → On (PITR 사용 시)
5. Save Changes 클릭

3.2 Atlas Admin API로 활성화

# Cloud Backup + PITR 동시 활성화
curl -X PATCH \
  "https://cloud.mongodb.com/api/atlas/v1.0/groups/{groupId}/clusters/{clusterName}" \
  --digest -u "{publicKey}:{privateKey}" \
  -H "Content-Type: application/json" \
  -d '{
    "providerBackupEnabled": true,
    "pitEnabled": true
  }'

# 백업 스케줄 정책 설정 (매 6시간 스냅샷, 7일 보존 + PITR 7일)
curl -X PUT \
  "https://cloud.mongodb.com/api/atlas/v1.0/groups/{groupId}/clusters/{clusterName}/backup/schedule" \
  --digest -u "{publicKey}:{privateKey}" \
  -H "Content-Type: application/json" \
  -d '{
    "referenceHourOfDay": 2,
    "referenceMinuteOfHour": 0,
    "restoreWindowDays": 7,
    "policies": [{
      "policyItems": [
        {
          "frequencyInterval": 6,
          "frequencyType": "hourly",
          "retentionUnit": "days",
          "retentionValue": 7
        },
        {
          "frequencyInterval": 1,
          "frequencyType": "daily",
          "retentionUnit": "days",
          "retentionValue": 14
        },
        {
          "frequencyInterval": 6,
          "frequencyType": "weekly",
          "retentionUnit": "weeks",
          "retentionValue": 4
        },
        {
          "frequencyInterval": 40,
          "frequencyType": "monthly",
          "retentionUnit": "months",
          "retentionValue": 12
        }
      ]
    }]
  }'

3.3 Terraform으로 IaC 관리

인프라를 코드로 관리하는 환경이라면 Terraform으로 백업 정책까지 버전 관리할 수 있습니다.

# main.tf

resource "mongodbatlas_cluster" "production" {
  project_id                  = var.atlas_project_id
  name                        = "prod-cluster"
  provider_name               = "AWS"
  provider_region_name        = "AP_SOUTHEAST_2"
  provider_instance_size_name = "M30"

  cloud_backup = true
  pit_enabled  = true
}

resource "mongodbatlas_cloud_backup_schedule" "production_schedule" {
  project_id   = var.atlas_project_id
  cluster_name = mongodbatlas_cluster.production.name

  reference_hour_of_day    = 2
  reference_minute_of_hour = 0
  restore_window_days      = 7

  policy_item_hourly {
    frequency_interval = 6
    retention_unit     = "days"
    retention_value    = 7
  }

  policy_item_daily {
    frequency_interval = 1
    retention_unit     = "days"
    retention_value    = 14
  }

  policy_item_weekly {
    frequency_interval = 6   # 토요일
    retention_unit     = "weeks"
    retention_value    = 4
  }

  policy_item_monthly {
    frequency_interval = 40  # 매월 마지막 날
    retention_unit     = "months"
    retention_value    = 12
  }
}

4. 스냅샷 보존 정책 설계 가이드

Atlas는 다섯 가지 주기(시간별 / 일별 / 주별 / 월별 / 연별)로 스냅샷 정책을 설정할 수 있으며, 각 주기마다 독립적인 보존 기간을 지정할 수 있습니다.

Atlas 기본 보존 정책 (권장 시작점)

비즈니스 중요도별 권장 정책

일반 운영 서비스 (e-커머스, SaaS 앱)

RPO 목표: 1시간 이하
- 시간별 스냅샷: 매 6시간, 7일 보존
- 일별 스냅샷: 14일 보존
- 주별 스냅샷: 4주 보존
- PITR: 7일 복구 창

금융·의료 서비스 (엄격한 컴플라이언스)

RPO 목표: 마지막 트랜잭션까지 (제로에 가깝게)
- 시간별 스냅샷: 매 2시간, 7일 보존
- 일별 스냅샷: 1개월 보존
- 월별 스냅샷: 12개월 보존 (Atlas 내 빠른 복구용)
- 월별 스냅샷 → S3 아카이브: 5년 장기 보존
- PITR: 2일 복구 창 (짧게 설정해 복구 속도 최적화)
- Backup Compliance Policy: 활성화 필수

개발·스테이징 환경

백업 비활성화 권장
(Atlas 공식 문서도 개발·테스트 환경 백업은 불필요하다고 명시)

5. Point-in-Time Recovery(PITR) 완전 정복

5.1 PITR의 동작 원리

Atlas PITR은 베이스 스냅샷 + Oplog 재생의 조합으로 작동합니다.

PITR 복구 창(Restore Window)이 짧을수록 Oplog 재생 시간도 줄어들어 실제 복구 시간(RTO)이 빨라집니다. 예를 들어 스냅샷 간격이 2시간이라면 최대 2시간치 Oplog만 재생하면 되므로 복구가 매우 빠릅니다.

5.2 실전 PITR 복구 절차 — UI 방식

시나리오: 2026년 4월 14일 오전 10시 26분, 개발자가 payments 컬렉션을 실수로 삭제했습니다. 10시 25분 55초 상태로 복구해야 합니다.

Step 1. Atlas UI에서 해당 클러스터 선택

Step 2. 왼쪽 사이드바 Backup 클릭

Step 3. Point in Time Restore 버튼 클릭

Step 4. 복구 방법 선택

복구 방법:
  ● Date & Time       → 분(minute) 단위 정밀도
  ○ Oplog Timestamp   → 초(second) 단위 정밀도  ← 더 정밀한 복구에 권장

Step 5. Oplog Timestamp 탭 선택 후 입력

Timestamp (seconds since epoch): 1744603555
Increment: 1

(2026-04-14T10:25:55 UTC = Unix timestamp 1744603555)

Step 6. 복구 대상 클러스터 선택 (기존 클러스터 덮어쓰기 또는 새 클러스터로 복구)

Step 7. Restore 클릭 → 완료까지 모니터링

5.3 Atlas Admin API로 PITR 복구 자동화

# Oplog Timestamp 기반 PITR 복구 (REST API)
curl -X POST \
  "https://cloud.mongodb.com/api/atlas/v1.0/groups/{groupId}/clusters/{clusterName}/backup/restoreJobs" \
  --digest -u "{publicKey}:{privateKey}" \
  -H "Content-Type: application/json" \
  -d '{
    "delivery": {
      "methodName": "AUTOMATED_RESTORE",
      "targetClusterName": "prod-recovery-cluster",
      "targetGroupId": "{targetGroupId}"
    },
    "oplogTs": 1744603555,
    "oplogInc": 1
  }'

# 복구 작업 상태 모니터링
RESTORE_JOB_ID="..."
curl -X GET \
  "https://cloud.mongodb.com/api/atlas/v1.0/groups/{groupId}/clusters/{clusterName}/backup/restoreJobs/$RESTORE_JOB_ID" \
  --digest -u "{publicKey}:{privateKey}"

5.4 PITR 설계 시 핵심 고려사항

복구 창과 스냅샷 간격의 관계

복구 창(restoreWindowDays)은 시간별 스냅샷 보존 기간보다 길게 설정할 수 없습니다. 예를 들어 시간별 스냅샷을 7일 보존하면 PITR 복구 창도 최대 7일로 제한됩니다.

PITR 비활성화 주의

Atlas에서 Continuous Cloud Backup을 비활성화하면 기존 Oplog 데이터가 즉시 삭제됩니다. Backup Compliance Policy가 활성화된 경우 MongoDB 지원팀의 검증 절차 없이 비활성화가 불가능합니다.

NVMe 스토리지 복구 시간

NVMe 기반 클러스터는 볼륨이 물리적으로 연결되어 있어 네트워크 가상 스토리지 방식보다 복구 시간이 더 걸릴 수 있습니다.

6. 멀티 리전 스냅샷 배포(Snapshot Distribution)

단일 리전 장애(클라우드 프로바이더의 리전 전체 다운)에 대비하려면 스냅샷을 다른 지리적 리전에 자동 복제해야 합니다.

6.1 Snapshot Distribution 활성화

Atlas UI 설정 경로:

Clusters → 클러스터 선택 → Backup Policy 탭 → Additional Backup Copies 섹션 → Copy to other regions 토글 On → 대상 리전 선택

주의: 같은 클라우드 프로바이더의 다른 리전만 선택 가능합니다. 예: AWS ap-northeast-2 → AWS ap-southeast-1

6.2 크로스 리전 정책 설정 예시

현재 Atlas는 어떤 스냅샷만 복제할지, 복제본의 보존 기간을 얼마로 할지 독립적으로 설정할 수 있습니다.

Primary Region (ap-northeast-2, 서울):
  - 매 6시간 스냅샷, 30일 보존 (운영 복구용)

DR Region (ap-southeast-1, 싱가포르):
  - 일별 스냅샷만 복제, 7일 보존 (비용 최적화)
  - Oplog 배포 활성화 → DR 리전에서도 PITR 가능

이 방식으로 DR 보장은 유지하면서 불필요한 스토리지 비용을 절감할 수 있습니다.

7. Backup Compliance Policy — 삭제 불가 잠금

랜섬웨어나 내부자 위협으로 인해 백업 자체가 삭제될 위험을 방지하려면 Backup Compliance Policy를 활성화해야 합니다.

이 정책이 활성화되면 다음이 불가능해집니다.

• 어떤 사용자도(조직 오너 포함) 스냅샷을 임의 삭제하거나 보존 기간 단축 불가
• 클러스터를 종료해도 기존 스냅샷은 설정된 보존 기간까지 유지
• Continuous Cloud Backup 비활성화는 MongoDB 지원팀 검증 절차 없이 불가

WORM(Write Once Read Many) 규정 준수: GDPR, HIPAA, SOC 2, PCI-DSS 등 컴플라이언스 요구사항이 있는 금융·의료·공공 서비스에 필수 기능입니다.

7.1 Atlas CLI로 Compliance Policy 설정

# Backup Compliance Policy 활성화
# 주의: 상세 정책 옵션은 --file <policy.json> 으로 별도 제공할 수 있음
atlas backups compliancePolicy setup \
  --projectId {projectId} \
  --authorizedEmail "security@company.com" \
  --authorizedUserFirstName "보안" \
  --authorizedUserLastName "담당자"

# PITR 필수 적용 설정
atlas backups compliancePolicy pointInTimeRestores enable \
  --projectId {projectId} \
  --restoreWindowDays 7

# 암호화 강제 설정 (Customer Key Management 필수화)
atlas backups compliancePolicy encryptionAtRest enable \
  --projectId {projectId}

8. 재해복구(DR) 시나리오별 대응 플레이북

재해 상황에서 매뉴얼을 처음 읽는 것은 이미 늦습니다. 아래 플레이북은 평시에 팀 전체가 숙지하고 정기적으로 모의 훈련해야 합니다.

시나리오 1 — 컬렉션 실수 삭제

발생 상황: 개발자가 프로덕션 환경에서 db.orders.drop()을 실행

[즉시 조치]
1. 애플리케이션의 해당 DB 쓰기 접근 차단 (추가 변경 방지)
2. 삭제 발생 시각 정확히 기록 (로그, APM 타임스탬프 확인)
3. Atlas UI → Backup → Point in Time Restore
4. Oplog Timestamp 방식으로 삭제 발생 1분 전 시각 입력
5. 스테이징 클러스터로 먼저 복구 → 데이터 검증
6. 검증 완료 후 프로덕션에 적용 또는 mongorestore로 해당 컬렉션만 이식
7. 근본 원인 분석 (접근 권한 재검토, 환경 변수 안전장치 추가)

시나리오 2 — 잘못된 마이그레이션 스크립트

발생 상황: 배포된 스키마 변환 스크립트가 대규모 도큐먼트를 손상시킴

[즉시 조치]
1. 진행 중인 마이그레이션 스크립트 즉시 중단
2. 손상 범위 파악 (어떤 컬렉션, 몇 개 도큐먼트)
3. 마이그레이션 시작 시각을 기준으로 PITR 복구 결정
4. Atlas → Backup → Point in Time Restore
   → 마이그레이션 시작 시각 기준 30초 전 Oplog Timestamp 입력
5. 신규 클러스터로 복구 후 데이터 무결성 검증
   db.runCommand({ validate: "affected_collection" })
6. Blue-Green 방식으로 트래픽 전환
7. 재발 방지: 스테이징 환경 마이그레이션 검증 프로세스 강화

시나리오 3 — 레플리카 셋 전체 장애

발생 상황: 리전 전체 장애로 클러스터의 모든 노드가 다운됨

[즉시 조치]
1. 클라우드 프로바이더 상태 페이지 확인 (리전 복구 예상 시간 파악)
2. 멀티 리전 스냅샷 배포가 설정되어 있는 경우:
   → DR 리전(예: 싱가포르)의 스냅샷으로 새 클러스터 즉시 생성
3. DNS 또는 로드밸런서를 DR 클러스터로 전환
4. 원본 리전 복구 후 데이터 동기화 절차 진행
5. 롤백 또는 원본 리전으로 재전환 결정

[사전 준비 사항]
- DR 클러스터 사전 생성 및 연결 문자열 환경변수 관리
- Snapshot Distribution: 반드시 DR 리전 활성화
- 분기마다 DR 복구 모의 훈련 실시

시나리오 4 — 랜섬웨어 공격

발생 상황: 공격자가 데이터를 암호화하고 백업 삭제를 시도함

[즉시 조치]
1. 영향받은 클러스터의 모든 API 키 즉시 무효화
2. Atlas 접근 권한 긴급 감사 및 의심 계정 차단
3. Backup Compliance Policy 활성화 확인
   → 정책이 활성화된 경우 공격자도 백업 삭제 불가
4. 가장 최근의 오염되지 않은 스냅샷 시점 파악
5. 완전히 격리된 새 프로젝트/조직에 복구
6. 복구된 클러스터의 데이터 무결성 전수 검사
7. 보안팀 및 법무팀 보고, 필요 시 규제기관 신고

9. 3-2-1 백업 원칙과 MongoDB 적용법

3-2-1 규칙은 백업 전략의 황금 원칙으로, MongoDB 환경에도 그대로 적용됩니다.

MongoDB Atlas 환경에서의 3-2-1 구현

자체 관리 환경이라면 mongodump 결과물을 별도 AWS 계정의 S3 버킷에 저장하는 방식으로 계정 분리를 달성할 수 있습니다. 주 계정이 침해되어도 별도 계정의 백업은 안전하게 유지됩니다.

10. 시리즈 최종 체크리스트 & 백업 전략 선택 가이드

MongoDB 백업 전략 감사 체크리스트

아래 항목에서 미충족 항목이 있다면, 실제 장애 발생 전에 반드시 보완해야 합니다.

기초 (어떤 환경에서든 필수)

• 백업이 자동화되어 있고 cron/스케줄이 정상 동작 중인가?
• 백업 대상 서버가 Secondary 노드인가? (Primary 부하 방지)
• 백업 파일에 타임스탬프가 포함되어 식별 가능한가?
• 백업 파일이 운영 DB와 다른 물리적/논리적 위치에 저장되는가?
• 백업 파일이 암호화되어 있는가?
• 백업 작업 실패 시 알림이 발송되는가?

복구 검증 (가장 많이 놓치는 항목)

• 최근 1개월 내에 실제 복구 테스트를 수행했는가?
• 컬렉션 단위의 부분 복구 절차를 문서화하고 테스트했는가?
• 복구 테스트에서 예상 RTO를 달성했는가?
• 복구 후 데이터 무결성 검증 쿼리가 준비되어 있는가?

운영 환경 심화

• PITR(Point-in-Time Recovery)이 활성화되어 있는가?
• 멀티 리전 스냅샷 배포가 설정되어 있는가?
• Backup Compliance Policy가 활성화되어 있는가? (컴플라이언스 환경)
• RPO/RTO 목표값이 문서화되어 팀 전체가 알고 있는가?
• 재해복구 Runbook이 최신 상태로 유지되고 있는가?
• 분기 1회 이상 DR 모의 훈련을 수행하고 있는가?

보안

• 백업 전용 사용자 계정이 최소 권한으로 설정되어 있는가?
• 백업 접근 API 키가 별도로 관리되고 있는가?
• 백업 버킷/스토리지에 불변(Immutable) 설정이 되어 있는가?

환경별 백업 전략 선택 가이드

11. 3부작 마치며

3개 파트에 걸쳐 MongoDB 백업/복구의 전체 스펙트럼을 다뤘습니다.

어떤 도구를 선택하든, 가장 중요한 원칙은 하나입니다.

"테스트되지 않은 백업은 백업이 아니다."

백업 파일이 존재한다는 것과, 그 백업으로 실제 복구할 수 있다는 것은 완전히 다른 이야기입니다. 복구 테스트를 월 1회 이상 정기적으로 수행하고, 결과를 Runbook에 기록하고, 팀 전체가 절차를 숙지해야 합니다.

재해는 예고 없이 찾아옵니다. 그때 가장 침착한 사람은 가장 많이 연습한 사람입니다.