객체 잠금이 있는 불변 S3 백업

불변 S3 백업 작동 방식

객체 잠금이 활성화된 버킷으로 S3 스냅샷 저장소 구성하고 변경할 수 없는 백업을 활성화 후:

• Ops Manager Ops Manager 애플리케이션 데이터베이스 에만 메타데이터 보관하는 대신 스냅샷 블록과 복원 에 필요한 메타데이터 S3 버킷에 기록합니다.

• 구성된 경우 Ops Manager 각 스냅샷 에 대한 객체 잠금 보존을 연장하여 백업 작업 보존 창 종료되기 전에 객체 저장 삭제 또는 수정을 방지할 수 있도록 합니다.

• Ops Manager S3 버킷에 저장된 내용만 읽음으로써 이러한 변경 불가능한 스냅샷을 검색하고 미리 채워진 버킷에서 다른 Ops Manager 인스턴스 로 가져올 수 있습니다.

또한 객체 잠금이 활성화된 S3 oplog 저장소를 구성하는 경우:

• MongoDB Ops Manager는 스냅샷 데이터에 대해 수행하는 방식과 동일하게 oplog 슬라이스와 복원에 필요한 메타데이터를 S3 oplog 저장의 버킷에 쓰기 (write)합니다.

• MongoDB Agent는 해당 백업 작업에 대해 과반수가 커밋한 oplog 항목만 추적하므로, Ops Manager는 나중에 롤백으로 제거될 수 있는 oplog 항목을 백업하지 않습니다.

• MongoDB Ops Manager는 이러한 변경 불가능한 oplog를 가져온 변경 불가능한 스냅샷과 함께 다른 MongoDB Ops Manager 인스턴스로 검색 및 가져와서 가져온 백업에서 특정 시점 복원을 지원할 수 있습니다.

전제 조건

변경할 수 없는 S3 백업을 사용하려면 다음이 있어야 합니다.

• 변경 불가능한 스냅샷의 경우 MongoDB Ops Manager 8.0.19 이상이 필요합니다. 변경 불가능한 oplog의 경우 버전 9.0 또는 8.0.28이 추가로 필요합니다.

• Ops Manager 에 구성된 S3 스냅샷 저장소 (블록 저장소 ) . 불변 스냅샷은 S3기반 스냅샷 저장소만 지원 , MongoDB 블록 저장소나 파일 시스템 스냅샷 저장소는 지원하지 않습니다.

• 저장에 사용하는 버킷에서 객체 잠금이 활성화된 상태에서 객체 잠금을 지원하는 객체 저장 (예: AWS S3 또는 호환되는 어플라이언스)입니다. 대부분의 S3 제공자는 객체 잠금이 작동하기 위해 객체 버전 관리가 필요하며, 일부 제공자는 버킷 생성 중에만 객체 잠금을 허용합니다.

• 적절한 노드에서 백업이 활성화된 MongoDB Agent 및 PITR 을 위한 oplog (작업 로그) 저장 등과 같은 표준 백업 요구 사항.

• 스냅샷 저장소에 대해 객체 잠금(Object Lock)이 활성화된 S3 버킷입니다. 버킷이 새 버킷일 필요는 없으며 이 저장 전용일 필요도 없지만, 전용 버킷을 사용하는 것이 좋습니다. Ops Manager에서 기존 S3 스냅샷 저장소의 설정을 변경하여 객체 잠금을 활성화할 수 없습니다. 객체 잠금이 활성화된 버킷을 가리키는 새 S3 스냅샷 저장소를 구성해야 합니다.

• 불변 oplog를 사용하는 경우: oplog 저장소에 대해 버전 관리 및 객체 잠금이 활성화된 S3 버킷이 필요합니다. 버킷이 새 버킷일 필요는 없으며 이 저장 전용일 필요는 없지만, 전용 버킷을 사용하는 것이 좋습니다. MongoDB Ops Manager에서 기존 S3 oplog 저장 구성의 설정을 변경하여 객체 잠금을 활성화할 수는 없습니다. 버전 관리 및 객체 잠금이 활성화된 버킷을 가리키는 새 S3 oplog 저장소를 구성해야 합니다.

고려 사항

변경할 수 없는 S3 백업을 계획할 때는 다음 항목을 고려하세요.

• 소급 불변성이 없습니다. Ops Manager 변경할 수 없는 백업 활성화 후 객체 잠금을 사용하여 버킷에 기록된 스냅샷만 보호합니다. Ops Manager 기존 스냅샷 객체에 객체 잠금을 적용 하지 않습니다.

• 객체 잠금 구성. Ops Manager 객체 잠금을 지원 하지 않는 S3 버킷에 대해 불변성을 제공하지 않습니다. 버킷에 대한 객체 잠금을 별도로 구성해야 합니다. Ops Manager 에서 객체 잠금 설정을 구성하거나 버킷 설정을 생성한 후 업데이트해도 버킷에서 객체 잠금이 활성화 되지 않습니다.

• 기존 데이터의 자동 마이그레이션 없습니다. S3 저장소 간 백업 마이그레이션 기능 사용하면 백업 작업 에서 향후 스냅샷에 사용할 S3 스냅샷 저장소 변경할 수 있습니다. 버킷 간에 기존 스냅샷 데이터를 복사하거나 이동하지 않습니다.

• managed 저장소에 대한 보존 및 객체 잠금. 백업 작업 보존 정책에 따라 스냅샷이 만료되면 Ops Manager 스냅샷 노출을 중지하고 관련 객체를 삭제 하려고 시도합니다. Ops Manager 객체 잠금 보존 기간이 만료된 후에만 객체를 삭제 수 있습니다. 예시 를 들어 객체 가 아직 보존되어 객체 저장 삭제 거부하는 경우에도 그루밍 작업 실패하지 않습니다. Ops Manager 삭제 수 없는 객체를 대기열에 추가하고, 백업 디먼 객체 저장 허용할 때까지 mms.backup.groom.failedDeleteRetryDelayHours시간마다 삭제를 다시 시도합니다.

• 가져온 저장소에 대한 보존. MongoDB Ops Manager는 가져온 S3 버킷에서 데이터를 삭제하지 않습니다. MongoDB Ops Manager는 자체 애플리케이션 데이터베이스로 가져온 메타데이터를 삭제할 수 있습니다. 보존은 MongoDB Ops Manager의 메타데이터 가시성에만 영향을 미칩니다.

• oplog 불변성은 소급 적용되지 않습니다. S3 oplog 저장소를 생성할 때만 객체 잠금을 활성화할 수 있습니다. 기존 S3 oplog 저장소의 설정을 변경하여 객체 잠금을 활성화할 수는 없습니다. 대신 새 저장소를 만들어야 합니다.

• oplog 버전 고정은 기본적으로 꺼져 있습니다. 기본값 MongoDB Ops Manager는 변경 불가능한 oplog 저장에서 oplog slice를 다시 읽을 때 기록된 정확한 S3 객체 버전을 사용하지 않습니다. brs.oplogStoreFallBackToLatestVersion 애플리케이션 설정은 기본적으로 true로 설정되어 있어 MongoDB Ops Manager는 기록된 버전 대신 항상 최신 버전의 객체를 가져옵니다. MongoDB Ops Manager가 기록된 정확한 버전을 사용하도록 하려면 전역 관리자가 brs.oplogStoreFallBackToLatestVersion을(를) false(으)로 설정해야 합니다.

• oplog 테일링을 위한 과반수 커밋 토폴로지 요구 사항. MongoDB Ops Manager는 객체 잠금(Object Lock)이 활성화된 oplog 저장소의 과반수 커밋된 oplog 항목만 추적합니다. 객체 잠금은 MongoDB Ops Manager가 이미 저장소에 기록된 데이터를 되돌리거나 변경할 수 없음을 의미하기 때문입니다. 세컨더리가 중단된 PSA 토폴로지 또는 PAA 토폴로지에서 oplog 테일은 과반수 커밋에 도달할 수 없습니다. 따라서 토폴로지가 복구될 때까지 tailing이 중단됩니다. MongoDB Ops Manager는 이런 일이 발생하면 원인과 해결책을 명시하는 경고를 발생시킵니다.

변경할 수 없는 스냅샷 저장 구성

변경할 수 없는 스냅샷 저장소를 구성하려면 다음 작업을 완료하세요.

1. Ops Manager 에서 변경할 수 없는 백업을 활성화합니다.

2. 객체 잠금이 활성화된 S3 버킷을 준비합니다.

3. Ops Manager 에서 새 S3 스냅샷 저장소 구성합니다.

변경 불가능한 Oplog 저장 구성

변경할 수 없는 oplog 저장을 구성하려면 다음 작업을 완료합니다.

1. 아직 활성화하지 않았다면 MongoDB Ops Manager 에서 변경할 수 없는 백업을 활성화합니다.

2. 버전 관리가 가능하고 객체 잠금이 활성화된 S3 버킷을 준비합니다.

3. MongoDB Ops Manager에서 새 S3 oplog 저장소를 구성합니다.

4. 기존 백업 작업을 변경할 수 없는 S3 oplog 저장으로 전환합니다.

불변성 확인

MongoDB Ops Manager는 각 스냅샷의 데이터와 이를 보호하는 객체 잠금(Object Lock) 메타데이터를 S3 버킷에 자동으로 쓰기 (write)합니다. 데이터를 수동으로 내보낼 필요는 없습니다. 다음 절차를 사용하여 특정 스냅샷이 객체 잠금(Object Lock)으로 보호되는지 확인하십시오.

S3 oplog 저장에 객체 잠금이 활성화되어 있는지 확인하려면 oplog 저장 페이지로 이동하여 해당 저장의 설정을 확인하세요.

재해 복구를 위한 스냅샷 가져오기

변경할 수 없는 스냅샷과 백업 메타데이터 가 포함된 기존 S3 버킷에서 데이터를 복원 해야 하는 경우 해당 스냅샷을 Ops Manager 배포서버 로 가져올 수 있습니다. 이 워크플로는 Ops Manager 재구축 후 백업 복원과 같은 재해 복구 시나리오에 사용합니다.

가져오기가 완료되면 할당한 프로젝트 아래의 Continuous Backup 페이지에 가져온 스냅샷이 표시됩니다. MongoDB Ops Manager는 완전히 가져온 클러스터 스냅샷만 표시합니다.

MongoDB Ops Manager는 가져온 S3 버킷에서 데이터를 삭제하거나 그루밍하지 않습니다. 객체 저장 계층에서 가져온 스냅샷 객체의 수명 주기를 제어합니다. MongoDB Ops Manager는 자체 애플리케이션 데이터베이스로 가져온 메타데이터를 삭제할 수 있습니다.

재해 복구를 위한 Oplog 가져오기

변경 불가능한 oplog가 포함된 기존 S3 버킷에서 특정 시점 복원 데이터가 필요한 경우, 해당 oplog를 MongoDB Ops Manager 배포서버로 가져올 수 있습니다. 먼저 해당 스냅샷을 가져와야 합니다. MongoDB Ops Manager는 이미 가져온 스냅샷이 있는 클러스터에 대해서만 oplog를 검색할 수 있습니다.

가져오기가 완료되면 MongoDB Ops Manager는 해당 행에 Manage Oplogs 조치를 표시하며, 여기서 가져온 oplog를 보거나 삭제할 수 있습니다.

PITR과의상호 작용

PITR은 기준 스냅샷과 oplog 저장소에 저장된 oplog 데이터를 결합합니다. 변경 불가능한 스냅샷은 기준 스냅샷 구성 요소에만 영향을 미칩니다.

• 변경할 수 없는 S3 스냅샷 저장소로 전환하면 PITR은 기존 스냅샷 및 oplog 데이터에서 계속 작동합니다. 오래된 스냅샷은 원래 저장소에 그대로 유지됩니다. 그리고 oplog 저장 구성은 변경되지 않습니다.

• 새 저장 에서 변경할 수 없는 첫 번째 전체 스냅샷 완료되면PITR은 해당 스냅샷을 기준으로 사용하고 구성된 oplog 저장 에서 oplog를 계속 테일링할 수 있습니다.

• PITR은 가져온 스냅샷에서 해당 변경 불가능한 oplogs를 가져오는 경우에만 사용할 수 있습니다. 그렇지 않으면, 가져온 스냅샷은 Ops Manager가 스냅샷을 만든 정확한 시점까지만 복원 할 수 있습니다.

장애 시나리오 및 복구

변경할 수 없는 S3 스냅샷은 스냅샷 저장소를 전환할 때 추가 데이터 손실 시나리오를 유발하지 않습니다. 각 스냅샷 단일 저장 에서 복원되므로 복원 로직은 하나의 스냅샷 에 대해 여러 버킷의 데이터를 필요로 하지 않습니다.