DBAtlas · 데이터베이스 운영 아틀라스

MongoDB 백업 및 복원 (mongodump, mongorestore, snapshot)

MongoDB난이도: 중급소요 시간: 45–90분

설치된 MongoDB에 백업 체계를 구성하고, 백업에서 복구하는 방법을 시나리오별로 설명합니다. 백업: mongodump로 단일 collection, 데이터베이스 또는 deployment 전체 백업(--archive --gzip, replica set에서는 --oplog로 일관된 시점 확보, secondary에서 읽기), 자격 증명 파일, systemd timer/cron을 이용한 보존 기간 있는 예약 백업, 테스트 복원, 선택적 파일 시스템 snapshot. 복원: 복원 리허설, 전체 복원, 단일 데이터베이스/collection, 백업 + oplog를 이용한 특정 시점 복구, 다른 cluster로 클론, sharded cluster. 데이터가 수백 GB이거나 빠른 복구가 필요하거나 sharded cluster인 경우에는 mongodump 대신 snapshot 또는 엔터프라이즈 도구(PBM, Ops Manager)를 사용합니다. 선택 기준은 첫 단계에서 설명합니다.

구성: 백업 서버 또는 멤버 하나 + replica set / 단일 instance / sharded cluster (mongos)

시나리오

  • 백업 구성: mongodump, 예약 실행, 테스트 복원 — 백업 사용자, 자격 증명 파일, 수동 및 예약 mongodump, 이름을 바꿔 수행하는 테스트 복원, 선택적 snapshot 및 mongoexport. 처음 구성하는 경우 여기서 시작하십시오.
  • 백업을 실제로 복원할 수 있는가? (--dryRun 및 임시 instance에서 리허설) — 운영 데이터에 영향 없이 아카이브 무결성, 포함된 namespace와 oplog를 확인하고, 필요하면 임시 mongod에 전체 복원한 뒤 문서 수를 셉니다.
  • 백업에서 전체 데이터 복원 (전체 복원, --drop) — 데이터 대부분이 유실되거나 손상되어 deployment를 백업 시점으로 되돌립니다. 백업 이후의 쓰기는 유실되며, 복원하는 동안 애플리케이션이 중단됩니다.
  • 단일 데이터베이스 또는 collection 복구 (--nsInclude, 새 이름으로 또는 원래 위치에) — collection/데이터베이스 하나가 삭제되거나 손상되었고 나머지는 정상인 경우: 해당 namespace만 백업에서 가져오며, 다른 데이터는 건드리지 않고 애플리케이션도 계속 운영할 수 있습니다.
  • 특정 시점으로 복구: 백업 + oplog (실수로 drop, 잘못된 update/delete) — 잘못된 작업이 백업 이후에 발생했고 그 시점까지의 쓰기도 필요한 경우: 마지막 전체 백업을 복원한 뒤 운영 oplog를 잘못된 작업 직전까지 적용합니다(--oplogReplay --oplogLimit). replica set에만 해당합니다.
  • 다른 cluster / 서버에 백업 복원 (클론, 테스트 환경, 이전) — 원본 deployment는 건드리지 않습니다. 백업을 다른 replica set이나 instance에 복원합니다(테스트/리포팅용 복사본, 서버 이전, 버전 업그레이드). 사용자 이전은 선택 사항입니다.
  • Sharded cluster 복원: mongodump의 한계와 올바른 방법 — 백업한 구성이 sharded cluster인 경우: mongos를 통한 논리적 복원(shard key 재생성, balancer) 또는 조정된 snapshot으로 cluster 전체를 물리적으로 재구성합니다.

시작하기 전에

  • 백업 대상 서버가 지원되는 운영체제에서 동작하고, 시계가 NTP로 동기화되어 있으며 시간대가 올바릅니다(백업 파일 이름과 예약 실행은 로컬 시간 기준).
  • 이 서버에서 …의 이름을 해석할 수 있고 해당 포트에 접근할 수 있습니다.… replica set에서는 연결 문자열의 이름이 rs.conf()의 멤버 이름과 같아야 합니다. 드라이버는 그 이름으로 접속합니다.…
  • …는 데이터 디스크와 다른 디스크 또는 네트워크 공유에 있으며, 여유 공간이 압축 백업 크기(보통 데이터의 20–50%)에 보존 기간을 곱한 값 이상입니다. 같은 디스크에 있는 백업은 디스크를 잃으면 데이터와 함께 사라집니다.
  • 인증이 활성화되어 있고 … 사용자(root 또는 userAdminAnyDatabase + clusterAdmin 역할)와 비밀번호를 알고 있습니다. 백업 사용자는 이 사용자로 생성합니다.
  • oplog 창이 전체 백업 소요 시간보다 확실히 깁니다(최소 몇 시간). --oplog는 백업 중 생성된 oplog 항목을 수집하므로, 창이 백업 시간보다 짧으면 백업이 실패합니다.… 특정 시점 복구에서는 운영 oplog의 첫 항목이 사용할 전체 백업이 끝난 시점보다 앞서야 합니다. 그렇지 않으면 그 사이의 작업은 어디에도 남아 있지 않습니다.…
  • MongoDB repo(repo.mongodb.org)에 HTTPS로 접근할 수 있거나 사내 mirror가 정의되어 있습니다. 서버에 도구가 이미 설치되어 있으면 버전이 표시됩니다.
  • dbPath(…)가 … LV에 있고 volume group에 … 이상의 여유 공간이 있습니다. WiredTiger journal(…/journal)은 같은 LV에 있어야 하며, 다른 디스크로 옮겼다면 snapshot 전에 fsyncLock이 필수입니다.
  • root 또는 sudo 권한이 있습니다. 전체 복원을 할 경우 유지보수 시간과 애플리케이션 팀의 승인을 받았습니다.… 복원 전에 사고 내용(언제, 어떤 작업, 누가)을 기록했고, 애플리케이션 팀이 어떤 데이터가 복구되는지 알고 있습니다.…
  • 이 가이드의 "백업 구성" 시나리오로 백업이 구성되어 있습니다: 도구(mongorestore, mongosh)와 자격 증명 파일 …(…: backup + restore)가 이 서버에 있습니다. 없다면 먼저 백업 구성 시나리오의 처음 두 단계를 수행하십시오.
  • 복원 시 데이터와 index를 다시 씁니다. 대상 서버의 데이터 디스크에 복원할 데이터(비압축 기준)의 1.5배 이상 여유 공간이 있습니다.… replica set에서는 secondary도 복제를 통해 같은 쓰기를 받으므로, 복원하는 동안 oplog 창이 짧아집니다.…
  • …에 복원할 데이터의 비압축 크기(전체 백업 + oplog)만큼 여유 공간이 있습니다. 임시 mongod는 127.0.0.1의 … 포트에서만 수신하며, 이 포트는 비어 있어야 합니다.
  • 대상(…)이 설치되어 실행 중이고, 인증이 활성화되어 있으며, …(root) 사용자의 비밀번호를 알고 있습니다. 대상 버전은 원본과 같거나 더 새 버전입니다(예: 7.0 → 8.0). 이전 버전으로의 복원은 지원되지 않습니다.

가이드 단계

  • 도구 설치 — MongoDB … repo 추가 · MongoDB … repo 추가 · mongodump, mongorestore, mongosh 설치 · 백업 디렉터리 준비
  • 백업 사용자와 자격 증명 파일 — 백업 사용자 생성 · 자격 증명 파일 작성 (--config) · 연결 테스트
  • 수동 백업 (mongodump) — 데이터 크기와 oplog 창 확인 · Balancer 중지 · mongodump로 백업 · Balancer 재시작 · 백업 검증 (gzip 및 dryRun) · 쿼리 기반 부분 백업 (--query)
  • 복원 (mongorestore) — 이름을 바꿔 테스트 복원 (--nsFrom/--nsTo) · 문서 수 비교 · 테스트 데이터베이스 삭제 · oplogReplay용 역할 정의 · 원래 위치 전체 복원 (--drop) · 임시 권한 회수 …
  • mongoexport / mongoimport (데이터 이전용, 백업 아님) — Collection 내보내기 (mongoexport) · 별도 collection으로 가져오기 (mongoimport) · 타입 비교 및 정리
  • 파일 시스템 snapshot — LVM snapshot 생성 (fsyncLock 사용) · snapshot을 백업 디렉터리에 아카이브 · fsyncLock으로 파일 복사
  • Sharded cluster 백업: 한계와 엔터프라이즈 방식 — 일관된 sharded cluster 백업을 위한 방법 선택
  • 예약 백업 및 보존 — balancer가 백업 시간 외에만 동작하도록 제한 · 백업 스크립트 작성 · 스크립트에 실행 권한 부여 · 원격 서버 SSH 접근 준비 · systemd service와 timer 생성 · 예약 백업을 수동으로 실행하여 검증 …
  • 모니터링 및 유지보수 — 마지막 백업 경과 시간 모니터링 · 정기 복구 훈련
  • 1. 진단: 백업 파일과 도구 — 백업 파일과 최근 백업을 순서대로 나열
  • 2. 리허설: 아카이브 읽기 — 압축 무결성 확인 (gzip -t) · 데이터를 쓰지 않고 복원 시험 (--dryRun) · 아카이브에 oplog가 있습니까? (일관된 시점)
  • 3. 리허설: 임시 instance에 전체 복원 — 임시 instance용 mongod 준비 · 임시 mongod 시작 · 임시 instance에 백업 복원 · 복원된 데이터 건수 확인 · 임시 instance 중지 및 삭제
  • 4. 사후 작업 — 리허설 결과 기록
  • Sharded cluster: 전체 복원은 이 시나리오로 하지 않음 — Sharded cluster 시나리오로 이동
  • 1. 진단: 전체 복원이 맞는 시나리오입니까? — 현재 상태와 영향받은 데이터 확인 · 데이터를 쓰지 않고 복원 시험 (--dryRun)
  • 2. 안전장치 — 애플리케이션 중지 및 연결 확인 · 현재 상태 백업 (복귀 지점)
  • 3. 실행: 전체 복원 — oplogReplay용 임시 권한 부여 · 원래 위치에 백업 복원 (--drop… --oplogReplay…) · 임시 권한 회수 · 복원 과정의 임시 사용자 collection 정리
  • 4. 검증 — 문서 수와 index 수 확인 · replica set 동기화 확인
  • 5. 사후 작업 — 새 전체 백업 수행 및 애플리케이션 시작
  • 1. 진단: namespace의 현재 상태와 백업 상태 — 운영 환경 상태 확인 · 데이터를 쓰지 않고 복원 시험 (--dryRun)
  • 2. 안전장치 — 현재 상태 백업 (복귀 지점)
  • 2. 실행: 새 이름으로 복원 — 새 이름으로 백업 복원 (--nsFrom/--nsTo) · 백업과 운영 환경의 건수 비교 · 삭제된 문서를 운영 환경에 다시 추가 ($merge) · 임시 사본 삭제
  • 3. 실행: 원래 위치에 복원 (--drop) — shard key 보존: collection 다시 shard · namespace를 원래 위치에 복원
  • 특정 시점 복구는 replica set에서만 가능 — 이 deployment에서는 oplog를 이용한 특정 시점 복구를 할 수 없습니다
  • 1. 진단: 잘못된 작업의 시점과 oplog 창 — oplog에서 잘못된 작업 찾기 · 전체 백업이 oplog 창 안에 있는지 확인
  • 2. 안전장치: 운영 oplog 복사 — 운영 oplog 사본 생성 · 현재 상태 백업 (복귀 지점)
  • 3. 실행: 임시 instance에서 해당 시점으로 복구 — 임시 instance용 mongod 준비 · 임시 mongod 시작 · 임시 instance에 전체 백업 복원 · 잘못된 작업 직전까지 운영 oplog 적용 · 임시 instance에서 복구된 데이터 확인 · 복구된 데이터를 운영 환경으로 옮기기 …
  • 4. 사후 작업 — 새 전체 백업 수행 및 근본 원인 제거
  • 1. 진단: 대상이 올바르고 호환됩니까? — 대상이 원본이 아닌지 확인하고 버전 확인 · 데이터를 쓰지 않고 복원 시험 (--dryRun)
  • 2. 안전장치와 대상 자격 증명 — 대상용 임시 자격 증명 파일 작성 · 대상의 기존 데이터 백업
내 환경에 맞춘 단계별 계획 열기 →