프로덕션에 MongoDB 배포할 때는 데이터 손실로부터 보호할 수 있는 백업 및 복원 전략을 세워야 합니다.
이 페이지에서는 자체 관리 배포서버의 백업 방법을 설명합니다.
MongoDB Atlas 에서 호스팅되는 배포를 위한 백업 방법에 학습 보려면 데이터 백업, 복원 및 보관 를 참조하세요.
MongoDB Cloud Manager 또는 Ops Manager를 사용하여 백업
MongoDB Cloud Manager 는 MongoDB 위한 호스팅된 백업, 모니터링 및 자동화 서비스입니다. MongoDB Cloud Manager 그래픽 사용자 인터페이스에서 복제본 세트 와 샤딩된 클러스터 의 백업 및 복원을 지원합니다.
MongoDB Cloud Manager
중요
MongoDB Cloud Manager를 사용하여 복제본 세트와 샤딩된 클러스터를 백업하려면, MongoDB Enterprise Server를 사용해야 합니다. 자세한 내용은 MongoDB Enterprise 설치를 참조하세요.
MongoDB Cloud Manager는 oplog 데이터를 MongoDB deployment에서 읽어 복제본 세트와 샤딩된 클러스터를 백업합니다. MongoDB Cloud Manager 설정하다 간격으로 스냅샷을 생성하고 특정 시점 복구를 제공합니다.
팁
샤딩된 클러스터 스냅샷은 다른 MongoDB 백업 방법으로는 달성하기 어렵습니다.
MongoDB Cloud Manager 백업을 시작하려면 MongoDB Cloud Manager에 등록하십시오. MongoDB 클라우드 관리자에 대한 문서는 MongoDB 클라우드 관리자 참조하세요.
Ops Manager
Ops Manager 사용하면 MongoDB 구독자는 자신의 인프라에 MongoDB Cloud Manager 와 동일한 백업 소프트웨어를 설치하고 실행 수 있습니다. Ops Manager Enterprise Advanced 구독을 통해 사용할 수 있습니다.
Ops Manager에 대한 자세한 내용은 MongoDB Enterprise Advanced 페이지 및 Ops Manager 매뉴얼을 참조하세요.
기초 데이터 파일을 복사하여 백업
참고
AES256-GCM을 사용하는 암호화 스토리지 엔진에 대한 고려 사항
2} 암호화 모드를 사용하는 암호화된 스토리지 엔진의 AES256-GCM AES256-GCM 경우 는 모든 프로세스가 키와 함께 고유한 카운터 블록 값을 사용하도록 요구합니다.
2} 암호로 구성된 암호화된 스토리지 엔진의 경우: AES256-GCM
- 핫 백업에서 복원
mongod실행 중에 "핫" 백업 통해 가져온 파일에서 복원 경우, MongoDB 스타트업 시 "더티(dirty)" 키를 감지하고 IV(초기화 벡터) 재사용을 방지하기 위해 데이터베이스 키를 자동으로 롤오버합니다.
- 콜드 백업에서 복원
그러나
mongod가 실행 되지 않는 동안 '콜드' 백업 통해 가져온 파일에서 복원 경우, MongoDB 스타트업 시 '더티' 키를 감지하지 못하며, IV를 재사용하면 기밀성과 무결성 보장 무효화됩니다.콜드 파일 시스템 스냅샷 에서 복원한 후 키 재사용을 방지하기 위해 MongoDB 새로운 명령줄 옵션
--eseDatabaseKeyRollover을 추가합니다.--eseDatabaseKeyRollover옵션으로 시작하면mongod인스턴스AES256-GCM암호로 구성된 데이터베이스 키를 롤오버하고 종료합니다.
If using filesystem-based backups for MongoDB Enterprise, use the "hot" 백업 기능 사용하세요.
파일 시스템 스냅샷으로 백업
MongoDB 데이터 파일을 저장하는 볼륨이 특정 시점 스냅샷을 지원하는 경우, 해당 스냅샷을 사용하여 정확한 시점에 백업을 생성합니다. 파일 시스템 스냅샷은 운영 체제 볼륨 관리자 기능 이며 MongoDB 에만 국한되지 않습니다. 운영 체제는 백업 기준으로 사용할 볼륨의 스냅샷 만듭니다. 스냅샷의 메커니즘은 기본 저장 시스템에 따라 다릅니다. 예시 를 들어 Linux 에서는 LVM (Logical Volume 관리자 )이 스냅샷을 생성할 수 있습니다. 마찬가지로 EC2 용 Amazon의 EBS 저장 시스템은 스냅샷을 지원합니다.
실행 중인 프로세스의 mongod 올바른 스냅샷을 얻으려면 저널링을 활성화해야 하며 저널은 다른 MongoDB 데이터 파일과 동일한 논리 볼륨에 있어야 합니다.
샤딩된 클러스터의 일관된 스냅샷을 얻으려면 밸런서를 비활성화하고 거의 같은 시간에 Config 서버뿐만 아니라 모든 샤드에서 스냅샷을 캡처해야 합니다. 샤딩된 클러스터를 백업하려면 데이터베이스 덤프를 사용한 자체 관리형 샤딩된 클러스터 백업을 참조하세요.
자세한 내용은 파일 시스템 스냅샷으로 자체 관리형 배포서버 백업 및 파일 시스템 스냅샷으로 자체 관리형 클러스터 백업하기 에서 LVM 사용하여 스냅샷을 만드는 방법에 대한 전체 지침을 참조하세요.
cp 또는 rsync로 백업
저장 시스템이 스냅샷을 지원하지 않는 경우 cp rsync, 또는 이와 유사한 도구를 사용하여 파일을 직접 복사할 수 있습니다. 여러 파일을 복사하는 것은 원자적인 작업이 아니므로 파일을 복사하기 전에 mongod에 대한 모든 쓰기를 중지해야 합니다.
기본 데이터를 복사하여 생성된 백업은 복제본 세트에 대한 특정 시점 복구를 지원하지 않으며, 대규모 샤딩된 클러스터를 관리하기 어렵습니다. 또한 이러한 백업에는 인덱스가 포함되고 기본 스토리지 패딩 및 프래그먼트화가 중복되기 때문에 더 커집니다. 반면에 mongodump는 더 작은 백업을 생성합니다.
백업 방법 mongodump
mongodump 및 mongorestore 는 소규모 MongoDB 배포를 백업 및 복원하기 위한 도구입니다. 자세한 학습 은 MongoDB 도구를 사용하여 자체 관리형 배포서버 백업 및 복원을 참조하세요.
샤딩된 클러스터를 백업하려면 데이터베이스 덤프를 사용하여 자체 관리형 샤딩 클러스터백업을 참조하세요.
백업 방법 비교
다음 표는 온프레미스 배포를 위한 백업 방법을 비교합니다.
백업 고려 사항 | Cloud Manager/Ops Manager | 파일시스템 스냅샷 | |
|---|---|---|---|
백업 RTO | 낮음/스냅샷 저장소 유형에 따라 다름 | 낮은 | 높음 |
백업 RPO | 낮은 | 높음 | 높음 |
백업 스토리지 비용 | 낮음/스냅샷 저장소 유형에 따라 다름 | 중간 | 높음 |
백업 관리에 소요되는 직원 시간 | 없음/스냅샷 저장소 유형에 따라 다름 | 높음 | 높음 |
지속적인 특정 시점 백업 및 복원 | 예 | No | No |
복원 작업의 복잡성 | 배포가 자동화된 경우 낮음 | 샤딩된 클러스터의 경우 높음 | 낮은 |
샤딩된 클러스터 백업의 복잡성 | 낮은 | 높음, 추가 단계 필요 | 높음, 추가 단계 필요 |
소스 샤딩된 클러스터 배포에 대한 백업의 영향 | 낮은 | 높음/쓰기 잠금 필요 | 높음/쓰기 잠금 필요 |
샤딩된 클러스터 백업의 일관성 | 보장됨 | 보장되지 않음/불일치를 줄이기 위해 | 보장되지 않음/불일치를 줄이기 위해 |
증분 백업 | 필요함/일일 증분 백업 및 주간 전체 백업 수행 | 저장 및 도구에 따라 다름 | No |
백업 범위 정의 | 필요함/네임스페이스 필터링으로 수행 | No | 예 |