Lv.2 초급MongoDB

2026.05.0325분 읽기Lv.2 초급

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

MongoDB 백업/복구 완벽 가이드 Part 2 — 파일시스템 스냅샷(LVM·EBS)·PBM·자동화 파이프라인

논리 백업만으로는 대용량 데이터베이스의 백업 시간·복원 시간·샤딩 일관성을 감당하기 어렵다. Part 2에서는 블록 레벨 물리 백업인 LVM·EBS 파일시스템 스냅샷을 WiredTiger 일관성 조건과 함께 설명하고, 샤딩 클러스터와 엄격한 PITR이 필요한 환경을 위한 Percona Backup for MongoDB(PBM)를 다룬다. 어떤 상황에 어떤 백업 방식을 고를지 판단 기준을 정리하고, 복원 검증과 알림까지 포함한 실전 자동화 파이프라인 구성 방법으로 마무리한다.

시리즈 구성

• Part 1 — RTO·RPO·Oplog부터 mongodump/mongorestore 실전까지
• Part 2 — 파일시스템 스냅샷(LVM·EBS)·PBM·자동화 파이프라인 (현재 편)
• Part 3 — MongoDB Atlas 클라우드 백업, Point-in-Time Recovery(PITR), 재해복구 체크리스트 (연재 예정)

목차

1. 들어가며 — Part 1 한계에서 자연스럽게 출발한다
2. 파일시스템 스냅샷이란?
3. WiredTiger와 스냅샷 일관성
4. LVM 스냅샷으로 MongoDB 백업하기
5. AWS EBS 스냅샷 백업 전략
6. Percona Backup for MongoDB(PBM) 완전 정복
7. PBM 설치 및 설정
8. PBM 백업·복원 실전 명령어
9. 백업 방식 비교 — 상황별 선택 가이드
10. 자동화 파이프라인: 백업 실행에서 검증·알림까지
11. 마치며 — Part 3 예고

1. 들어가며 — Part 1 한계에서 자연스럽게 출발한다

Part 1에서 mongodump는 이식성이 좋고 설정이 단순해 소규모 데이터베이스에 적합하다고 설명했습니다. 하지만 다음 상황에서는 논리 백업만으로 충분하지 않습니다.

• 수백 GB 이상의 데이터베이스에서 백업 시간이 너무 길다
• 복원 시 인덱스 재구성에 추가 시간이 소요된다
• 샤딩 클러스터에서 일관된 백업을 보장하기 어렵다
• RPO가 매우 짧아 PITR이 실질적으로 필요하다

이런 상황에서 다음 단계는 두 방향입니다. 하나는 블록 레벨 물리 백업인 파일시스템 스냅샷(LVM/EBS), 다른 하나는 분산 백업 도구인 **Percona Backup for MongoDB(PBM)**입니다.

2. 파일시스템 스냅샷이란?

파일시스템 스냅샷은 블록 레벨에서 디스크 이미지를 순간적으로 복사하는 물리 백업 방식입니다. mongodump가 MongoDB와 직접 통신하며 데이터를 하나씩 읽어내는 것과 달리, 스냅샷은 운영체제나 클라우드 인프라의 스토리지 레이어에서 동작합니다.

핵심 동작 원리는 Copy-on-Write(CoW) 전략입니다. 스냅샷 생성 시점에 라이브 데이터와 스냅샷 볼륨 사이에 포인터를 만들어두고, 이후 실제 데이터가 변경될 때만 변경된 블록을 스냅샷 볼륨에 복사합니다. 덕분에 스냅샷 생성 자체는 매우 빠르고 초기 용량 부담도 적습니다.

스냅샷 백업의 주요 장점:

• 수백 GB 이상의 대용량 데이터베이스도 수 초 안에 스냅샷 생성
• MongoDB 인스턴스에 직접적인 CPU/메모리 부하를 거의 주지 않음
• 블록 단위 복사이므로 인덱스까지 그대로 보존 — 복원 후 재구성 불필요
• 클라우드 환경(AWS, GCP, Azure)에서 인프라 수준으로 자동화 가능

3. WiredTiger와 스냅샷 일관성

MongoDB의 기본 스토리지 엔진인 WiredTiger는 스냅샷 백업과 잘 어울립니다.

WiredTiger는 체크포인트(Checkpoint) 방식으로 데이터 내구성을 보장합니다. MongoDB는 WiredTiger가 60초 간격으로 체크포인트를 생성하도록 구성하며, 이 시점에 인메모리 데이터를 디스크에 일관되게 기록합니다. 저널링(Journaling)이 활성화된 상태에서 파일시스템 스냅샷을 찍으면, 두 체크포인트 사이의 중간 상태에서 스냅샷이 생성되더라도 WiredTiger가 재시작 시 저널을 자동으로 재생(replay)하여 일관된 상태로 복구합니다.

단, 반드시 지켜야 할 규칙이 있습니다.

핵심 주의사항: 데이터 디렉터리(/data/db)와 저널 디렉터리가 별도 볼륨에 있거나 저널링을 사용하지 않는다면, db.fsyncLock()으로 쓰기를 잠근 뒤 관련 볼륨을 같은 백업 절차에서 함께 캡처해야 합니다. 데이터만 따로, 저널만 따로 스냅샷을 찍으면 복구 보장이 깨집니다.

db.fsyncLock() — 언제 필요한가?

WiredTiger 환경에서 LVM 스냅샷을 사용할 때는 일반적으로 db.fsyncLock()이 필수가 아닙니다. 저널링이 활성화된 경우 WiredTiger의 스냅샷 메커니즘이 일관성을 처리합니다.

다만, 저널과 데이터 파일이 서로 다른 볼륨에 위치하거나 저널링이 꺼져 있거나 스냅샷 도구가 원자적(atomic) 일관성을 보장하지 않는 경우에는 db.fsyncLock()으로 쓰기를 잠근 뒤 스냅샷을 찍고 즉시 db.fsyncUnlock()으로 해제해야 합니다.

// mongosh에서 실행
// 1. 쓰기 잠금 및 모든 데이터 디스크 플러시
db.adminCommand({ fsync: 1, lock: true })

// → 이 시점에 스냅샷 생성 (외부 도구로 실행)

// 2. 즉시 잠금 해제
db.adminCommand({ fsyncUnlock: 1 })

4. LVM 스냅샷으로 MongoDB 백업하기

LVM(Logical Volume Manager)은 Linux 온프레미스 환경에서 가장 널리 쓰이는 스냅샷 백업 방법입니다.

4.1 사전 준비

MongoDB 데이터 파일이 LVM 볼륨 위에서 실행 중이어야 합니다.

# 볼륨 그룹 확인
sudo vgdisplay

# 논리 볼륨 확인
sudo lvdisplay

# MongoDB 데이터 경로 확인 (예: /dev/vg0/mongodb → /data/mongodb)
df -h /data/mongodb

4.2 LVM 스냅샷 생성 (백업)

#!/bin/bash
# LVM 스냅샷 MongoDB 백업 스크립트

set -euo pipefail

VG_NAME="vg0"
LV_NAME="mongodb"
SNAP_NAME="mdb-snap-$(date +%Y%m%d)"
SNAP_SIZE="20G"
BACKUP_DIR="/backup/mongodb-snapshots"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p "$BACKUP_DIR"

echo "[$(date)] LVM 스냅샷 생성 시작..."

# 1. 스냅샷 생성 (보통 1초 이내)
sudo lvcreate \
  --size "$SNAP_SIZE" \
  --snapshot \
  --name "$SNAP_NAME" \
  /dev/$VG_NAME/$LV_NAME

echo "[$(date)] 스냅샷 생성 완료: /dev/$VG_NAME/$SNAP_NAME"

# 2. 읽기 전용으로 마운트
sudo mkdir -p /mnt/mongodb-snapshot
sudo mount -o ro /dev/$VG_NAME/$SNAP_NAME /mnt/mongodb-snapshot

# 3. 압축 아카이브로 저장
sudo tar -czf "$BACKUP_DIR/$DATE.tar.gz" \
  -C /mnt/mongodb-snapshot .

echo "[$(date)] 아카이브 생성 완료: $BACKUP_DIR/$DATE.tar.gz"

# 4. 스냅샷 마운트 해제 및 삭제
sudo umount /mnt/mongodb-snapshot
sudo lvremove -f /dev/$VG_NAME/$SNAP_NAME

echo "[$(date)] LVM 스냅샷 백업 완료"

4.3 LVM 스냅샷에서 복원

#!/bin/bash
BACKUP_ARCHIVE="/backup/mongodb-snapshots/20260413_020000.tar.gz"
RESTORE_LV="mdb-new"
VG_NAME="vg0"
RESTORE_SIZE="100G"

# 1. 복원용 새 논리 볼륨 생성
sudo lvcreate --size $RESTORE_SIZE --name $RESTORE_LV $VG_NAME

# 2. 백업 아카이브를 새 볼륨에 복원
sudo gzip -d -c "$BACKUP_ARCHIVE" | sudo dd of=/dev/$VG_NAME/$RESTORE_LV

# 3. 마운트
sudo mount /dev/$VG_NAME/$RESTORE_LV /srv/mongodb

# 4. 잠금 파일 제거 (중요)
sudo rm -f /srv/mongodb/mongod.lock
# 5. mongod 복원 데이터 경로로 재시작
sudo mongod --dbpath /srv/mongodb --repair
sudo mongod --dbpath /srv/mongodb

echo "복원 완료"

주의: 스냅샷에는 오래된 mongod.lock 파일이 남아 있을 수 있습니다. db.fsyncLock()을 사용했다면 복원 전 이 파일을 제거하고, 그 외 WiredTiger 관련 파일은 임의 삭제하지 말고 시작 로그와 공식 복구 절차를 기준으로 판단합니다.

5. AWS EBS 스냅샷 백업 전략

클라우드 환경에서 MongoDB를 운영 중이라면 AWS EBS 스냅샷이 가장 간편한 물리 백업 수단입니다. EBS 스냅샷은 S3에 증분(incremental) 방식으로 저장되므로, 첫 번째 이후부터는 변경된 블록만 저장해 비용 효율이 높습니다.

RAID 구성 환경의 주의사항

EBS 볼륨 여러 개를 RAID로 묶은 환경이라면, 개별 EBS 스냅샷 도구만으로는 모든 디스크에 걸쳐 일관된 상태를 보장하기 어렵습니다. 이 경우 두 방법 중 하나를 선택해야 합니다.

1. LVM을 RAID 위에 구성: LVM 스냅샷으로 단일 작업에서 일관성 있는 스냅샷 생성
2. db.fsyncLock() 후 EBS 스냅샷: 쓰기를 잠근 상태에서 모든 볼륨을 동시에 스냅샷

AWS CLI를 활용한 EBS 스냅샷 자동화

#!/bin/bash
# AWS EBS 스냅샷 자동화 스크립트 (단일 볼륨 환경)

INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
VOLUME_ID="vol-0123456789abcdef0"
DESCRIPTION="mongodb-backup-$(date +%Y%m%d-%H%M%S)"
REGION="ap-northeast-2"
RETENTION_DAYS=7

echo "[$(date)] EBS 스냅샷 생성 시작..."

SNAPSHOT_ID=$(aws ec2 create-snapshot \
  --region "$REGION" \
  --volume-id "$VOLUME_ID" \
  --description "$DESCRIPTION" \
  --tag-specifications "ResourceType=snapshot,Tags=[{Key=Name,Value=$DESCRIPTION},{Key=Retention,Value=$RETENTION_DAYS}]" \
  --query 'SnapshotId' \
  --output text)

echo "[$(date)] 스냅샷 생성 요청 완료: $SNAPSHOT_ID"

aws ec2 wait snapshot-completed \
  --region "$REGION" \
  --snapshot-ids "$SNAPSHOT_ID"

echo "[$(date)] 스냅샷 완료: $SNAPSHOT_ID"

# 보존 기간 초과 스냅샷 삭제
CUTOFF_DATE=$(date -d "$RETENTION_DAYS days ago" +%Y-%m-%dT%H:%M:%SZ)
OLD_SNAPSHOTS=$(aws ec2 describe-snapshots \
  --region "$REGION" \
  --filters "Name=tag:Retention,Values=$RETENTION_DAYS" \
  --query "Snapshots[?StartTime<'$CUTOFF_DATE'].SnapshotId" \
  --output text)

for snap in $OLD_SNAPSHOTS; do
  aws ec2 delete-snapshot --region "$REGION" --snapshot-id "$snap"
  echo "[$(date)] 오래된 스냅샷 삭제: $snap"
done

echo "[$(date)] EBS 스냅샷 백업 완료"

6. Percona Backup for MongoDB(PBM) 완전 정복

mongodump는 소규모 환경에, LVM/EBS 스냅샷은 대용량 단일 노드에 강점이 있습니다. 하지만 샤딩 클러스터에서 여러 샤드에 걸친 일관된 백업이 필요하다면 두 방법 모두 한계에 부딪힙니다.

이를 해결하는 것이 **Percona Backup for MongoDB(PBM)**입니다. PBM은 MongoDB 샤딩 클러스터와 레플리카 셋을 위한 오픈소스 분산 백업 솔루션으로, 엔터프라이즈급 기능을 무료로 제공합니다. MongoDB 공식 Atlas 백업과는 별개의 도구입니다.

클러스터 전체 일관성 보장

샤딩 클러스터에서 각 샤드의 백업은 서로 약간씩 다른 시간에 캡처될 수 있습니다. PBM은 Oplog의 멱등적 업데이트(idempotent updates)를 활용해 모든 샤드를 동일한 시점으로 "빠르게 감기(fast-forward)"하여 클러스터 전체 일관성을 달성합니다.

지원하는 백업 유형

스토리지 백엔드는 AWS S3, Azure Blob, Google Cloud Storage, MinIO(온프레미스 S3 호환)를 모두 지원합니다. 24시간 상시 Oplog를 캡처하여 베이스 스냅샷과 결합한 PITR도 제공합니다.

7. PBM 설치 및 설정

7.1 설치 (Ubuntu/Debian 기준)

# Percona 저장소 추가 및 PBM 설치
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
sudo percona-release enable pbm release
sudo apt-get update
sudo apt-get install -y percona-backup-mongodb

7.2 MongoDB에 PBM 전용 사용자 생성

// mongosh에서 실행
use admin
db.createUser({
  user: "pbmUser",
  pwd: "pbmSecurePassword",
  roles: [
    { role: "readWrite",       db: "admin" },
    { role: "backup",          db: "admin" },
    { role: "restore",         db: "admin" },
    { role: "clusterMonitor",  db: "admin" },
    { role: "readAnyDatabase", db: "admin" }
  ]
})

7.3 PBM 설정 파일 작성 (S3 스토리지 예시)

# /etc/pbm/pbm_config.yaml

storage:
  type: s3
  s3:
    region: ap-northeast-2
    bucket: my-mongodb-backups
    prefix: production-cluster
    credentials:
      access-key-id: YOUR_ACCESS_KEY
      secret-access-key: YOUR_SECRET_KEY
    serverSideEncryption:
      sseAlgorithm: aws:kms
      kmsKeyID: arn:aws:kms:ap-northeast-2:123456789:key/abcd-1234

pitr:
  enabled: true
  oplogSpanMin: 10    # 10분 간격으로 Oplog 슬라이스 저장

restore:
  batchSize: 500
  numInsertionWorkers: 10

# 설정 적용 및 확인
pbm config --file /etc/pbm/pbm_config.yaml
pbm config --list

7.4 pbm-agent 서비스 등록

레플리카 셋의 모든 노드에 pbm-agent가 실행되어야 합니다.

# 환경 변수 설정 (/etc/default/pbm-agent)
PBM_MONGODB_URI="mongodb://pbmUser:pbmSecurePassword@localhost:27017/?authSource=admin"

# 서비스 시작 및 상태 확인
sudo systemctl enable pbm-agent
sudo systemctl start pbm-agent
pbm status

8. PBM 백업·복원 실전 명령어

8.1 백업 실행

# 논리 백업
pbm backup

# 물리(Hot) 백업 - 대용량 DB에 권장
pbm backup --type physical

# 증분 물리 백업 (두 번째부터 변경분만)
pbm backup --type incremental

# 특정 네임스페이스만 선택적 백업
pbm backup --ns="myDatabase.users,myDatabase.orders"

# 백업 목록 확인
pbm list

8.2 백업 상태 확인

# 전체 클러스터 백업 상태
pbm status

# 백업 목록 상세 조회
pbm list --full

# 출력 예시:
# Snapshots:
#   2026-04-13T02:00:05Z [physical] <-- replset: rs0, rs1 | ok
#   2026-04-12T02:00:03Z [logical]  <-- replset: rs0, rs1 | ok
#
# PITR <on>:
#   2026-04-12T02:00:03Z - 2026-04-13T09:45:22Z

8.3 복원 실행

# 특정 백업 시점으로 전체 복원
pbm restore 2026-04-13T02:00:05Z

# PITR — 특정 시각으로 복원 (초 단위 정밀도)
# 예: 컬렉션이 실수로 삭제된 시각이 09:30:00이라면, 그 1분 전으로 복원
pbm restore --time="2026-04-13T09:29:00"

# 특정 네임스페이스만 선택적 복원
pbm restore 2026-04-13T02:00:05Z --ns="myDatabase.users"

# 복원 진행 상태 확인
pbm logs --event restore

8.4 자동화: cron 정기 백업 스케줄

# /etc/cron.d/pbm-backup

# 매일 새벽 2시 전체 물리 백업
0 2 * * * root pbm backup --type physical >> /var/log/pbm-backup.log 2>&1

# PITR은 pbm_config.yaml의 pitr.enabled: true로 상시 활성화 (별도 cron 불필요)

9. 백업 방식 비교 — 상황별 선택 가이드

"무엇이 최고인가"가 아니라 "어떤 상황인가"로 선택해야 합니다.

10. 자동화 파이프라인: 백업 실행에서 검증·알림까지

백업 전략의 핵심은 자동화입니다. 수동 절차는 사람의 실수와 누락에 취약하고, 백업 성공 로그만으로는 실제 복구 가능성을 보장할 수 없습니다.

10.1 PBM 기반 전체 파이프라인 흐름

10.2 백업 무결성 자동 검증 스크립트

격리된 테스트 인스턴스에 자동 복원 후 도큐먼트 수를 확인하는 스크립트입니다.

#!/bin/bash
# MongoDB 백업 무결성 자동 검증 스크립트 (주 1회 실행 권장)

set -euo pipefail

TEST_MONGO_URI="mongodb://admin:password@test-mongo:27017/?authSource=admin"
ALERT_EMAIL="ops-team@company.com"
LOG_FILE="/var/log/mongodb-backup-verify.log"

log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "===== 백업 무결성 검증 시작 ====="

# 1. 가장 최근 백업 ID 조회
LATEST_BACKUP=$(pbm list --json 2>/dev/null | \
  python3 -c "import json,sys; data=json.load(sys.stdin); print(data['snapshots'][0]['name'])")

log "검증 대상 백업: $LATEST_BACKUP"

# 2. 테스트 인스턴스에 복원
log "테스트 인스턴스에 복원 중..."
PBM_MONGODB_URI="$TEST_MONGO_URI" pbm restore "$LATEST_BACKUP" --wait

# 3. 주요 컬렉션 도큐먼트 수 확인
log "복원 결과 검증 중..."
DOC_COUNT=$(mongosh "$TEST_MONGO_URI" --quiet --eval \
  "db.getSiblingDB('myDatabase').users.countDocuments({})")

if [ "$DOC_COUNT" -gt 0 ]; then
  log "검증 성공: users 컬렉션 도큐먼트 수 = $DOC_COUNT"
else
  log "검증 실패: 도큐먼트 수 = 0"
  echo "MongoDB 백업 검증 실패: $LATEST_BACKUP" | \
    mail -s "[ALERT] MongoDB Backup Verify Failed" "$ALERT_EMAIL"
  exit 1
fi

log "===== 백업 무결성 검증 완료 ====="

10.3 Slack 알림 연동

#!/bin/bash
# PBM 백업 결과를 Slack Webhook으로 알림

SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
BACKUP_LOG=$(pbm logs --event backup --tail 20 2>&1)

if echo "$BACKUP_LOG" | grep -q "error"; then
  STATUS="FAILED"
  COLOR="danger"
else
  STATUS="SUCCESS"
  COLOR="good"
fi

curl -s -X POST "$SLACK_WEBHOOK" \
  -H 'Content-type: application/json' \
  -d "{
    \"attachments\": [{
      \"color\": \"$COLOR\",
      \"title\": \"MongoDB Backup: $STATUS\",
      \"text\": \"$(date '+%Y-%m-%d %H:%M:%S')\",
      \"footer\": \"MongoDB Backup Monitor\"
    }]
  }"

11. 마치며 — Part 3 예고

Part 2에서는 대용량 환경에서 빛을 발하는 **파일시스템 스냅샷(LVM/EBS)**과, 샤딩 클러스터의 일관성 문제를 해결하는 **Percona Backup for MongoDB(PBM)**를 다뤘습니다. 그리고 상황별 선택 기준과 함께, 복원 검증과 알림까지 포함한 자동화 파이프라인 구성 방법을 살펴봤습니다.

"자동화되지 않은 백업 절차는 언젠가 반드시 실패한다."

백업 실패는 예고 없이 찾아오고, 그때는 이미 늦습니다. 정기 실행뿐 아니라 복원 검증과 알림까지 파이프라인에 포함해야 진정한 백업 전략이라 할 수 있습니다.

Part 3에서는 모든 인프라 관리를 클라우드에 위임하는 MongoDB Atlas 클라우드 백업, 초 단위 정밀도의 Point-in-Time Recovery(PITR), 그리고 실제 장애 상황을 가정한 재해복구(DR) 체크리스트와 Runbook 작성법을 다룰 예정입니다.