백업 및 복원

개요

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

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

주요 기능

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

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

  • 자동 만료: 모든 백업에는 자동으로 삭제되는 시점을 결정하는 사용자 지정 만료 날짜가 포함됩니다.

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

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

백업 및 복원가져오기 및 내보내기
데이터 일관성 백업 및 내보낸 데이터베이스 모두 transactional consistency 및 external consistency를 갖습니다.
성능 영향 둘 다 데이터베이스 성능에 대한 영향을 최소화하기 위해 낮은 우선순위로 실행됩니다. 내보내기에는 low-priority-user CPU가 사용되고 백업에는 low-priority-system CPU가 사용됩니다. 자세한 내용은 태스크 우선순위를 참조하세요.
스토리지 형식 빠른 복원을 위해 디자인된 고유 암호화 형식이 사용됩니다. CSV 및 Avro 파일 형식이 모두 지원됩니다.
이동성 백업이 소스 데이터베이스와 동일한 인스턴스에 저장되고 이동할 수 없습니다.

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

백업 작동 방식

콘텐츠

사용자는 모든 Cloud Spanner 데이터베이스의 백업을 만들 수 있습니다. 이러한 백업은 백업의 create_time 시점에 데이터베이스의 모든 데이터(스키마 및 보조 색인 포함)를 포함한다는 점에서 완전성을 갖습니다. 백업 만들기가 시작된 다음의 데이터 또는 스키마 수정 사항은 백업에 포함되지 않습니다. 백업에는 ID 및 액세스 관리(IAM) 정책과 같은 데이터베이스 메타데이터가 포함되지 않습니다.

만들기 과정

백업을 만들 때는 소스 데이터베이스, 백업 리소스 이름, 만료 날짜(백업 만들기 시점으로부터 최대 1년)를 지정해야 합니다. 시스템은 백업 리소스 및 장기 실행 백업 작업을 만들어서 백업 진행 상태를 추적합니다.

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

리소스 계층 구조

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

백업 시간 및 성능

백업을 만드는 데 걸리는 시간은 여러 요소에 따라 달라지지만, 주로 데이터베이스 크기노드 수에 따라 결정됩니다. 더 빠른 백업 시간이 필요한 경우 노드 수를 늘릴 수 있지만 노드 수 변경이 후속 백업에 영향을 준다는 것에 주의해야 합니다.

또한 백업 만들기에는 유휴 CPU가 사용됩니다. 따라서 CPU 사용량이 권장 가이드라인 내에 있는지 확인합니다. CPU에 과부하를 주면 백업 시간이 매우 길어지고 데이터베이스 대기 시간에 부정적인 영향을 줄 수도 있습니다.

한 인스턴스의 CPU는 해당 인스턴스에서 진행되는 모든 백업에 공유됩니다. 동시에 동일한 인스턴스에서 서로 다른 데이터베이스의 백업을 만들면 백업 시간이 오래 걸릴 수 있습니다.

복원 작동 방법

복원할 때는 소스 백업과 새로운 대상 데이터베이스를 지정해야 합니다. 기존 데이터베이스로는 복원할 수 없습니다. 새 데이터베이스는 백업과 동일한 프로젝트에 있어야 하며, 백업과 동일한 인스턴스 구성의 인스턴스에 있어야 합니다. 예를 들어 백업이 us-west3로 구성된 인스턴스에 있으면 또한 us-west3로 구성된 프로젝트의 모든 인스턴스로 복원될 수 있습니다. 인스턴스의 노드 수는 동일할 필요가 없습니다. 복원된 데이터베이스는 백업의 create_time 시점에 원본 데이터베이스의 모든 데이터 및 스키마를 갖습니다. 복원된 데이터베이스를 포함하는 인스턴스에서 상속되는 권한을 제외하고 어떠한 IAM 권한도 포함하지 않으며, 사용자가 복원 완료 후 적절한 IAM 권한을 적용해야 합니다. 해당 인스턴스의 리전 및 영역의 다수 쿼럼을 사용할 수 있는 한 데이터베이스를 복원할 수 있도록 복원 프로세스가 고가용성으로 디자인됩니다.

두 작업으로 추적되는 3개의 States 사이의 복원된 데이터베이스 전환을 이해하는 것이 중요합니다.

  • CREATING 상태: 복원을 시작하면 시스템이 RestoreDatabaseMetadata로 새 데이터베이스 및 장기 실행 데이터베이스 작업을 만들어 복원 진행 상태를 추적합니다. 새 데이터베이스가 시작되고 CREATING 상태로 유지됩니다. 즉, 복원 작업이 완료될 때까지 사용할 준비가 되지 않습니다. 빠른 복원 시간(일반적으로 10분 미만)을 위해 복원 작업은 파일을 데이터베이스로 복사하지 않고 백업에서 파일을 마운트하여 수행됩니다.

  • READY_OPTIMIZING 상태: 복원 작업이 완료되면 데이터베이스가 READY_OPTIMIZING 상태로 전환됩니다. 이 상태에서는 사용할 준비가 되지만, 데이터베이스가 백업으로부터 데이터를 읽는 동안 읽기 대기 시간이 약간 높아질 수 있습니다. 데이터베이스 복원 또는 최적화를 위해 백업을 사용 중인 상태에서 백업을 삭제하려고 시도하면 실패합니다.

    복원 작업이 완료되면 최적화 진행 상태를 추적하기 위해 또 OptimizeRestoredDatabaseMetadata로 다른 장기 실행 데이터베이스 작업이 수행됩니다. 최적화 작업은 백업에서 데이터베이스로 데이터를 복사합니다. 최적화 프로세스 속도를 높이려면 인스턴스에 노드를 더 추가할 수 있습니다.

  • READY 상태: 최적화가 완료되면 데이터베이스가 READY 상태로 전환됩니다. 이 시점에서는 복원된 데이터베이스가 완전히 작동하며 더 이상 백업을 참조하지 않습니다.

인스턴스에는 복원 CREATING 상태의 데이터베이스가 최대 한 개 있을 수 있습니다. 복원된 데이터베이스가 READY_OPTIMIZING 또는 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을 참조하세요.