MongoDB 백업/복구 완벽 가이드 Part 1 — RTO·RPO·Oplog부터 mongodump/mongorestore 실전까지
MongoDB 백업은 도구 선택이 아니라 복구 목표 설계에서 시작한다. RTO(복구 목표 시간)와 RPO(허용 데이터 손실 시점)를 먼저 정해야 백업 빈도와 방식을 고를 수 있다. Part 1에서는 논리 백업 도구인 mongodump와 mongorestore의 핵심 옵션을 실전 예시로 다루고, 운영 환경에서 Secondary 대상 백업·권한 분리·체크섬 검증·보존 기간 관리를 어떻게 묶는지 설명한다. mongodump는 이식성이 좋은 논리 백업 도구지만 대용량 데이터베이스와 샤딩 클러스터에는 한계가 있으며, 이 한계선이 Part 2(파일시스템 스냅샷·PBM)와 Part 3(Atlas 클라우드 백업·PITR)로 이어지는 경계가 된다.
시리즈 구성
- Part 1 — RTO·RPO·Oplog부터 mongodump/mongorestore 실전까지 (현재 편)
- Part 2 — 파일시스템 스냅샷(LVM·EBS), Percona Backup for MongoDB(PBM), 자동화 파이프라인 (연재 예정)
- Part 3 — MongoDB Atlas 클라우드 백업, Point-in-Time Recovery(PITR), 재해복구 체크리스트 (연재 예정)
목차
- 들어가며 — 백업은 도구가 아니라 복구 목표에서 출발한다
- 핵심 개념: RTO · RPO · Oplog
- 백업 전략 유형 한눈에 보기
- mongodump 완전 정복
- mongorestore 완전 정복
- 실전 운영 루틴
- mongodump의 한계와 주의사항
- 마치며 — 복원 테스트와 Part 2 예고
1. 들어가며 — 백업은 도구가 아니라 복구 목표에서 출발한다
MongoDB 운영에서 백업을 이야기할 때 가장 흔한 실수는 "어떤 도구를 쓸까"부터 시작하는 것입니다.
올바른 시작점은 도구가 아니라 두 가지 질문입니다.
- 얼마나 빨리 복구해야 하는가? (RTO)
- 얼마나 잃어도 괜찮은가? (RPO)
이 두 질문에 답하지 않으면 백업 빈도도, 도구 선택도, 보존 기간도 제대로 설계할 수 없습니다.
그렇다면 왜 백업이 필요한가? 운영 환경에서 데이터 손실은 예상보다 다양한 경로로 발생합니다.
- 실수에 의한 삭제:
db.collection.drop()을 잘못된 환경에서 실행하는 경우 - 스키마 마이그레이션 오류: 대규모 문서를 손상시키는 데이터 변환 스크립트
- 랜섬웨어 및 인프라 공격: 오프라인 복사본 없이 데이터 접근이 불가능해지는 상황
- 하드웨어 장애: 레플리카 없이 단독 노드 장애
- 컴플라이언스 요건: GDPR, HIPAA, SOC 2 등 규정이 백업을 강제
백업이 없다면 단순한 기술적 장애가 규정 위반과 과태료 부과로 이어질 수 있습니다.
2. 핵심 개념: RTO · RPO · Oplog
백업 전략을 설계하기 전에 반드시 이해해야 할 세 가지 개념이 있습니다.
RTO (Recovery Time Objective) — 복구 목표 시간
장애 발생 후 서비스가 얼마나 빨리 재개되어야 하는가를 나타내는 지표입니다.
예를 들어 "RTO = 1시간"이면 장애 발생 후 1시간 내에 정상 운영으로 돌아와야 한다는 의미입니다.
RPO (Recovery Point Objective) — 복구 목표 시점
어느 시점의 데이터까지 잃어도 괜찮은가를 정의합니다.
"RPO = 6시간"이면 최대 6시간치 데이터 손실은 허용 가능하다는 의미입니다. RPO가 짧을수록 백업 빈도가 높아야 하고 비용도 증가합니다.
Oplog (Operation Log)
레플리카 셋의 모든 쓰기 작업을 순서대로 기록하는 특수 컬렉션입니다(local.oplog.rs).
Oplog는 MongoDB 복제의 핵심이지만 백업에서도 중요한 역할을 합니다. mongodump --oplog 옵션을 사용하면 백업 중 발생한 변경사항까지 캡처하여 덤프 결과가 하나의 일관된 시점에 더 가깝게 복원되도록 보정할 수 있습니다.
주의:
--oplog는 전체 인스턴스 백업에서만 사용할 수 있습니다.--db나--collection을 지정한 경우 이 옵션은 동작하지 않습니다.
3. 백업 전략 유형 한눈에 보기
MongoDB에서 사용할 수 있는 백업 방식은 크게 세 가지로 구분됩니다.
| 방식 | 도구 | 속도 | 일관성 | 추천 환경 |
|---|---|---|---|---|
| 논리 백업 | mongodump / mongorestore | 느림 | 보통 | 소규모-중규모 DB, 이식성 필요 |
| 파일시스템 스냅샷 | LVM, AWS EBS, ZFS | 빠름 | 높음 | 대규모 DB, 최소 다운타임 |
| 클라우드 관리형 백업 | MongoDB Atlas | 자동 | 매우 높음 | 클라우드 환경, PITR 필요 |
Part 1에서는 가장 기본이 되는 논리 백업(mongodump/mongorestore)을 집중적으로 다룹니다.
4. mongodump 완전 정복
mongodump는 MongoDB가 공식 제공하는 논리 백업 도구로, 데이터를 BSON 형식으로 내보내 파일로 저장합니다.
4.1 기본 명령어 구조
mongodump [옵션]
4.2 주요 사용 예시
전체 인스턴스 백업
mongodump \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--out=/backup/mongodb/$(date +%Y%m%d_%H%M%S)
특정 데이터베이스만 백업
mongodump \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--db=myDatabase \
--out=/backup/mongodb/
특정 컬렉션만 백업
mongodump \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--db=myDatabase \
--collection=users \
--out=/backup/mongodb/
gzip 압축 + 단일 아카이브 파일로 저장
mongodump \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--gzip \
--archive=/backup/mongodb/myDatabase_$(date +%Y%m%d).gz
Oplog 포함 전체 백업 (덤프 중 쓰기 보정용)
mongodump \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--oplog \
--gzip \
--out=/backup/mongodb/full_$(date +%Y%m%d_%H%M%S)
주의:
--oplog는 전체 인스턴스 백업(--db,--collection미지정)에서만 동작합니다. 특정 DB나 컬렉션을 지정하면 이 옵션은 사용할 수 없습니다.
4.3 레플리카 셋 환경 권장 설정
운영 환경에서는 항상 Secondary 노드를 대상으로 백업을 실행해야 합니다. Primary에서 백업을 돌리면 CPU, 메모리, 디스크 I/O를 대량 소비하여 서비스 성능에 직접 영향을 줍니다.
mongodump \
--uri="mongodb://secondary.example.com:27017/?readPreference=secondary&authSource=admin" \
--oplog \
--out=/backup/mongodb/
4.4 필요한 권한
mongodump를 실행하려면 백업 대상 데이터베이스에 대한 find 권한이 필요합니다. MongoDB 내장 역할인 backup 역할을 사용하면 모든 데이터베이스를 백업할 수 있습니다.
db.createUser({
user: "backupUser",
pwd: "securePassword",
roles: [{ role: "backup", db: "admin" }]
})
5. mongorestore 완전 정복
mongorestore는 mongodump로 생성한 BSON 덤프를 MongoDB 인스턴스로 복원하는 도구입니다.
5.1 기본 복원 명령어
전체 백업 복원
mongorestore \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--drop \
/backup/mongodb/20260413_120000/
--drop옵션은 복원 전 기존 컬렉션을 삭제합니다. 데이터 중복을 방지하기 위해 완전 덮어쓰기 시 사용합니다.
특정 데이터베이스만 복원
mongorestore \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--db=myDatabase \
--drop \
/backup/mongodb/20260413_120000/myDatabase/
특정 컬렉션만 복원
mongorestore \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--db=myDatabase \
--collection=users \
/backup/mongodb/20260413_120000/myDatabase/users.bson
gzip 아카이브 복원
mongorestore \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--gzip \
--archive=/backup/mongodb/myDatabase_20260413.gz \
--drop
Oplog 재생 포함 복원
mongorestore \
--uri="mongodb://admin:password@localhost:27017/?authSource=admin" \
--oplogReplay \
--drop \
/backup/mongodb/full_20260413_120000/
5.2 필요한 권한
mongorestore를 실행하려면 insert와 createCollection 권한이 필요합니다. MongoDB 내장 역할인 restore 역할을 사용하는 것이 권장됩니다.
db.createUser({
user: "restoreUser",
pwd: "securePassword",
roles: [{ role: "restore", db: "admin" }]
})
6. 실전 운영 루틴
명령어 예제에서 끝나는 백업은 절반만 구현한 것입니다. 실제 운영 루틴에는 Secondary 대상 백업, 체크섬 검증, 압축, 보존 기간 관리가 함께 묶여야 합니다.
6.1 자동화 백업 스크립트
#!/bin/bash
# MongoDB 자동 백업 스크립트 (운영 환경용)
set -euo pipefail
MONGO_URI="mongodb://backupUser:securePassword@secondary.example.com:27017/?readPreference=secondary&authSource=admin"
BACKUP_DIR="/backup/mongodb"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_PATH="$BACKUP_DIR/$DATE"
RETENTION_DAYS=7
LOG_FILE="/var/log/mongodb_backup.log"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}
log "===== MongoDB 백업 시작: $DATE ====="
mkdir -p "$BACKUP_PATH"
log "mongodump 실행 중..."
mongodump \
--uri="$MONGO_URI" \
--oplog \
--gzip \
--out="$BACKUP_PATH"
BACKUP_SIZE=$(du -sh "$BACKUP_PATH" | cut -f1)
if [ -d "$BACKUP_PATH" ] && [ "$(ls -A "$BACKUP_PATH")" ]; then
log "백업 성공. 크기: $BACKUP_SIZE"
else
log "ERROR: 백업 디렉터리가 비어 있음"
exit 1
fi
log "체크섬 계산 중..."
find "$BACKUP_PATH" -type f -exec md5sum {} \; > "$BACKUP_PATH/checksums.md5"
log "아카이브 압축 중..."
tar -czf "$BACKUP_DIR/$DATE.tar.gz" -C "$BACKUP_DIR" "$DATE"
rm -rf "$BACKUP_PATH"
# AWS S3 업로드 (선택)
# log "S3 업로드 중..."
# aws s3 cp "$BACKUP_DIR/$DATE.tar.gz" s3://my-mongodb-backups/
log "보존 기간 ${RETENTION_DAYS}일 초과 백업 삭제 중..."
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
log "===== 백업 완료 ====="
cron 등록 — 매일 새벽 2시 실행
0 2 * * * /opt/scripts/mongodb_backup.sh >> /var/log/mongodb_backup.log 2>&1
6.2 복원 절차 (체크섬 검증 포함)
#!/bin/bash
BACKUP_ARCHIVE="/backup/mongodb/20260413_020000.tar.gz"
RESTORE_DIR="/tmp/mongodb_restore"
MONGO_URI="mongodb://restoreUser:securePassword@localhost:27017/?authSource=admin"
mkdir -p "$RESTORE_DIR"
tar -xzf "$BACKUP_ARCHIVE" -C "$RESTORE_DIR"
# 체크섬 검증 — 복원 전 무결성 확인
cd "$RESTORE_DIR/20260413_020000"
md5sum -c checksums.md5
mongorestore \
--uri="$MONGO_URI" \
--oplogReplay \
--drop \
--gzip \
"$RESTORE_DIR/20260413_020000"
echo "복원 완료"
7. mongodump의 한계와 주의사항
mongodump는 강력하지만 모든 상황에 적합하지는 않습니다. 다음 한계를 반드시 숙지해야 합니다.
성능 영향
mongodump는 실행 중인 MongoDB 인스턴스와 직접 통신하므로 데이터베이스 성능에 영향을 줍니다. 특히 거의 사용되지 않는 데이터를 메모리로 읽어들이면서 자주 사용되는 데이터가 캐시에서 밀려날 수 있습니다.
Secondary에서 백업을 실행하면 이 영향을 줄일 수 있지만 완전히 제거하지는 못합니다.
인덱스 미포함
mongodump는 인덱스 데이터를 직접 백업하지 않습니다. 복원 시 모든 인덱스를 재구성해야 하므로, 대용량 데이터베이스에서는 복원 시간이 크게 늘어날 수 있습니다.
대규모 데이터베이스에 부적합
수백 GB 이상의 데이터베이스에서는 mongodump가 매우 느리고 시스템 부하가 큽니다. 이 경우 파일시스템 스냅샷(Part 2에서 다룸)이나 Atlas 클라우드 백업(Part 3에서 다룸)을 고려해야 합니다.
샤딩 클러스터 주의
샤딩 클러스터에서 mongodump를 사용할 때는 Balancer를 중지하고, cross-shard transaction과 컬렉션 생성·변경 같은 DDL 작업을 일시 중단해야 데이터 불일치 위험을 줄일 수 있습니다. 샤딩 환경에서는 PBM(Percona Backup for MongoDB)이 더 안정적인 선택입니다.
8. 마치며 — 복원 테스트와 Part 2 예고
Part 1에서는 MongoDB 백업의 필요성, 핵심 개념(RTO/RPO/Oplog), 그리고 가장 기본적인 도구인 mongodump와 mongorestore의 실전 사용법을 다뤘습니다.
"백업은 한 번도 복원 테스트를 하지 않았다면 백업이 아니다."
백업 성공 로그만으로 안심할 수 없습니다. 복원 절차, --drop, --oplogReplay, 체크섬 확인을 함께 점검하는 정기 복원 리허설을 운영 기준으로 세워야 합니다. 월 1회 이상 스테이징 환경에서 실제 복원을 수행하고 결과를 기록하는 것이 권장됩니다.
Part 2에서는 더 빠르고 안정적인 방법인 **파일시스템 스냅샷(LVM / AWS EBS)**과, 샤딩 클러스터에서도 강력한 일관성을 보장하는 Percona Backup for MongoDB(PBM), 그리고 완전 자동화된 백업 파이프라인 구성 방법을 다룰 예정입니다.