백업 준비
클러스터 또는 복제본 세트를 백업하기 전에 데이터를 백업하는 방법과 백업할 데이터를 결정하세요. 이 페이지에서는 백업을 시작하기 전에 고려해야 할 항목에 대해 설명합니다.
경고
MongoDB Ops Manager는 더 이상 로컬 키 암호화 를 사용하는 데이터베이스 배포에서 클러스터 스냅샷 생성을 지원하지 않습니다. 로컬 키 암호화를 사용하여 데이터베이스 배포를 암호화하면 스냅샷이 실패합니다. 스냅샷을 암호화하려면 데이터베이스 배포에 KMIP기반 암호화를 사용합니다.
백업 구성 옵션
특정 시스템의 백업 및 복구 요구 사항은 시스템 소유자가 설정한 비용, 성능 및 데이터 보호 표준에 따라 달라집니다.
Ops Manager 엔터프라이즈 백업 및 복구는 5가지 백업 아키텍처를 지원하며, 각 아키텍처에는 고유한 강점과 장단점이 있습니다. 백업 아키텍처를 구성하고 배포하기 전에 배포에 필요한 데이터 보호 요구 사항을 충족하는 아키텍처를 고려하세요.
예시
낮은 운영 비용이 요구 사항인 시스템을 고려하세요. 시스템 소유자는 백업 및 복구 구성을 위해 스토리지에 지출할 수 있는 비용을 엄격하게 제한할 수 있습니다. 결과적으로 복구 시간이 더 오래 걸릴 수 있습니다.
반대로 복구 시간 목표가 낮아야 하는 시스템을 가정해 보겠습니다. 시스템 소유자는 복구 요구 사항을 충족하는 백업 및 복구 구성으로 인해 더 많은 스토리지 비용을 감수할 수 있습니다.
Ops Manager 엔터프라이즈 백업 및 복구는 다음과 같은 백업 아키텍처를 지원합니다:
고가용성, 압축, 중복 제거 등 파일 시스템 백업을 위한 고급 기능을 갖춘 SAN의 파일 시스템입니다.
하나 이상의 NAS 장치에 있는 파일 시스템
고가용성 구성의 MongoDB 블록 저장소
독립형 구성의 MongoDB 블록 저장소
중요
자체 데이터 보호 접근 방식을 개발하기 위한 지침으로 백업 아키텍처 권장 사항을 제공합니다. 권장 사항은 각 시나리오 또는 배포를 다루거나 나타내지 않습니다.
백업 방법 기능
백업 시스템 기능 | SAN의 파일 시스템 | NAS의 파일 시스템 | AWS S3 블록 저장소 | MongoDB HA 블록 저장소 | MongoDB 블록 저장소 |
|---|---|---|---|---|---|
스냅샷 유형 | 완료 [1] | 완료 [1] | 많은 부분 | 많은 부분 | 많은 부분 |
백업 데이터 중복 제거 | SAN이 다음을 지원하는 경우 | No | 예 | 예 | 예 |
백업 데이터 압축 | 예 | No | 예 | 예 | 예 |
백업 데이터 복제 | SAN이 다음을 지원하는 경우 | No | No | 예 | No |
백업 스토리지 비용 | 높음 | 중간 | 낮음 | 높음 | 낮음 |
백업 관리에 소요되는 직원 시간 | 중간 | 중간 | 낮음 | 높음 | 중간 |
백업 RTO | 낮음 | 중간 | 낮음 | 낮음 | 중간 |
| [1] | (1, 2) 파일 시스템 저장소 에 증분 백업을 수행하기 위해 MongoDB Agent 는 백업용으로 지정된 경로에 있는 각 storage engine 파일을 데이터 블록으로 슬라이스하고 변경된 블록만 다음으로 전송합니다. MongoDB Ops Manager. MongoDB Ops Manager는 수신된 블록에서 새 스냅샷 을 만들고 이전 전체 백업 스냅샷에서 변경되지 않은 나머지 블록을 복사합니다. 파일 시스템에 저장된 각 증분 백업 스냅샷은 네트워크 I/O를 절약합니다. 이러한 각 백업 스냅샷에는 백업된 MongoDB deployment에서 필요한 모든 파일의 전체 복사본이 포함되어 있으며 레코드 중복을 제거 하지 않습니다. |
참고
특정 백업 방법은 언제 사용하나요?
대량의 데이터에 대해 백업을 자주 실행하고 백업에서 복원하려면 SAN 의 파일 시스템, Amazon Web Services S3호환 스토리지 스냅샷 저장소 또는 복제본 세트 또는 복제본 세트로 구성된 MongoDB 블록 저장소에 백업하는 것이 좋습니다. 샤드 클러스터.
MongoDB database를 사용하지 않고 데이터를 복원하려면 AWS S3 호환 스토리지 스냅샷 저장소, 하나 이상의 NAS 장치, 고가용성, 압축 또는 중복 제거와 같은 파일 시스템 백업을 위한 고급 기능을 갖춘 SAN의 파일 시스템에 백업하는 것이 좋습니다.
내부 스토리지 및 유지 보수 비용을 최소화하려면 AWS S3 호환 스토리지 스냅샷 저장소 또는 MongoDB 독립형 블록 저장소에 백업하는 것을 고려하세요.
MongoDB 독립형 블록 저장소는 제한된 회복 탄력성을 제공합니다. 이 블록 저장소는 디스크가 가득 차면 오프라인 상태가 될 수 있습니다. 추가 스토리지를 추가한 후에만 백업 스냅샷을 복구할 수 있습니다.
백업 크기 조정 권장 사항
데이터 백업의 크기를 조정할 때 복제본 세트 크기를 압축되지 않은 데이터 의 2 TB 이하로 유지합니다. 데이터베이스의 비압축 데이터가 2 TB를 초과하여 증가하는 경우:
데이터베이스 샤딩
각 샤드의 비압축 데이터를 2TB 이하로 유지하세요.
이러한 사이즈 제한은 권장사항입니다. MongoDB database 또는 Ops Manager의 제한 사항이 아닙니다.
백업 및 복원은 대용량의 CPU, 메모리, 스토리지 및 네트워크 대역폭을 사용할 수 있습니다.
예시
명시된 네트워크 처리량(예: 10Gbps 또는 100Gbps)은 이론적 최대값입니다. 이 값은 네트워크 트래픽 공유 또는 제한을 고려하지 않습니다.
다음 시나리오를 생각해 보겠습니다.
2TB 데이터베이스를 백업하려고 합니다.
호스트는 Ops Manager에서 백업 스토리지로의 10Gbps TCP 연결을 지원합니다.
네트워크 연결은 패킷 손실이 매우 적고 왕복 지연 시간이 낮습니다.
데이터의 전체 백업 을 완료하는 데 30 시간 이상이 걸립니다. [3]
이는 단일 또는 미러링된 NVMe 스토리지 장치에 대해 최대 3Gbps 읽기 및 1Gbps 쓰기가 가능한 디스크 읽기 및 쓰기 속도를 고려하지 않은 예상치입니다.
각 연속 증분 백업을 완료하는 데 필요한 시간은 쓰기 부하에 따라 다릅니다.
이 데이터베이스를 샤딩하여 4개의 샤드로 만들면 각 샤드에서 백업을 개별적으로 실행합니다. 이렇게 하면 8시간 안에 백업을 완료할 수 있습니다.
| [2] | 이 처리량 수치는 네트워크 처리량 계산기 를 사용하여 계산되었습니다. 추가 네트워크 압축이 없다고 가정합니다. |
스냅샷 빈도 및 보존 정책
Ops Manager는 기본적으로 24시간마다 데이터의 기본 스냅샷을 만듭니다.
관리자는 기본 스냅샷의 빈도를 6, 8, 12 또는 24시간으로 변경할 수 있습니다. Ops Manager는 일정에 따라 자동으로 스냅샷을 생성하므로, 필요에 따라 스냅샷을 찍을 수는 없습니다.
Ops Manager는 다음 표에 안내된 기간 동안 스냅샷을 보관합니다.
배포 백업을 종료하면 현재 보존 정책의 날짜 내에 있는 스냅샷이 Ops Manager에서 즉시 삭제됩니다.
배포 백업을 중지하면 Ops Manager는 새 스냅샷 생성을 중지하지만, 기존 스냅샷은 안내된 만료 날짜까지 유지합니다.
스냅샷 | 기본 보존 정책 | 최대 보유 기간 정책 |
|---|---|---|
기본 스냅샷 | 2일 | 5일(빈도가 24시간인 경우 30일) |
일일 스냅샷 | 0일 | 1년 |
주간 스냅샷 | 2주 | 1년 |
월간 스냅샷 | 1개월 | 7년 |
Backup 페이지를 통해 제공되는 Edit Snapshot Schedule 메뉴 옵션을 통해 백업된 배포의 일정을 변경할 수 있습니다. 관리자는 API의 SnapshotSchedule 리소스를 통해 스냅샷 빈도와 보존 기간을 변경할 수 있습니다.
기준 시간을 변경하면 다음 예약된 스냅샷의 시간이 변경됩니다. 예약된 다음 스냅샷이 현재 다음 스냅샷 시간보다 빨리 생성되도록 할 수는 없습니다. 현재 다음 스냅샷 시간은 현재 기준 시간에 스냅샷 간의 간격을 더한 값입니다.
다음 스냅샷 시간을 확인하려면 현재 다음 스냅샷 시간을 새 기준 시간과 비교하세요.
새 기준 시간이 현재 다음 스냅샷 시간 이전인 경우, 다음 스냅샷은 여전히 현재 다음 스냅샷 시간 이후에 생성됩니다. 스냅샷은 새 기준 시간에 현재 다음 스냅샷 시간을 초과하는 데 필요한 간격 수를 더한 시간에 생성됩니다. 변경할 때 이 시간이 이미 지난 경우, Ops Manager는 다음에 새 기준 시간이 발생할 때 다음 스냅샷을 찍습니다. 예시는 다음 표의 처음 두 줄을 참조하세요.
새 참고 시간이 현재 다음 스냅샷 시간 이후인 경우, Ops Manager는 다음에 새 기준 시간이 발생할 때 다음 스냅샷을 찍습니다. 예시는 다음 표의 세 번째와 네 번째 줄을 참조하세요.
변경 시점 | 현재 기준 시간 | 스냅샷 간 간격 | 현재 다음 스냅샷 시간 | 새 기준 시간 | 다음 스냅샷 시간 |
|---|---|---|---|---|---|
08:00 UTC | 12:00 UTC | 6시간 | 12:00 UTC | 10:00 (UTC) | 오늘 16:00 UTC |
23:00 UTC | 12:00 UTC | 6시간 | 00:00 UTC | 10:00 (UTC) | 내일 04:00 UTC |
08:00 UTC | 12:00 UTC | 6시간 | 12:00 UTC | 19:00 UTC | 오늘 19:00 UTC |
20:00 UTC | 12:00 UTC | 6시간 | 00:00 UTC | 19:00 UTC | 내일 01:00 UTC |
스냅샷을 더 적게 저장하도록 일정을 변경하는 경우 Ops Manager는 새 일정을 맞추기 위해 기존 스냅샷을 삭제하지 않습니다. 불필요한 스냅샷을 삭제하려면 스냅샷 삭제를 참조하세요.
제한
Ops Manager는 배포의 총 컬렉션 수가
100,000이상인 배포를 백업하지 않습니다.Ops Manager는 인덱스 컬렉션 옵션을 복제하지 않습니다.
암호화 (Encryption)
는 스토리지 엔진을MongoDB Ops Manager MongoDB Enterprise 사용하여 FCV 3 4 4.0 WiredTiger 및 . 간에 를 실행하는 헤드 데이터베이스 에 저장된 모든 백업 작업을 암호화할 수 있습니다.
FCV 4.2 그리고 나중에 헤드 데이터베이스 대신 백업 커서 를 사용할 수 있습니다. 자세한 내용은 백업 디먼 서비스를 참조하세요.
백업 고려 사항
일관성 및 스냅샷
MongoDB 버전 4.2 이상을 실행하는 클러스터
MongoDB Ops Manager는 collStats 및 에서 보고한 크기 통계를 제외하고 스냅샷을 생성할 때 인과적 일관성 을 유지합니다.
db.[collection].count()collStats 및db.[collection].count()에서 보고하는 크기 통계는 정확하지 않을 수 있습니다.Ops Manager는 샤딩된 클러스터의 모든 샤드에 걸쳐 시간을 조정합니다. 이렇게 하면 예약된 스냅샷 시간을 기준으로 모든 샤드 및 노드에 기록된 모든 문서가 스냅샷에 포함됩니다.
MongoDB 버전 4.0 이하를 실행하는 클러스터
Ops Manager는 충돌 일관성이 있는 스냅샷을 유지합니다.
Ops Manager는 샤딩된 클러스터와 config 서버 복제본 세트에 대해 각 샤드에서 거의 동시에 스냅샷을 생성합니다.
FCV 4.2 이상을 실행하는 데이터베이스
현재 지원되는 백업 기능
기능 | FCV 4.2 이상을 실행하는 데이터베이스 | FCV 4.0 이하를 실행하는 데이터베이스 |
|---|---|---|
WiredTiger 스냅샷을 이용한 데이터 백업 | ||
백업 데몬을 사용하여 데이터 백업 | ||
복제본 세트 백업 | ||
샤딩된 클러스터 백업 | ||
네임스페이스를 사용하여 필터링 가능 [4] | ||
동기화 소스 데이터베이스 지정 가능 | ||
데이터를 특정 시점으로 복원할 수 있음 [5] | ||
증분 백업 수행 가능 [6] | ||
KMIP 암호화 [7]를 사용하는 스냅샷 지원 | ||
로컬 키 암호화 [8]를 사용하는 스냅샷 지원 | ||
블록 저장소 스냅샷 스토리지에 저장 지원 | ||
S3 호환 스토리지에 저장 지원 스냅샷 스토리지 | ||
파일 시스템 스토리지 [9]에 저장 지원 | ||
MongoDB Enterprise를 실행하는 데이터베이스 지원 | ||
MongoDB Community를 실행하는 데이터베이스 지원 | ||
| [3] | 네임스페이스 필터링은 Ops Manager 버전 6.0.8 이상에서만 지원됩니다. MongoDB deployment의 featureCompatibilityVersion 값이 4.0 이하이거나 6.0.1 이상이어야 합니다. |
| [4] | PIT 복원을 수행하려면 Ops Manager 4.2.13 이상이 필요합니다. |
| [5] | Ops Manager는 스냅샷이 삭제된 후 블록 저장소 블록 크기가 변경된 경우 첫 번째 백업에 대한 전체 백업을 요구합니다. 증분 백업은 네트워크 전송 및 스토리지 비용을 줄여줍니다. 이 기능은 다음과 같은 경우에 사용할 수 있습니다.
|
| [6] | 암호화된 스냅샷을 쿼리하려면 MongoDB Enterprise 4.2.9 이상 또는 4.4.0 이상이 필요합니다. |
| [7] | FCV 4.2 이상 백업은 로컬 키 암호화를 지원하지 않습니다. |
| [8] | FCV 4.2 이상 데이터베이스에 대한 파일 시스템 저장소 백업은 File System Store Gzip Compression Level 무시합니다. |
요구 사항 및 제한 사항
MongoDB 4.2 이상을 FCV 4.2 이상으로 실행하는 경우 백업 및 복원을 실행하려면 다음을 수행합니다.
블록 저장소 블록 크기 변경을 고려해야 합니다. 블록 크기를 설정하지 않고 기본값을 사용한 경우 해당 블록 크기는 64KB에서 1MB로 변경됩니다. 이는 스토리지 사용량에 영향을 줄 수 있습니다.
복제본 세트 구성의 호스트 이름이 MongoDB Agent가 사용하는 호스트 이름과 일치하는지 또는 호스트 매핑 에 올바른 호스트 이름이 포함되어 있는지 확인해야 합니다. rs.conf() 를 사용하여 복제본 세트 구성을 확인할 수 있습니다.
네임스페이스 필터 목록을 사용하여 MongoDB 6.0 이상을 실행하는 경우에만 백업에 포함된 네임스페이스 를 정의할 수 있습니다. MongoDB 4.2 ~ 5.0 버전에서 만든 스냅샷에는 항상 모든 네임스페이스가 포함됩니다.
동기화 소스 데이터베이스가 필요하지 않습니다. Ops Manager 스냅샷을 만들 때 성능에 미치는 영향이 가장 적고 스냅샷 데이터의 스토리지 수준 중복이 가장 큰 복제본 세트 노드를 선택합니다.
클러스터의 모든
mongod노드와 함께 MongoDB Agent를 배포해야 합니다.
참고
Ops Manager가 클러스터를 관리하지 않는 경우
백업을 실행하는 MongoDB
backup사용자에게 및 역할을 부여 합니다.clusterAdminMongoDB Agent를 실행하는 시스템 사용자에게 배포의 모든 데이터 파일(저널 파일 포함)에 대한 읽기 권한이 있는지 확인합니다.
공유 파일 시스템
또는 HTTPS HTTP 로드 밸런서 뒤에서 여러 애플리케이션 서버를 사용하고 MongoDB Ops Manager MongoDB Ops Manager 파일 시스템 스냅샷 을 사용하도록 를 구성하는 경우, FCV 4.2 이상의 백업 스냅샷 작업은 하나 이상의 서버에서 병렬로 실행됩니다. 각 MongoDB Ops Manager 서버에 공유 파일 시스템이 마운트되어 있는지 확인합니다. MongoDB Ops Manager 애플리케이션 서버는 동일한 파일의 서로 다른 오프셋을 열고 쓸 수 있습니다. 공유 파일 시스템에서 이를 허용하는지 확인합니다. 그렇지 않으면 액세스 오류가 발생합니다.
FCV 4.0 이하를 실행하는 데이터베이스
중요
샤딩된 클러스터 또는 복제본 세트만 백업할 수 있습니다. 독립형 mongod 프로세스를 백업하려면 그것을 반드시 단일 노드 복제본 세트로 변환해야 합니다.
다음 고려 사항은 데이터베이스가 MongoDB 4.0 이하 버전을 실행하거나 MongoDB 4.2를 다음으로 실행하는 경우에 적용됩니다.
"featureCompatibilityVersion" : 4.0
만료된 스냅샷의 가비지 컬렉션
Ops Manager는 만료된 스냅샷을 그루밍 작업을 사용하여 관리합니다. 이러한 정리 작업은 스냅샷이 포함된 스냅샷 저장소에 따라 다르게 작동합니다.
스냅샷 저장소 | 그루밍 작업 방식 |
|---|---|
MongoDB 블록 저장소 | 각 작업에 필요한 리빙 블록의 양까지 추가 디스크 공간을 사용합니다. |
파일시스템 스냅샷 저장소 | 만료된 스냅샷 삭제 |
S3 Snapshot Store | 그루밍 작업이 실행되는 동안 Ops Manager가 스냅샷을 생성하는 경우 추가 디스크 공간을 사용할 수 있습니다. Ops Manager는 S3 Snapshot Store에서 동시 그루밍 작업을 실행할 수 있습니다. |
참고
스냅샷 작업과 그루밍 작업은 동시에 실행할 수 없습니다. 스냅샷 작업이 실행되는 동안 그루밍 작업을 시작하면 그루밍 작업이 실패하고 MongoDB Ops Manager가 오류를 기록하고 스냅샷 작업이 완료된 후 그루밍 작업을 자동으로 다시 시도합니다. 그루밍 작업이 실행되는 동안 스냅샷 작업을 시작하면 스냅샷 작업이 실패하고 MongoDB Ops Manager가 오류를 기록하고 그루밍 작업이 완료된 후 스냅샷 작업을 다시 시도합니다.
그루밍 작업에 대해 자세히 알아보려면 그루밍 작업을 참조하세요 .
네임스페이스 필터
네임스페이스 필터하다 를 사용하면 백업할 데이터베이스와 컬렉션을 지정할 수 있습니다. admin 및 local 를 제외한 모든 데이터베이스 와 system 로 시작하지 않는 모든 컬렉션 에 네임스페이스 필터하다 를 적용 할 수 있습니다.
제외할 항목의 Blacklist 또는 포함할 항목의 Whitelist를 작성합니다. 백업을 시작할 때 선택한 항목은 나중에 필요에 따라 편집할 수 있습니다. 백업에 데이터를 추가하는 방식으로 필터를 변경하는 경우에는 다시 동기화해야 합니다.
블랙리스트를 사용하면 로깅 데이터, 캐시 또는 기타 임시 데이터가 포함된 컬렉션의 백업을 방지할 수 있습니다. 이러한 종류의 데이터베이스 및 컬렉션을 제외하면 백업 시간과 비용을 줄일 수 있습니다. 화이트리스트는 백업하려는 모든 네임스페이스를 의도적으로 선택해야 하므로, 블랙리스트를 사용하는 것이 화이트리스트를 사용하는 것보다 더 나은 경우가 많습니다.
참고
네임스페이스 필터링은 Ops Manager 버전 6.0.8 이상에서만 지원됩니다. MongoDB deployment의 featureCompatibilityVersion 값이 4.0 이하이거나 6.0.1 이상이어야 합니다.
스토리지 엔진
MongoDB cluster를 백업하려면 WiredTiger 스토리지 엔진 스토리지 엔진을 사용하세요.
현재 백업 데이터베이스가 MMAPv1을 사용하는 경우 WiredTiger로 업그레이드하세요.
WiredTiger를 사용하면 Ops Manager는 백업을 파일 수가 10만 개 미만인 배포로 제한합니다. 파일에는 컬렉션과 인덱스가 포함됩니다.
MongoDB 4.2 이 MMAPv1 스토리지를 제거합니다. 스토리지 엔진에 대해 자세히 알아보려면 MongoDB 매뉴얼의 스토리지 를 참조하세요.
프로덕션 배포 재동기화
프로덕션 배포의 경우, 백업된 모든 복제본 세트를 1년에 한 번 등 주기적으로 재동기화하세요. 재동기화하면 각 복제본 세트의 세컨더리에서 데이터를 읽습니다. 재동기화 중에는 새 스냅샷이 생성되지 않습니다.
다음과 같은 경우 백업을 재동기화할 수 있습니다.
데이터 크기를 줄여 디스크에 있는 Ops Manager의 데이터 사본 크기도 함께 감소
문서를 주기적으로 삭제하는 TTL 인덱스 생성
컬렉션을 삭제합니다 (MMAPv1 에만 해당).
샤드 클러스터 를 실행하고 특정 샤드에서 청크를 이동합니다.
Ops Manager가 새 스토리지 엔진 형식으로 스냅샷을 제공하도록 하려면 스토리지 엔진을 전환합니다.
체크포인트
중요
기능 호환성 버전 이 4.0 이하인 MongoDB를 실행하는 클러스터에 체크포인트를 사용할 수 있습니다. FCV 가 4.2 이상인 MongoDB 인스턴스에서 체크포인트가 제거되었습니다.
샤딩된 클러스터 의 경우, 체크포인트는 스냅샷 사이에 추가 복원 지점을 제공합니다. 체크포인트를 활성화하면 MongoDB Ops Manager 가 스냅샷 사이에 15, 30 또는 60 분마다 구성 가능한 간격으로 복원 지점을 생성합니다. 체크포인트를 활성화 하려면 체크포인트 활성화를 참조하세요 .
체크포인트를 생성하기 위해 MongoDB Ops Manager는 밸런서 를 중지하고 oplog 클러스터의 각 샤드 및 config 서버 의 에 토큰을 삽입합니다. 이러한 체크포인트 토큰은 가벼우며 성능이나 디스크 사용에 영향을 주지 않습니다.
백업에는 체크포인트가 필요하지 않으며 기본적으로 비활성화되어 있습니다.
체크포인트에서 복원하려면 Ops Manager가 각 shard 및 config 서버의 oplog를 체크포인트 전에 캡처한 마지막 스냅샷에 적용해야 합니다. 체크포인트에서 복원하는 경우 스냅샷에서 복원하는 것보다 시간이 오래 걸립니다.
에이전트가 밸런서를 중지할 수 없는 경우의 스냅샷
FCV 4.0 이하로 실행되는 샤드 클러스터 의 경우, MongoDB Ops Manager 는 클러스터 스냅샷을 생성하기 전에 밸런서 를 비활성화합니다. 마이그레이션이 오래 걸리거나 mongos 가 실행되지 않는 등의 특정 상황에서 MongoDB Ops Manager 는 밸런서를 비활성화하려고 시도하지만 비활성화할 수 없습니다. 이러한 경우 MongoDB Ops Manager 는 클러스터 스냅샷을 계속 생성하지만 불완전하거나 일관되지 않은 데이터가 있을 수 있는 스냅샷에 플래그를 지정합니다. 활성 밸런싱 작업 중에 생성된 클러스터 스냅샷은 데이터 손실 또는 고아 데이터의 위험이 있습니다.
에이전트가 연결할 수 없는 경우 스냅샷 mongod
샤드 클러스터 의 경우, 백업이 샤드 또는 config 서버에 관계없이 mongod 프로세스에 연결할 수 없으면 에이전트가 동기화 oplog 토큰 을 삽입할 수 없습니다. 이러한 경우 MongoDB Ops Manager는 스냅샷을 생성하지 않고 경고 메시지를 표시합니다.