다음을 통해 공유

Azure Cosmos DB의 특정 시점 복원을 사용한 지속적인 백업

  • 아티클

적용 대상: NoSQL MongoDB Gremlin 테이블

Azure Cosmos DB의 특정 시점 복원 기능은 다음을 포함한 여러 시나리오에서 유용합니다.

  • 컨테이너 내에서 실수로 인한 쓰기 또는 삭제 작업으로부터 복구
  • 삭제된 계정, 데이터베이스 또는 컨테이너를 복원
  • 특정 복원 시점의 백업이 존재하던 지역으로 복원

Azure Cosmos DB는 추가로 프로비전된 처리량(RU)을 사용하지 않으며 데이터베이스의 성능 및 가용성에 영향을 주지 않고 백그라운드에서 데이터 백업을 수행합니다. 지속적인 백업은 계정이 있는 모든 지역에서 수행됩니다. 예를 들어 계정의 쓰기 지역은 미국 서부에 있고 읽기 지역은 미국 동부 및 미국 동부 2에 있을 수 있습니다. 이러한 복제본 지역을 각 지역의 원격 Azure Storage 계정에 백업할 수 있습니다. 기본적으로 각 지역은 로컬 중복 스토리지 계정에 백업을 저장합니다. 지역에서 가용성 영역을 사용하는 경우 백업은 영역 중복 스토리지 계정에 저장됩니다.

컨테이너가 여러 지역에서 백업되는 방식을 보여주는 다이어그램.

복원에 사용할 수 있는 기간(보존 기간이라고도 함)은 30일과 7일 중 작은 값입니다.

선택하는 옵션은 선택한 지속적인 백업 계층에 따라 달라집니다. 리소스가 만들어진 시점 이후의 보존 기간 내 모든 타임스탬프를 복원 시점으로 사용할 수 있습니다. 강력한 일관성 모드에서는 쓰기 영역에서 수행된 백업이 읽기 영역에 비해 더 최신입니다. 읽기 영역은 네트워크 또는 기타 일시적인 문제로 인해 지연될 수 있습니다. 복원을 수행하는 동안 특정 지역의 특정 리소스에 대한 최신 복원 가능한 타임스탬프를 얻을 수 있습니다. 복원 가능한 최신 타임스탬프를 참조하면 리소스 백업이 지정된 타임스탬프만큼 최신 상태인지 확인하는 데 도움이 되며 해당 지역에서 복원할 수 있습니다.

현재 특정 시점의 Azure Cosmos DB 계정(API for NoSQL 또는 MongoDB, API for Table, API for Gremlin) 콘텐츠를 다른 계정으로 복원할 수 있습니다. 이 복원 작업은 Azure Portal, Azure CLI, Azure PowerShell 또는 Azure Resource Manager 템플릿에서 수행할 수 있습니다.

백업 스토리지 중복성

기본적으로 Azure Cosmos DB는 연속 모드 백업 데이터를 로컬 중복 스토리지 Blob에 저장합니다. 영역 중복이 구성된 지역의 경우 백업이 영역 중복 스토리지 Blob에 저장됩니다. 연속 백업 모드에서는 백업 스토리지 중복도를 업데이트할 수 없습니다.

복원하는 다양한 방법

지속적인 백업 모드는 삭제된 컨테이너와 데이터베이스를 복원하는 두 가지 방법을 지원합니다. 여기에 설명된 대로 새 계정으로 복원하거나 여기에 설명된 대로 기존 계정으로 복원할 수 있습니다. 이러한 두 모드 중에서의 선택은 시나리오에 따라 달라집니다. 대부분의 경우 삭제된 컨테이너 및 데이터베이스를 기존 계정으로 복원하는 것이 좋습니다. 이렇게 하면 새 계정으로 복원되는 경우 필요한 데이터 전송 비용을 방지할 수 있습니다. 실수로 데이터를 수정한 시나리오의 경우 새 계정으로 복원하는 것이 선호되는 옵션일 수 있습니다.

새 계정으로 복원되는 항목은 무엇인가요?

안정적인 상태에서 원본 계정(데이터베이스, 컨테이너 및 항목 포함)에서 수행되는 모든 변경은 100초 이내에 비동기적으로 백업됩니다. Azure Storage 백업 미디어가 다운되었거나 사용할 수 없는 경우 미디어를 사용할 수 있을 때까지 변경 내용이 로컬에서 유지됩니다. 그리고 복원 가능한 작업의 정확도 손실을 방지하기 위해 변형이 플러시됩니다.

프로비저닝된 처리량 컨테이너, 공유 처리량 데이터베이스 또는 전체 계정 조합을 복원하도록 선택할 수 있습니다. 복원 작업을 수행하면 모든 데이터 및 해당 인덱스 속성이 새 계정으로 복원됩니다. 복원 프로세스에 따라 계정, 데이터베이스 또는 컨테이너에 복원된 모든 데이터가 지정된 복원 시간까지 일관되도록 보장됩니다. 복원 기간은 복원해야 하는 데이터의 양에 따라 달라집니다. 새로 복원된 데이터베이스 계정의 일관성 설정은 원본 데이터베이스 계정의 일관성 설정과 동일합니다.

참고 항목

지속적인 백업 모드를 사용하면 Azure Cosmos DB 계정을 사용할 수 있는 모든 지역에서 백업이 수행됩니다. 각 지역 계정에 대해 수행되는 백업은 기본적으로 로컬 중복이며, 계정이 해당 지역에서 가용성 영역 기능이 사용하도록 설정된 경우에는 영역 중복입니다. 복원 작업은 항상 데이터를 새 계정으로 복원합니다.

복원되지 않는 것은 무엇인가요?

특정 시점 복원 후에는 다음 구성이 복원되지 않습니다.

  • 공유 처리량 데이터베이스 아래의 컨테이너 하위 집합은 복원할 수 없습니다. 전체 데이터베이스를 전체적으로 복원할 수 있습니다.
  • 방화벽, Virtual Network VNET, 데이터 평면 역할 기반 액세스 제어 RBAC 또는 프라이빗 엔드포인트 설정입니다.
  • 원본 계정의 모든 지역입니다.
  • 저장 프로시저, 트리거 및 UDF.
  • 역할 기반 액세스 제어 할당.

복원이 완료된 후에 이러한 구성을 복원된 계정에 추가할 수 있습니다.

라이브 계정의 복원 가능한 타임스탬프

삭제되지 않은 Azure Cosmos DB 라이브 계정을 복원하려면 항상 컨테이너의 복원 가능한 최신 타임스탬프를 파악하는 것이 좋습니다. 그런 다음, 이 타임스탬프를 사용하여 계정을 최신 버전으로 복원할 수 있습니다.

복원 시나리오

지정 시간 복원 기능은 다음 시나리오를 지원합니다. 시나리오 [1]~[3]은 복원 타임스탬프를 미리 알 수 있는 경우 복원을 트리거하는 방법을 보여 줍니다. 그러나 실수로 인한 삭제 또는 손상의 정확한 시점을 모르는 시나리오가 있을 수 있습니다. 시나리오 [4] 및 [5]는 복원 가능한 데이터베이스 또는 컨테이너에서 새 이벤트 피드 API를 사용하여 복원 타임스탬프를 검색하는 방법을 보여 줍니다.

복원 가능한 계정에 대한 타임스탬프가 포함된 수명 주기 이벤트.

  1. 삭제된 계정 복원 - 복원할 수 있는 모든 삭제된 계정은 복원 창에 표시됩니다. 예를 들어 '계정 A'가 타임스탬프 T3에 삭제되었습니다. 이 경우 T3 직전 타임스탬프, 위치, 대상 계정 이름, 리소스 그룹이면 Azure Portal, PowerShell 또는 CLI에서 복원하는 데 충분합니다.

    복원 가능한 데이터베이스 및 컨테이너에 대한 타임스탬프가 포함된 수명 주기 이벤트.

  2. 특정 지역에 있는 계정의 데이터를 복원 - 예를 들어 '계정 A'가 타임스탬프 T3에 두 지역 '미국 동부' 및 '미국 서부'에 존재합니다. 미국 서부의 계정 A의 복사본이 필요한 경우 Azure Portal, PowerShell 또는 CLI에서 미국 서부를 대상 위치로 사용하여 특정 시점 복원을 수행할 수 있습니다.

  3. 알려진 복원 타임스탬프를 사용하여 컨테이너 내에서 실수로 인 한 쓰기 또는 삭제 작업으로부터 복구 - 예를 들어 '데이터베이스 1' 내의 '컨테이너 1'에서 타임스탬프 T3에 실수로 콘텐츠가 수정된 것을 알았습니다. Azure Portal, PowerShell 또는 CLI에서 타임스탬프 T3의 다른 계정으로 특정 시점 복원을 수행하여 컨테이너를 원하는 상태로 복구할 수 있습니다.

  4. 데이터베이스를 실수로 삭제하기 전 시점으로 계정을 복원 - Azure Portal에서 이벤트 피드 창을 사용하여 데이터베이스가 삭제된 시간을 확인하고 복원 시점을 찾을 수 있습니다. 마찬가지로 Azure CLI 또는 PowerShell을 사용하면 데이터베이스 이벤트 피드를 열거하여 데이터베이스 삭제 이벤트를 검색한 다음 필요한 매개 변수를 사용하여 restore 명령을 트리거할 수 있습니다.

  5. 컨테이너 속성을 실수로 삭제 또는 수정하기 전 시점으로 계정을 복원합니다. - Azure Portal에서 이벤트 피드 창을 사용하여 컨테이너가 생성, 수정 또는 삭제된 시기를 확인하여 복원 시점을 찾을 수 있습니다. 마찬가지로 Azure CLI 또는 PowerShell을 사용하면 컨테이너 이벤트 피드를 열거하여 모든 컨테이너 이벤트를 검색한 다음 필요한 매개 변수를 사용하여 restore 명령을 트리거할 수 있습니다.

사용 권한

Azure Cosmos DB를 사용하면 지속적인 백업 계정에 대한 복원 권한을 특정 역할 또는 보안 주체로 분리하고 제한할 수 있습니다. 자세히 알아보려면 사용 권한 문서를 참조하세요.

가격 책정

연속 30일 백업을 사용하는 Azure Cosmos DB 계정에는 백업을 저장하는 데 월별 추가 요금이 부과됩니다. 30일 및 7일 지속적인 백업 계층 둘 다 데이터 복원 요금이 발생합니다. 복원 비용은 복원 작업을 시작할 때마다 추가됩니다. 지속적인 백업을 사용하여 계정을 구성하지만 데이터를 복원하지 않는 경우에는 백업 스토리지 비용만 청구서에 포함됩니다.

다음 예는 미국 서부에 배포된 Azure Cosmos DB 계정에 대한 가격을 기준으로 합니다. 가격 책정 및 계산은 사용 중인 지역에 따라 다를 수 있습니다. 최신 가격 책정 정보는 Azure Cosmos DB 가격 책정 페이지를 참조하세요.

  • 30일 지속적인 백업 정책을 사용하도록 설정된 모든 계정에는 다음과 같이 계산되는 백업 스토리지에 대한 월별 요금이 청구됩니다.

    $0.20/GB * 계정 내 데이터 크기(GB) * 지역 수

  • 모든 복원 API 호출에는 일회성 요금이 발생합니다. 요금은 복원된 데이터 양에 대한 기능입니다.

    $0.15/GB * 데이터 크기(GB)

예를 들어 두 지역에 1TB의 데이터가 있는 경우

  • 백업 스토리지 비용은 (1000 * 0.20 * 2) = $400/월로 계산됩니다.

  • 복원 비용은 복원당 (1000 * 0.15) = $150로 계산됩니다.

팁

Azure Cosmos DB 계정의 현재 데이터 사용량을 측정하는 방법에 대한 자세한 내용은 Azure Monitor Azure Cosmos DB 인사이트 탐색을 참조하세요. 연속 7일 계층은 데이터 백업에 대한 비용이 발생하지 않습니다.

지속적인 30일 계층과 지속적인 7일 계층의 비교

  • 한 계층의 보존 기간은 30일이고 다른 계층은 7일입니다.
  • 30일 보존 계층은 백업 스토리지에 대해 요금이 청구됩니다. 7일 보존 계층은 요금이 청구되지 않습니다.
  • 복원은 항상 두 계층 중 하나로 청구됩니다.

TTL(Time to Live)

  • 기본 복원 프로세스는 기본적으로 TTL 구성을 포함하여 컨테이너의 모든 속성을 복원하며, 이 경우 TTL을 사용 중지하는 방법 없이 복원을 수행하면 데이터가 삭제될 수 있습니다. 삭제를 방지하려면 복원을 수행하는 동안 PowerShell(-DisableTtl $true) 또는 cli(--disable-ttl True)에서 TTL을 사용하지 않도록 설정하는 매개 변수를 전달하세요.

고객 관리형 키

고객 관리형 키는 지속적인 백업에 어떤 영향을 주나요를 참조하세요.

  • 고객 관리형 키를 지속적인 백업과 함께 사용할 때 Azure Cosmos DB 계정을 구성하는 방법입니다.
  • 고객 관리형 키는 복원에 어떤 영향을 주나요?

현재 제한 사항

현재 특정 시점 복원 기능에는 다음과 같은 제한 사항이 있습니다.

  • SQL, MongoDB, Gremlin 및 Table에 대한 Azure Cosmos DB API로 지속적인 백업이 가능합니다. API for Cassandra는 현재 지원되지 않습니다.

  • Multi region write 계정은 지원되지 않습니다.

  • 지속적인 백업 모드를 사용하는 데이터베이스 계정용 Synapse Link는 GA입니다. Synapse Link 사용 계정에 대한 연속 백업 모드인 반대 상황은 공개 미리 보기 상태입니다. 현재 컨테이너에서 Synapse Link를 사용하지 않도록 설정한 고객은 지속적인 백업으로 마이그레이션할 수 없습니다. 그리고 분석 저장소는 백업에 포함되지 않습니다. 백업 및 분석 저장소에 대한 자세한 내용은 분석 저장소 백업을 참조하세요.

  • 복원된 계정은 원본 계정이 있는 동일한 지역에 만들어집니다. 원본 계정이 존재하지 않는 지역으로 계정을 복원할 수는 없습니다.

  • 복원 기간은 연속 30일 계층의 경우 30일, 연속 7일 계층의 경우 7일입니다. 이러한 계층은 전환할 수 있지만 실제 수량(7 또는 30)은 변경할 수 없습니다. 또한 30일 계층에서 7일 계층으로 전환하는 경우 7일 이후의 일에서 데이터 손실 가능성이 있습니다.

  • 백업은 지리적 재해 방지를 자동으로 수행하지 않습니다. 계정 및 백업의 복원력을 위해 다른 지역을 명시적으로 추가해야 합니다.

  • 복원이 진행 중인 동안 IAM(ID 및 액세스 관리) 정책을 수정하거나 삭제하지 마세요. 이러한 정책은 계정에 VNET, 방화벽 구성을 변경할 수 있는 권한을 부여합니다.

  • 지속적인 백업을 사용하는 Azure Cosmos DB for MongoDB 계정은 기존 컬렉션에 대한 고유 인덱스 만들기를 지원하지 않습니다. 이러한 계정의 경우 관련 컬렉션과 함께 고유 인덱스를 만들어야 합니다. 이 작업은 컬렉션 만들기 확장 명령을 사용하여 수행할 수 있습니다.

  • 복원 후 특정 컬렉션의 경우 일관성 있는 인덱스가 다시 작성될 수 있습니다. IndexTransformationProgress 속성을 통해 다시 빌드 작업의 상태를 확인할 수 있습니다.

  • 지속적인 백업 모드 계정을 만들 때 API for MongoDB의 고유 인덱스를 추가, 업데이트 또는 삭제할 수 없습니다. 계정을 주기적 모드에서 연속 모드로 마이그레이션할 때에도 수정할 수 없습니다.

  • 연속 모드 복원은 복원 시점을 기준으로 유효한 처리량 설정을 복원하지 못할 수 있습니다.

다음 단계