Spanner 백업을 사용하면 필요에 따라 Spanner 데이터베이스 백업을 만들고 이를 복원하여 연산자 및 애플리케이션 오류로 인한 논리적 데이터 손상으로부터 보호할 수 있습니다. 백업은 가용성이 높고 암호화되며, 생성된 시점으로부터 최대 1년까지 보관할 수 있습니다. 백업을 만들 때 백업은 소스 데이터베이스와 동일한 인스턴스, 리전 및 프로젝트에 있습니다. 규정 준수 또는 비즈니스 연속성 이유로 다른 리전 또는 프로젝트의 백업에서 복원해야 하는 경우 별도의 리전 또는 프로젝트의 인스턴스에 백업을 복사할 수 있습니다. 1년 이상 백업을 유지하려면 데이터베이스를 내보내는 것이 좋습니다. 논리적 데이터 손상으로부터 보호하기 위해 Spanner는 point-in-time recovery도 제공합니다. 또한 실수로 인한 데이터베이스 삭제를 방지하기 위해 데이터베이스 삭제 보호를 사용 설정할 수 있습니다.
주요 특징
데이터 일관성: 백업은 백업의
version_time시점에 트랜잭션별 및 external consistency를 갖는 Spanner 데이터베이스 사본입니다.복제: 소스 데이터베이스와 동일한 인스턴스에 있는 백업은 동일한 지리적 위치에서 복제됩니다. 리전별 인스턴스의 경우 백업은 3개의 각 읽기-쓰기 영역에 저장됩니다. 이중 리전 및 멀티 리전 인스턴스의 경우 읽기-쓰기 또는 읽기 전용 복제본을 포함하는 모든 영역에 백업이 저장됩니다. 데이터베이스의 백업을 다른 리전 또는 프로젝트에 저장해야 하는 경우 완료된 백업을 소스 인스턴스에서 다른 리전 또는 프로젝트에 있는 대상 인스턴스로 복사할 수 있습니다. 자세한 내용은 백업 복사를 참조하세요.
자동 만료: 모든 백업에는 자동으로 삭제되는 시점을 결정하는 사용자 지정 만료 날짜가 포함됩니다. Spanner는 만료된 백업을 비동기적으로 삭제합니다. 따라서 백업이 만료되는 시점과 실제로 삭제되는 시점 사이에 지연이 발생할 수 있습니다.
백업 권장 방법
다음 표에서는 몇 가지 백업 전략, 계획을 구현하는 데 권장되는 방법, 제안된 방법의 최대 보관 기간을 설명합니다.
| 백업 전략 | 권장 방법 | 제안된 방법의 최대 보관 기간 |
|---|---|---|
| 데이터베이스 백업을 소스 데이터베이스와 동일한 인스턴스, 리전, 프로젝트에 저장 | 백업 만들기 | 1년 |
| 데이터베이스의 백업을 소스 데이터베이스와 다른 인스턴스, 리전 또는 프로젝트에 저장(리전 간 또는 프로젝트 간 백업) | 백업을 만든 후 다른 리전 또는 프로젝트의 인스턴스로 복사합니다. | 1년 |
| Cloud Storage에 백업 저장 | 데이터베이스를 Cloud Storage 버킷으로 내보냅니다. 백업과 내보내기에 대한 자세한 비교는 백업 및 복원 또는 가져오기 및 내보내기 중에서 선택을 참조하세요. | 무제한(삭제까지 유지) |
| 특정 시점 복구(PITR) | 과거의 특정 시점에서 데이터를 복구하려면 PITR을 선택합니다. 데이터베이스 version_retention_period를 기본 1시간에서 최대 7일로 변경할 수 있습니다. |
7일 |
Identity and Access Management(IAM) 정책으로 액세스 제어
IAM을 사용하면 백업을 포함하는 Spanner 리소스에 대한 액세스를 제어할 수 있습니다. IAM, 역할, 권한을 처음 접하는 경우에는 IAM 개요에서 자세한 내용을 참조하세요.
백업 리소스는 Spanner 리소스 계층 구조에서 인스턴스 아래에 저장됩니다. 프로젝트 수준 또는 인스턴스 수준에서 IAM 정책을 적용하는 것이 좋습니다. 더 세밀한 제어가 필요한 경우 백업 및 데이터베이스 수준에서도 IAM 정책을 적용할 수 있지만, 복잡하기 때문에 권장되지 않습니다. 백업은 IAM 정책과 같은 데이터베이스 메타데이터를 포함하지 않습니다. 따라서 데이터베이스를 복원할 때 데이터베이스는 처음에 해당 상위 인스턴스로부터 정책을 상속 받습니다.
이 섹션에서는 백업 및 복원에 액세스할 수 있는 미리 정의된 역할에 대해 설명합니다.
다음 역할은 특히 백업을 위해 설계되었습니다.
spanner.backupAdmin: 백업 만들기, 보기, 업데이트, 복사, 삭제를 수행할 수 있는 액세스 권한을 갖습니다. 이 역할은 백업의 IAM 정책을 보고 관리할 수도 있습니다. 이 역할은 백업에서 데이터베이스를 복원할 수 없습니다.spanner.backupWriter: 백업 만들기 및 복사 액세스 권한을 갖지만, 이를 업데이트하거나 삭제할 수 없습니다. 이 역할은 백업 만들기를 자동화하는 스크립트에 사용됩니다.
다음 역할도 Spanner 백업에 대한 액세스 권한을 갖습니다.
spanner.admin: 백업에 대한 전체 액세스 권한을 포함합니다. 이 역할에는 모든 Spanner 리소스에 대한 전체 액세스 권한이 포함됩니다.owner: 백업에 대한 전체 액세스 권한을 포함합니다.editor: 백업에 대한 전체 액세스 권한을 포함합니다.viewer: 백업 및 백업 작업을 볼 수 있는 액세스 권한을 포함합니다. 이 역할은 백업을 만들거나, 업데이트, 삭제, 복사할 수 없습니다.
자세한 내용은 Spanner IAM을 참조하세요.
백업 만들기 작동 방법
모든 Spanner 데이터베이스의 백업을 만들 수 있습니다. 이러한 백업은 백업의 version_time 시점에 데이터베이스의 모든 데이터(스키마 및 보조 색인 포함)를 포함한다는 점에서 완전성을 갖습니다. version_time 후 데이터 또는 스키마의 수정 사항은 백업에 포함되지 않습니다. 백업에는 ALTER DATABASE SET OPTIONS 명령어로 설정된 모든 데이터베이스 옵션이 포함되지만 Identity and Access Management(IAM) 정책은 포함되지 않습니다. 백업을 만들 때 백업은 소스 데이터베이스와 동일한 인스턴스, 리전 및 프로젝트에 있습니다.
다음 방법으로 백업을 만들 수 있습니다.
- Google Cloud 콘솔 사용
- Google Cloud CLI 사용
- 클라이언트 라이브러리 사용
- REST 또는 RPC API 사용
백업을 만들 때는 소스 데이터베이스, 백업 리소스 이름, 만료 날짜(백업 만들기 시점으로부터 최대 1년)를 지정해야 합니다. 또한 선택적으로 version_time을 지정하여, 초기 시점에 데이터베이스를 백업할 수 있습니다. version_time 필드는 일반적으로 point-in-time recovery를 사용하여 여러 데이터베이스의 백업을 동기화하거나 데이터를 복구하기 위해 사용됩니다. version_time이 지정되지 않았으면 백업의 create_time으로 설정됩니다. 시스템은 백업 리소스 및 장기 실행 백업 작업을 만들어서 백업 진행 상태를 추적합니다. 새로 생성된 백업은 소스 데이터베이스와 동일한 인스턴스, 리전 및 프로젝트에 있습니다.
백업의 외적 일관성을 보장하기 위해 Spanner는 데이터베이스의 콘텐츠를 create_time에 고정합니다. 이렇게 하면 백업 작업을 진행하는 동안 가비지 컬렉션 시스템이 관련 데이터 값을 삭제하는 것을 방지할 수 있습니다. 그런 후 인스턴스의 모든 읽기/쓰기 및 읽기 전용 영역이 데이터 복사를 병렬로 시작합니다. 영역을 일시적으로 사용할 수 없게 되면 영역이 다시 온라인 상태로 전환되어 완료될 때까지 백업이 완전한 상태가 아닙니다. 작업이 완료되면 즉시 백업을 복원할 수 있습니다. 멀티 리전 인스턴스의 경우 백업이 복원 가능으로 표시되기 전 모든 리전의 모든 읽기/쓰기 및 읽기 전용 영역이 백업 복제본을 완료해야 합니다.
또한 백업에는 데이터베이스의 변경 내역 스키마가 포함되지만 기존 변경 레코드가 포함되지 않습니다. 변경 내역 데이터는 설명되는 변경사항과 거의 동시에 스트리밍되고 소비됩니다. 따라서 Spanner가 이 데이터를 백업에서 제외합니다.
백업 복사 작동 방법
Spanner 백업 및 복원을 사용하면 Spanner 데이터베이스 백업을 한 인스턴스에서 다른 리전 또는 프로젝트의 다른 인스턴스로 복사하여 추가 데이터 보호 및 규정 준수 기능을 제공할 수 있습니다. 복사된 백업에는 원본 백업과 동일한 주요 기능이 있습니다. 또한 교차 리전 및 교차 프로젝트 백업과 복원 사용 사례를 지원하기 위해 복사된 백업과 동일한 인스턴스에서 복사된 백업을 restore할 수 있습니다.
일반적인 교차 리전 사용 사례
백업 복사를 위한 몇 가지 일반적인 리전 간 사용 사례는 다음과 같습니다.
규정 준수 및 규제 요건을 위해 다른 리전에서 백업을 유지합니다.
예를 들어 규정 준수 요구사항을 충족하기 위해 프로덕션 데이터에서 최소 거리에 있는 리전의 인스턴스에 데이터베이스 백업을 복사할 수 있습니다.
재해 복구 및 비즈니스 연속성을 위해 별도의 리전에 백업을 유지합니다.
예를 들어 0이 아닌 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)를 사용하여 재해 복구 목적으로 백업 데이터베이스를 대상 인스턴스에 복사할 수 있습니다. 그런 후 필요한 경우 대상 인스턴스의 복사된 백업에서 데이터베이스를 복원할 수 있습니다. (애플리케이션에 0-RTO 및 0-RPO 요구사항이 있는 경우 재해 복구 계획에 대한 Spanner 멀티 리전 구성을 사용하는 것이 좋습니다.)
일반적인 교차 프로젝트 사용 사례
백업 복사를 위한 일반적인 프로젝트 간 사용 사례는 다음과 같습니다.
- 운영, 보안, 규정 준수 요구사항을 충족하기 위해 개별 프로젝트에서 백업 사본을 유지보수합니다.
개발, 테스트, 프로덕션 프로젝트 간에 데이터를 복사하고 이동합니다.
예를 들어 프로덕션 프로젝트에서 테스트 프로젝트로 데이터를 이동하려면 프로덕션 데이터의 백업을 만든 후 백업을 테스트 프로젝트에 복사합니다. 복사 작업이 완료되면 테스트 프로젝트의 인스턴스에 복사된 백업을 복원할 수 있습니다.
한 프로젝트에서 다른 프로젝트로 데이터베이스를 이동합니다(마이그레이션 중에 다운타임이 발생할 수 있음).
소스 백업 생성 시간에서 최대 1년까지 소스 백업, 대상 백업 및 만료 날짜를 지정하여 다른 지역 또는 프로젝트의 대상 인스턴스에 백업을 복사할 수 있습니다. 즉, expiration_date 값은 현재 복사 요청이 처리된 후 최소 6시간, 소스 백업 create_time 이후 최대 366일이어야 합니다.
백업 복사 요청을 시작할 때 Spanner는 백업 리소스 및 장기 실행 백업 작업을 만들어 백업 진행 상태를 추적합니다. 백업이 대상 인스턴스의 모든 읽기-쓰기 및 읽기 전용 영역에 복사됩니다. 영역이 일시적으로 사용할 수 없게 되면 해당 영역이 다시 온라인으로 전환되기 전까지 백업 복사가 완료되지 않습니다. 복사 중에는 대상 인스턴스를 삭제할 수 없습니다. 백업 복사 작업의 진행률과 완료 상태를 추적하려면 백업 진행률 표시의 단계를 따르세요.
복사가 완료된 후 더 이상 필요하지 않은 경우 소스 백업을 삭제할 수 있습니다. 복사가 완료되면 복사된 백업과 함께 GetBackup, UpdateBackup, DeleteBackup과 같은 작업을 사용할 수 있습니다.
백업 복사 시작 단계 기본 요건
다른 리전 또는 프로젝트의 인스턴스에 백업을 복사하는 경우 대상 인스턴스를 먼저 설정하고 구성해야 합니다. 대상 인스턴스는 백업 사본이 저장되는 인스턴스입니다. 최소 100개의 처리 단위로 구성될 수 있으며, 소스 인스턴스(소스 백업이 있는 인스턴스)와 동일한 인스턴스 구성이 필요하지 않습니다. 복원하기 전에 대상 인스턴스에 노드당 10TB 스토리지 한도에 따라 데이터베이스 크기를 지원할 수 있는 충분한 노드 또는 처리 장치가 프로비저닝되었는지 확인합니다(즉, 20TB를 복원하려면 2개 이상의 노드가 필요함). 새 대상 인스턴스를 만들려면 인스턴스 만들기 및 관리를 참조하세요.
추가 고려사항
추가 고려 사항에는 다음이 포함됩니다.
- 소스 인스턴스에서 대상 인스턴스로 백업을 복사할 때 복사된 백업은 소스 백업과 독립적으로 존재합니다. 복사 작업이 완료되면 소스 인스턴스에 백업 1개가 있고 대상 인스턴스에 백업 1개가 있습니다. 소스 인스턴스에서 더 이상 백업이 필요하지 않으면 삭제할 수 있습니다.
- 백업을 리전 인스턴스에 복사하면 백업 데이터가 대상 인스턴스의 세 가지 읽기-쓰기 영역 각각에 복사됩니다.
- 멀티 리전 인스턴스에 백업을 복사할 때는 인스턴스에서 읽기-쓰기 또는 읽기 전용 복제본이 있는 각 영역에 백업 데이터가 복사됩니다.
- 여러 백업을 동시에 복사할 수 있습니다.
- 복사 프로세스가 진행되는 동안 대상 백업을 업데이트하거나 삭제할 수 있습니다. 대상 백업을 삭제하면 그 결과로 진행 중인 복사 작업이 취소됩니다.
- 복사 작업이 진행되는 동안 소스 인스턴스에서 백업을 복원할 수 있습니다.
- 복사 작업은 완료되기 전에 취소할 수 있습니다.
다음 작업은 복사 프로세스 중에 허용되지 않습니다.
- 복사 작업이 진행되는 동안 소스 백업을 삭제할 수 없습니다.
- 복사가 진행되는 동안에는 대상 복사된 백업에 대해 새 복사 또는 복원을 시작할 수 없습니다. 복사가 완료되었으면 다시 복사하거나 복원할 수 있습니다.
Spanner 백업 저장 위치
백업은 Spanner에서 리소스입니다.
각 백업 리소스는 리소스 계층 구조에서 해당 소스 데이터베이스와 동일한 인스턴스에 저장되며 projects/<project>/instances/<instance>/backups/<backup> 형식의 리소스 경로를 갖습니다.
백업은 해당 소스 데이터베이스가 삭제된 다음에도 계속 존재하지만 상위 인스턴스보다 오래 지속될 수 없습니다. 백업이 실수로 삭제되는 것을 방지하기 위해 백업이 있는 경우 Spanner 인스턴스를 삭제할 수 없습니다. 인스턴스를 삭제하려면 백업 및 인스턴스를 삭제하기 전에 해당 백업을 복원한 다음 복원된 데이터베이스를 내보내는 것이 좋습니다.
암호화
데이터베이스와 마찬가지로 Spanner 백업은 Google 관리 또는 고객 관리(CMEK) 암호화로 암호화됩니다. 기본적으로 백업은 해당 데이터베이스와 동일한 암호화 구성을 사용하지만, 백업을 만들 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 백업에 CMEK가 사용 설정되었으면 백업을 만들 때 KMS 키의 기본 버전을 사용하여 암호화됩니다. 백업을 만든 후에는 KMS 키가 순환되어도 해당 키 및 키 버전을 수정할 수 없습니다. 자세한 내용은 CMEK 사용 백업 만들기를 참조하세요.
기본적으로 복사된 백업은 Google 관리나 고객 관리(CMEK)인 경우 소스 백업 암호화와 동일한 암호화 구성을 사용합니다. 백업을 복사할 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 리전 간에 복사할 때 복사된 백업을 CMEK로 암호화하려면 대상 리전에 해당하는 KMS 키를 지정합니다.
성능
이 섹션에서는 Spanner에서 최적의 백업 성능에 대해 설명합니다.
백업 시 성능
백업을 수행할 때 Spanner는 데이터베이스에서 백업 스토리지로 직접 데이터를 복사하는 백업 작업을 만들고 데이터베이스 크기에 따라 해당 작업의 크기를 조정합니다. 이 백업 작업은 데이터베이스 인스턴스에 할당된 CPU 리소스를 사용하지 않으므로 인스턴스 성능에 영향을 미치지 않습니다. 또한 데이터베이스 인스턴스의 컴퓨팅 부하는 백업 작업 속도에 영향을 미치지 않습니다. 백업 작업의 진행률과 완료를 추적하려면 백업 진행률 표시를 참조하세요.
일반적으로 대부분의 백업은 1~4시간 정도 걸립니다. 일부 백업은 크기 또는 내부 리소스 큐로 인해 더 오래 걸릴 수 있습니다. 다른 요인이 변경되지 않았을 때 백업이 평소보다 오래 걸리는 경우 영역에서 백업 작업 예약이 지연되었기 때문일 수 있습니다. 이 과정에는 최대 30분이 소요될 수 있습니다. 백업을 취소하고 다시 시작하지 않는 것이 좋습니다. 새로운 백업 작업에 동일한 예약 지연이 발생할 수 있습니다.
백업 복사 시 성능
백업을 복사하는 데 걸리는 시간은 복사한 백업에 대해 선택한 소스 백업 및 대상 리전의 크기와 같은 요소에 따라 달라집니다. 일반적으로 대부분의 복사는 1~4시간 안에 완료됩니다. 일부 사본은 백업 크기와 대상 리전에 따라 더 오래 걸릴 수 있습니다. 백업을 복사해도 소스 인스턴스 또는 데이터베이스에 대한 성능 영향이 없습니다. 성능에 영향을 주지 않고 다른 리전의 인스턴스에 소스 백업의 여러 복사본을 동시에 만들 수 있습니다.
가격 책정
백업에 사용되는 단위 시간별 스토리지 사용량을 기준으로 청구됩니다. 청구는 백업 작업이 완료된 다음부터 시작되며 백업이 삭제되기 전까지 계속됩니다. 완료된 백업은 최소 24시간 단위로 청구됩니다. 백업을 만들고 나서 완료 후 1분만에 삭제하더라도 24시간에 대한 비용이 청구됩니다.
백업 사본에는 원래 백업과 동일한 스토리지 비용이 적용됩니다. 서로 다른 리전을 사용하는 두 인스턴스 간에 복사본을 만드는 경우 아웃바운드 데이터 전송 비용이 적용됩니다.
예를 들어 데이터베이스를 소스 멀티 리전 인스턴스 구성 nam7에서 대상 멀티 리전 인스턴스 구성 nam-eur-asia3로 복사할 경우 다음 요금이 적용됩니다.
us-central1리전 중복에 요금이 부과되지 않음us-central2리전에 요금이 부과되지 않음- 대륙 간 데이터 전송 요금은 신 대륙(유럽 및 아시아)마다 한 번씩 두 번 적용됩니다.
- 동일한 대륙 내 리전 간 데이터 전송 요금은
us-east1에 한 번만 적용됩니다. - 동일한 대륙 내 리전 간 데이터 전송 요금은 유럽에서 한 번 적용됩니다.
Spanner는 교차 리전 전송 수를 최소화하기 위해 복사 프로세스를 최적화합니다. 이렇게 하면 빠른 복사 백업 경험을 제공하면서도 데이터 전송 비용을 최소화할 수 있습니다.
백업은 개별적으로 저장되고 청구됩니다. 백업 스토리지는 데이터베이스 스토리지 청구 또는 데이터베이스 스토리지 한도에 영향을 주지 않습니다. 자세한 내용은 스토리지 사용량 측정항목도 참조하세요.
백업 비용에 대한 자세한 내용은 Spanner 가격 책정을 참조하세요.
다음 단계
백업 및 복원 또는 가져오기 및 내보내기 중 선택에 대해 알아보기
백업을 만들려면 백업 만들기 참조하기
백업을 관리하려면 백업 관리 참조하기