백업 및 복원

개요

Cloud Spanner 백업 및 복원을 사용하면 필요에 따라 Cloud Spanner 데이터베이스 백업을 만들고 이를 복원하여 작업자 및 애플리케이션 오류로 인한 논리적 데이터 손상으로부터 보호할 수 있습니다. 백업은 가용성이 높고 암호화되며, 생성된 시점으로부터 최대 1년까지 보관할 수 있습니다. 더 긴 보관 기간이 필요한 경우에는 데이터베이스 내보내기를 하는 것이 좋습니다.

백업 및 복원은 다음 방식으로 사용할 수 있습니다.

논리적 데이터 손상의 경우 Cloud Spanner는 point-in-time recovery도 제공합니다.

주요 특징

  • 데이터 일관성: 백업은 백업의 version_time 시점에 트랜잭션별 및 external consistency를 갖는 Cloud Spanner 데이터베이스 사본입니다.

  • 복제: 소스 데이터베이스와 동일한 인스턴스에 있는 백업은 동일한 지리적 위치에서 복제됩니다. 리전별 인스턴스의 경우 백업 사본이 3개의 각 읽기-쓰기 영역에 저장됩니다. 멀티 리전별 인스턴스의 경우 읽기-쓰기 또는 읽기 전용 복제본을 포함하는 모든 영역에 사본이 저장됩니다.

  • 자동 만료: 모든 백업에는 자동으로 삭제되는 시점을 결정하는 사용자 지정 만료 날짜가 포함됩니다. Cloud Spanner는 만료된 백업을 비동기적으로 삭제합니다. 따라서 백업이 만료되는 시점과 실제로 삭제되는 시점 사이에 지연이 발생할 수 있습니다.

백업 및 복원 또는 가져오기 또는 내보내기 중에서 선택

Cloud Spanner 가져오기내보내기는 백업 및 복원과 비슷한 사용 사례를 제공합니다. 다음 표에서는 올바른 항목을 결정할 수 있도록 이들 사이의 유사점과 차이점을 설명합니다.

백업 및 복원가져오기 및 내보내기
데이터 일관성 백업 및 내보낸 데이터베이스 모두 transactional consistency 및 external consistency를 갖습니다.
성능 영향 백업은 인스턴스 성능에 영향을 미치지 않습니다. Cloud Spanner는 인스턴스의 서버 리소스를 사용하지 않는 전용 작업을 사용하여 백업을 수행합니다. 내보내기는 데이터베이스 성능에 미치는 영향을 최소화하기 위해 중간 우선순위 작업으로 실행됩니다. 자세한 내용은 태스크 우선순위를 참조하세요.
스토리지 형식 빠른 복원을 위해 디자인된 고유 암호화 형식이 사용됩니다. CSV 및 Avro 파일 형식이 모두 지원됩니다.
이동성 백업이 소스 데이터베이스와 동일한 인스턴스에 저장되고 이동할 수 없습니다.

백업과 동일한 인스턴스 구성을 갖는 프로젝트의 모든 인스턴스로 데이터베이스를 복원할 수 있습니다.
내보낸 데이터베이스가 Google Cloud Storage에 저장되고, CSV 또는 Avro를 지원하는 시스템으로 데이터를 마이그레이션할 수 있습니다.
보관 백업은 최대 1년까지 보관할 수 있습니다. 내보낸 데이터베이스는 Cloud Storage에 저장되며, 기본적으로 삭제되기 전까지 계속 보관됩니다. 수명 주기보관 정책을 맞춤설정할 수 있습니다.
청구 백업은 단위 시간별로 사용된 스토리지를 기준으로 Cloud Spanner 프로젝트에 청구됩니다. 자세한 내용은 청구 섹션을 참조하세요. 가져오기 및 내보내기에 대한 청구는 Google Cloud StorageDataflow가 사용되기 때문에 더 복잡합니다. 자세한 내용은 데이터베이스 내보내기 및 가져오기 가격 책정을 참조하세요.
복원 시간 복원은 복원 및 최적화의 두 작업으로 수행됩니다. 데이터 복사 없이 데이터베이스가 백업을 직접 마운트하기 때문에 복원 작업은 빠른 첫 바이트 소요 시간을 제공합니다. 최적화하는 동안 읽기 대기 시간이 약간 더 높을 수 있지만 복원 작업이 완료된 다음에는 데이터베이스를 사용할 준비가 됩니다. 자세한 내용은 복원 작동 방법을 참조하세요. 가져오기는 속도가 더 느립니다. 모든 데이터가 데이터베이스에 기록될 때까지 기다려야 합니다.

백업 작동 방식

콘텐츠

사용자는 모든 Cloud Spanner 데이터베이스의 백업을 만들 수 있습니다. 이러한 백업은 백업의 version_time 시점에 데이터베이스의 모든 데이터(스키마 및 보조 색인 포함)를 포함한다는 점에서 완전성을 갖습니다. version_time 후 데이터 또는 스키마의 수정 사항은 백업에 포함되지 않습니다.

백업에는 ALTER DATABASE SET OPTIONS 명령어로 설정된 모든 데이터베이스 옵션이 포함되지만 Identity and Access Management(IAM) 정책은 포함되지 않습니다.

또한 백업에는 데이터베이스의 변경 스트림의 스키마가 포함되지만 기존 변경 레코드는 포함되지 않습니다. 변경 스트림 데이터는 설명된 변경사항과 거의 동시에 스트리밍하고 소비하기 위한 것입니다. 따라서 Spanner는 이 데이터를 백업에서 제외합니다.

암호화

데이터베이스와 마찬가지로 Cloud Spanner 백업은 Google 관리 또는 고객 관리(CMEK) 암호화로 암호화됩니다. 기본적으로 백업은 해당 데이터베이스와 동일한 암호화 구성을 사용하지만, 백업을 만들 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 백업에 CMEK가 사용 설정되었으면 백업을 만들 때 KMS 키의 기본 버전을 사용하여 암호화됩니다. 백업을 만든 후에는 KMS 키가 순환되어도 해당 키 및 키 버전을 수정할 수 없습니다. 자세한 내용은 CMEK 사용 백업 만들기를 참조하세요.

만들기 과정

백업을 만들 때는 소스 데이터베이스, 백업 리소스 이름, 만료 날짜(백업 만들기 시점으로부터 최대 1년)를 지정해야 합니다. 또한 선택적으로 version_time을 지정하여, 초기 시점에 데이터베이스를 백업할 수 있습니다. version_time 필드는 일반적으로 point-in-time recovery를 사용하여 여러 데이터베이스의 백업을 동기화하거나 데이터를 복구하기 위해 사용됩니다. version_time이 지정되지 않았으면 백업의 create_time으로 설정됩니다. 시스템은 백업 리소스 및 장기 실행 백업 작업을 만들어서 백업 진행 상태를 추적합니다.

백업의 external consistency를 보장하기 위해 Cloud Spanner는 만들기 시점에 데이터베이스의 콘텐츠를 고정시킵니다. 이렇게 하면 백업 작업을 진행하는 동안 가비지 컬렉션 시스템이 관련 데이터 값을 삭제하는 것을 방지할 수 있습니다. 그런 후 인스턴스의 모든 읽기/쓰기 및 읽기 전용 영역이 데이터 복사를 병렬로 시작합니다. 어떤 영역을 일시적으로 사용할 수 없게 되면 영역이 다시 온라인 상태로 전환되어 완료될 때까지 백업이 완전한 상태가 아닙니다. 작업이 완료되면 즉시 백업을 복원할 수 있습니다. 멀티 리전 인스턴스의 경우 모든 리전의 모든 읽기/쓰기 및 읽기 전용 영역에서 백업 복제본을 완료해야 백업이 복원 가능으로 표시됩니다.

리소스 계층 구조

백업은 Cloud Spanner에서 리소스입니다. 각 백업 리소스리소스 계층 구조에서 해당 소스 데이터베이스와 동일한 인스턴스에 저장되며 projects/<project>/instances/<instance>/backups/<backup> 형식의 리소스 경로를 갖습니다. 백업은 해당 소스 데이터베이스가 삭제된 다음에도 계속 존재하지만 상위 인스턴스보다 오래 지속될 수 없습니다. 백업이 실수로 삭제되는 것을 방지하기 위해 백업이 있는 경우 Cloud Spanner 인스턴스를 삭제할 수 없습니다. 인스턴스를 삭제하려는 경우에는 백업을 복원하고 복원된 데이터베이스 내보내기를 수행한 후에 백업과 인스턴스를 삭제하는 것이 좋습니다.

백업 시간 및 성능

백업을 수행할 때 Cloud Spanner는 데이터베이스에서 백업 스토리지로 직접 데이터를 복사하는 백업 작업을 만들고 데이터베이스 크기에 따라 해당 작업의 크기를 조정합니다. 이 백업 작업은 데이터베이스 인스턴스에 할당된 CPU 리소스를 사용하지 않으므로 인스턴스 성능에 영향을 미치지 않습니다. 또한 데이터베이스 인스턴스의 컴퓨팅 부하는 백업 작업 속도에 영향을 미치지 않습니다.

백업 작업의 진행률과 완료를 추적하려면 백업 진행률 표시를 참조하세요.

다른 요인이 변경되지 않았을 때 백업이 평소보다 오래 걸리는 경우 영역에서 백업 작업 예약이 지연되었기 때문일 수 있습니다. 이 과정에는 최대 30분이 소요될 수 있습니다. 백업을 취소하고 다시 시작하지 않는 것이 좋습니다. 새로운 백업에도 동일한 예약 지연이 발생할 수 있습니다.

복원 작동 방법

Cloud Spanner 데이터베이스를 복원할 때는 소스 백업과 새로운 대상 데이터베이스를 지정해야 합니다. 기존 데이터베이스로는 복원할 수 없습니다. 새 데이터베이스는 백업과 동일한 프로젝트에 있어야 하며, 백업과 동일한 인스턴스 구성의 인스턴스에 있어야 합니다. 예를 들어 백업이 us-west3로 구성된 인스턴스에 있으면 또한 us-west3로 구성된 프로젝트의 모든 인스턴스로 복원될 수 있습니다. 인스턴스의 컴퓨팅 용량은 동일할 필요가 없습니다.

복원된 데이터베이스는 ALTER DATABASE SET OPTIONS 명령어로 설정된 모든 데이터베이스 옵션을 포함하여 백업의 create_time 시점에 원본 데이터베이스의 모든 데이터 및 스키마와 모든 변경 스트림 구성을 갖습니다. 복원된 데이터베이스를 포함하는 인스턴스에서 상속되는 권한을 제외하고 어떠한 IAM 권한도 포함하지 않으며, 사용자가 복원 완료 후 적절한 IAM 권한을 적용해야 합니다. 변경 스트림의 내부 데이터는 포함되지 않습니다.

복원 프로세스는 고가용성을 위해 고안되었습니다. 인스턴스의 리전 및 영역의 다수 쿼럼을 사용할 수 있는 경우 데이터베이스를 복원할 수 있습니다.

CMEK 사용 백업을 복원하려면 키 및 키 버전을 모두 Cloud Spanner에 사용할 수 있어야 합니다. 기본적으로 복원된 데이터베이스에는 백업과 동일한 암호화 구성이 사용됩니다. 데이터베이스를 복원할 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 자세한 내용은 CMEK 사용 백업에서 복원을 참조하세요.

복원된 데이터베이스는 3개의 상태를 통해 전환되며. 이는 2개의 장기 실행 작업으로 추적할 수 있습니다.

  • CREATING: Cloud Spanner는 새 데이터베이스를 만들고 백업에서 파일을 마운트하여 복원을 시작합니다. 이는 대개 10분 이내에 완료됩니다. 이 초기 CREATING 상태에서는 복원된 데이터베이스를 아직 사용할 준비가 되지 않습니다.

    이 상태의 진행 상황을 추적하려면 이 프로세스 중에 Cloud Spanner가 제공하는 장기 실행 복원 작업을 쿼리하면 됩니다. 쿼리는 RestoreDatabaseMetadata 객체를 반환합니다.

    CREATING 상태와 관련된 다음 주의사항에 유의하세요.

    • 다른 인스턴스로 복원하는 경우, 복원 작업은 백업이 포함된 인스턴스가 아니라 복원된 데이터베이스가 포함된 인스턴스에 속합니다.
    • Cloud Spanner는 백업을 복원하는 동안 백업을 삭제할 수 없습니다. 복원이 완료되고 데이터베이스가 READY 상태가 된 후에 삭제할 수 있습니다.
    • 백업에서 복원으로 인해 인스턴스는 CREATING 상태의 데이터베이스를 최대 한 개만 가질 수 있습니다. 아래에 설명된 것처럼, 복원된 데이터베이스가 READY_OPTIMIZING 또는 READY 상태로 전환될 때까지는 인스턴스에 다른 백업을 복원할 수 없습니다.
  • READY_OPTIMIZING: Cloud Spanner가 백업을 마운트한 후 저장된 크기를 최적화하면서 백업 데이터를 새 데이터베이스에 복사하기 시작합니다. 이 프로세스 중에 데이터베이스를 사용할 수 있습니다. 관련 데이터 양에 따라 복원 단계를 완료하는 데 며칠이 걸릴 수 있습니다.

    READY_OPTIMIZING 중에 데이터베이스를 일반적으로 사용할 수 있지만 다음 사항에 주의해야 합니다.

    • 읽기 지연 시간이 일반적인 시간보다 약간 길 수 있습니다.
    • 스토리지 측정항목에는 백업이 아닌 새 데이터베이스의 크기가 표시됩니다. 따라서 데이터 전송이 진행 중일 때 Cloud Spanner 스토리지 측정항목에는 모든 데이터의 전체 크기를 반영하지 않는 결과가 표시될 수 있습니다.
    • CREATING 상태와 마찬가지로 Cloud Spanner는 마운트된 백업을 삭제할 수 없습니다.

    Cloud Spanner는 이 상태 동안 또 다른 장기 실행 복원 작업을 사용할 수 있으며, 이번에는 OptimizeRestoredDatabaseMetadata 메타데이터 객체를 반환합니다.

  • READY: 복사 및 최적화 작업이 완료되면 데이터베이스가 READY 상태로 전환됩니다. 데이터베이스가 완전히 복원되었으며 더 이상 백업을 참조하거나 필요로 하지 않습니다.

청구

백업에 사용되는 단위 시간별 스토리지 사용량을 기준으로 청구됩니다. 청구는 백업 작업이 완료된 다음부터 시작되며 백업이 삭제되기 전까지 계속됩니다. 백업에서 복원할 때는 요금이 부과되지 않습니다.

백업은 개별적으로 저장되고 청구됩니다. 백업 스토리지는 데이터베이스 스토리지 청구 또는 데이터베이스 스토리지 한도에 영향을 주지 않습니다.

완료된 백업은 최소 24시간 단위로 청구됩니다. 백업을 만들고 나서 완료 후 1분만에 삭제하더라도 24시간에 대한 비용이 청구됩니다.

백업 비용에 대한 자세한 내용은 Cloud Spanner 가격 책정 페이지를 참조하세요.

IAM으로 액세스 제어

IAM을 사용하면 백업 및 복원된 데이터베이스를 포함하는 Cloud Spanner 리소스에 대한 액세스를 제어할 수 있습니다. IAM, 역할, 권한을 처음 접하는 경우에는 IAM 개요에서 자세한 내용을 참조하세요.

백업 리소스는 Cloud Spanner 리소스 계층 구조에서 인스턴스 아래에 저장됩니다. 프로젝트 수준 또는 인스턴스 수준에서 IAM 정책을 적용하는 것이 좋습니다. 더 세밀한 제어가 필요한 경우 백업 및 데이터베이스 수준에서도 IAM 정책을 적용할 수 있지만, 복잡하기 때문에 권장되지 않습니다. 백업은 IAM 정책과 같은 데이터베이스 메타데이터를 포함하지 않습니다. 따라서 데이터베이스를 복원할 때 데이터베이스는 처음에 해당 상위 인스턴스로부터 정책을 상속 받습니다.

이 섹션에서는 백업 및 복원에 액세스할 수 있는 미리 정의된 역할에 대해 설명합니다.

다음 역할은 특별히 백업 및 복원을 위해 디자인되었습니다.

  • spanner.backupAdmin: 백업 만들기, 보기, 업데이트, 삭제를 위한 액세스 권한을 갖습니다. 이 역할은 백업의 IAM 정책을 보고 관리할 수도 있습니다. 이 역할은 백업에서 데이터베이스를 복원할 수 없습니다.
  • spanner.restoreAdmin: 백업에서 데이터베이스를 복원하기 위한 액세스 권한을 갖습니다. 백업을 다른 인스턴스로 복원해야 하는 경우 프로젝트 수준에서 또는 두 인스턴스 모두에 이 역할을 적용합니다. 이 역할은 백업을 만들 수 없습니다.
  • spanner.backupWriter: 백업 만들기를 위한 액세스 권한을 갖지만, 이를 업데이트하거나 삭제할 수 없습니다. 이 역할은 백업 만들기를 자동화하는 스크립트에 사용하기 위한 용도입니다.

다음 역할도 백업 및 복원을 위한 액세스 권한을 갖습니다.

  • spanner.admin: 백업 및 복원에 대한 전체 액세스 권한을 갖습니다. 이 역할에는 모든 Cloud Spanner 리소스에 대한 전체 액세스 권한이 포함됩니다.
  • owner: 백업 및 복원에 대한 전체 액세스 권한을 갖습니다.
  • editor: 백업 및 복원에 대한 전체 액세스 권한을 갖습니다.
  • viewer: 백업, 백업 작업, 복원 작업 보기를 위한 액세스 권한을 갖습니다. 이 역할은 백업을 만들거나, 업데이트, 삭제, 복원할 수 없습니다.

자세한 내용은 Cloud Spanner IAM을 참조하세요.