이 문서에서는 Spanner 백업 및 백업 일정에 대해 간략하게 설명합니다.
Spanner를 사용하면 필요에 따라 데이터베이스의 전체 백업을 만들고 백업 일정을 사용하여 전체 또는 증분 백업을 만들 수 있습니다. 전체 백업은 데이터베이스의 전체 데이터를 저장하는 반면 증분 백업은 이전 백업 이후 변경된 데이터만 포함합니다.
연산자 또는 애플리케이션 오류로 인해 논리적 데이터가 손상된 경우 백업을 복원할 수 있습니다.
백업은 가용성이 높고 암호화되며, 생성된 시점으로부터 최대 1년까지 보관할 수 있습니다. 백업을 만들 때 백업은 소스 데이터베이스와 동일한 인스턴스, 리전 및 프로젝트에 있습니다. 규정 준수 또는 비즈니스 연속성 이유로 다른 리전 또는 프로젝트의 백업에서 복원해야 하는 경우 별도의 리전 또는 프로젝트의 인스턴스에 백업을 복사할 수 있습니다.
주요 특징
데이터 일관성: Spanner 데이터베이스의 백업은 백업의
versionTime시점에 트랜잭션별 및 external consistency를 갖습니다.복제: 소스 데이터베이스와 동일한 인스턴스에 있는 백업은 동일한 지리적 위치에서 복제됩니다. 리전별 인스턴스의 경우 백업은 3개의 각 읽기-쓰기 영역에 저장됩니다. 이중 리전 및 멀티 리전 인스턴스의 경우 읽기-쓰기 또는 읽기 전용 복제본을 포함하는 모든 영역에 백업이 저장됩니다. 데이터베이스의 백업을 다른 리전 또는 프로젝트에 저장해야 하는 경우 완료된 백업을 소스 인스턴스에서 다른 리전 또는 프로젝트에 있는 대상 인스턴스로 복사할 수 있습니다. 자세한 내용은 백업 복사를 참조하세요.
자동 만료: 모든 백업에는 자동으로 삭제되는 시점을 결정하는 사용자 지정 만료 날짜가 포함됩니다. Spanner는 만료된 백업을 비동기적으로 삭제합니다. 따라서 백업이 만료되는 시점과 실제로 삭제되는 시점 사이에 지연이 발생할 수 있습니다.
백업 만들기
백업을 만들 때 백업은 소스 데이터베이스와 동일한 인스턴스, 리전 및 프로젝트에 있습니다. 백업에는 백업의 versionTime에 있는 데이터베이스의 다음 정보가 포함됩니다.
- 전체 백업에는 모든 데이터가 포함됩니다. 증분 백업에는 이전 백업 이후 변경된 데이터만 포함됩니다.
- 테이블 이름, 필드, 데이터 유형, 보조 색인, 변경 내역, 이러한 항목 간의 관계를 비롯한 스키마 정보
ALTER DATABASE SET OPTIONS명령어로 설정된 모든 데이터베이스 옵션
Spanner 백업에는 다음 정보가 포함되지 않습니다.
versionTime후 데이터 또는 스키마의 수정 사항- Identity and Access Management(IAM) 정책
- 변경 내역 데이터 레코드. 변경 내역 스키마는 저장되지만 변경 내역 데이터는 설명되는 변경사항과 거의 동시에 스트리밍되고 소비됩니다.
백업의 외적 일관성을 보장하기 위해 Spanner는 데이터베이스의 콘텐츠를 versionTime에 고정합니다.
이렇게 하면 백업 작업을 진행하는 동안 가비지 컬렉션 시스템이 관련 데이터 값을 삭제하는 것을 방지할 수 있습니다. 그런 후 인스턴스의 모든 읽기/쓰기 및 읽기 전용 영역이 데이터 복사를 병렬로 시작합니다. 영역을 일시적으로 사용할 수 없게 되면 영역이 다시 온라인 상태로 전환되기 전까지 백업이 완료되지 않습니다. 작업이 완료되면 즉시 백업을 복원할 수 있습니다. 멀티 리전 인스턴스의 경우 백업이 복원 가능으로 표시되기 전 모든 리전의 모든 읽기/쓰기 및 읽기 전용 영역이 백업 복제본을 완료해야 합니다.
백업 일정
Spanner를 사용하면 데이터베이스의 전체 백업 또는 증분 백업을 예약할 수 있습니다. 증분 백업에는 이전 백업 이후 변경된 데이터만 포함되며 전체 백업은 데이터베이스의 전체 콘텐츠를 저장합니다. Spanner에서 백업을 만들 백업 일정 유형 (전체 또는 증분) 및 빈도를 지정할 수 있습니다.
전체 백업 일정은 12시간마다 백업을 생성할 수 있습니다. 증분 백업 일정은 4시간마다 백업을 생성할 수 있습니다.
Spanner는 백업 일정을 통해 데이터베이스의 증분 백업을 제공합니다. 주문형으로 증분 백업을 만들 수는 없습니다.
백업 생성은 예약된 시간의 4시간 내에 시작됩니다. 데이터베이스당 최대 4개의 백업 일정을 설정할 수 있습니다.
증분 백업
증분 백업은 전체 백업 간에 체인을 형성합니다. 증분 백업 일정에 의해 생성된 첫 번째 백업은 전체 백업입니다. 체인에서 생성된 연속 백업은 증분 백업으로, 각각 체인의 이전 백업 이후 변경된 데이터만 포함됩니다.
Spanner는 초기 전체 백업 외에도 체인당 최대 13개의 증분 백업을 허용합니다. 체인은 해당하는 incrementalBackupChainId 값으로 식별됩니다.
체인이 최대 길이에 도달하면 Spanner는 초기 전체 백업으로 시작하여 새 체인을 만듭니다.
경우에 따라 최대 체인 길이가 발생하기 전에 Spanner가 새 체인을 만들 수 있습니다. 다음은 몇 가지 시나리오입니다.
- 가장 오래된 전체 백업이 28일 이상 전에 생성됨
- 체인의 가장 최근 백업이 삭제됨
- 증분 백업 일정이 수정됨
증분 백업을 사용하는지 여부를 결정하는 데 도움이 되는 몇 가지 요소는 다음과 같습니다.
암호화: 증분 백업은 데이터베이스가 고객 관리 암호화 키(CMEK)로 암호화되더라도 Google 관리 키를 사용한 암호화만 지원합니다.
복원: 증분 백업을 복원하는 데 동일한 데이터가 포함된 전체 백업을 복원하는 것보다 시간이 더 걸릴 수 있습니다.
삭제: 체인의 백업을 삭제하거나 만료되면 체인에 더 새로운 백업이 있는 경우 이를 지원하기 위해 Spanner에서 백업을 계속 보관할 수 있습니다. 증분 백업을 복원하려면 Spanner에 체인의 모든 이전 백업이 필요합니다. 만료되거나 삭제된 백업을 비롯하여 백업 체인의 모든 데이터를 삭제하려면 체인의 모든 백업을 삭제합니다.
보관: 각 백업 일정에는 일정에 관한 정보를 제공하는 다음과 같은 용어가 있습니다.
creation_interval: 백업 일정에 지정된 일정 빈도를 나타냅니다.retention_duration: 일정에 의해 생성된 백업이 보관되는 기간을 나타냅니다. 특정 체인의 경우 체인의 최신 백업을 지원하는 데 필요한 경우 가장 오래된 전체 백업이 원래 만료일 이후에도 유지됩니다. 전체 백업의 총 보관 기간은 다음 값 중 더 낮은 값을 초과하지 않습니다.retention_duration+ 28일retention_duration+ (creation_interval*14)
백업 사본: 증분 백업을 복사하면 Spanner는 초기 전체 백업부터 복사하려는 특정 증분 백업까지의 백업 체인을 복사합니다. Spanner는 사용된 총 스토리지를 기준으로 요금을 청구합니다.
증분 백업 생성에 관한 자세한 내용은 백업 일정 만들기 및 관리를 참고하세요.
전체 백업 및 증분 백업의 스토리지 비용
각 Spanner 백업에는 스토리지 사용량에 관한 정보를 제공하는 다음 필드가 있습니다.
exclusiveSizeBytes: 백업에 필요한 바이트 수를 표시합니다. 이 크기는 백업의 청구 가능한 크기를 나타냅니다.freeableSizeBytes: 백업을 삭제할 경우 해제되는 바이트 수를 표시합니다.oldestVersionTime: 체인에서 가장 오래된 전체 백업의versionTime을 표시합니다(백업이 만료된 경우에도 해당). 이 필드를 사용하여 저장되는 데이터를 파악할 수 있습니다.
증분 백업을 사용하면 스토리지 비용을 절약할 수 있습니다. 증분 백업은 체인의 이전 백업 이후 변경사항만 저장하면 되므로 전체 백업보다 exclusiveSizeBytes 필드가 훨씬 작을 수 있습니다.
체인의 각 백업에 이 필드 값을 추가하면 체인의 백업에서 사용한 총 바이트 수가 반영됩니다.
증분 백업은 복원 시 동일한 체인의 모든 이전 백업에 종속됩니다.
즉, 최신 증분 백업이 있는 경우 체인의 모든 이전 백업 데이터를 시스템에서 삭제할 수 없으며 동일한 체인의 모든 이전 백업의 freeableSizeBytes 필드는 0입니다.
크기가 100GB이고 매일 10GB씩 증가하는 데이터베이스에 전체 백업 일정과 증분 백업 일정을 만들었다고 가정해 보겠습니다. 다음 표에는 이러한 백업 일정에 따른 스토리지 비용이 나와 있습니다.
| 일 | 전체 예약 백업 크기 | 증분 일정 백업 크기 |
|---|---|---|
| 1 | 100GB | 100GB |
| 2 | 110 GB | 10 GB |
| 3 | 120 GB | 10 GB |
| 4 | 130 GB | 10 GB |
| 5 | 140 GB | 10 GB |
5일 동안 전체 백업 일정은 600GB의 스토리지를 사용하고 증분 백업 일정은 약 140GB의 스토리지를 사용합니다.
증분 백업 일정의 경우 전체 백업 크기는 체인의 해당 백업까지의 모든 백업 크기의 합계이며 sizeBytes 필드에 반영됩니다.
백업 복사 작동 방법
Spanner 백업 및 복원을 사용하면 Spanner 데이터베이스 백업을 한 인스턴스에서 다른 리전 또는 프로젝트의 다른 인스턴스로 복사하여 추가 데이터 보호 및 규정 준수 기능을 제공할 수 있습니다. 복사된 백업에는 원본 백업과 동일한 주요 기능이 있습니다. 또한 교차 리전 및 교차 프로젝트 백업과 복원 사용 사례를 지원하기 위해 복사된 백업과 동일한 인스턴스에서 복사된 백업을 restore할 수 있습니다.
Spanner 백업 저장 위치
백업은 Spanner에서 리소스입니다. 각 백업 리소스는 리소스 계층 구조에서 해당 소스 데이터베이스와 동일한 인스턴스에 저장되며 다음 형식을 사용하는 리소스 경로를 갖습니다.
projects/PROJECT_ID/instances/INSTANCE_ID/backups/BACKUP_NAME
다음을 바꿉니다.
PROJECT_ID: 프로젝트 IDINSTANCE_ID: 인스턴스 IDBACKUP_NAME: 백업 이름
백업은 해당 소스 데이터베이스가 삭제된 다음에도 계속 존재하지만 상위 인스턴스보다 오래 지속될 수 없습니다. 백업이 실수로 삭제되는 것을 방지하기 위해 백업이 있는 경우 Spanner 인스턴스를 삭제할 수 없습니다. 인스턴스를 삭제하려면 백업 및 인스턴스를 삭제하기 전에 해당 백업을 복원한 다음 복원된 데이터베이스를 내보내는 것이 좋습니다.
암호화
데이터베이스와 마찬가지로 Spanner 백업은 Google 관리 암호화 키 또는 고객 관리 암호화 키(CMEK)로 암호화됩니다. 기본적으로 백업은 해당 데이터베이스와 동일한 암호화 구성을 사용하지만, 백업을 만들 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 백업에 CMEK가 사용 설정되었으면 백업을 만들 때 KMS 키의 기본 버전을 사용하여 암호화됩니다. 백업을 만든 후에는 KMS 키가 순환되어도 해당 키 및 키 버전을 수정할 수 없습니다. 자세한 내용은 CMEK 사용 백업 만들기를 참조하세요.
복사된 백업은 Google 관리나 고객 관리(CMEK)인 경우 소스 백업 암호화와 동일한 암호화 구성을 사용합니다. 백업을 복사할 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 리전 간에 복사할 때 복사된 백업을 CMEK로 암호화하려면 대상 리전에 해당하는 Cloud KMS 키를 지정합니다.
백업 일정을 만들거나 수정할 때 암호화 구성을 지정할 수 있습니다. 백업 일정에서 CMEK 키로 암호화된 백업을 만들려면 키 경로를 지정해야 합니다.
증분 백업은 데이터베이스가 CMEK 키로 암호화되더라도 Google 관리 키만을 사용하여 암호화를 지원합니다.
성능
이 섹션에서는 Spanner에서 최적의 백업 성능에 대해 설명합니다.
백업 시 성능
백업을 수행할 때 Spanner는 데이터베이스에서 백업 스토리지로 직접 데이터를 복사하는 백업 작업을 만들고 데이터베이스 크기에 따라 해당 작업의 크기를 조정합니다. 이 백업 작업은 데이터베이스 인스턴스에 할당된 CPU 리소스를 사용하지 않으므로 인스턴스 성능에 영향을 미치지 않습니다. 또한 데이터베이스 인스턴스의 컴퓨팅 부하는 백업 작업 속도에 영향을 미치지 않습니다. 백업 작업의 진행률과 완료를 추적하려면 백업 진행률 표시를 참조하세요.
일반적으로 대부분의 백업은 1~4시간 정도 걸립니다. 일부 백업은 크기 또는 내부 리소스 큐로 인해 더 오래 걸릴 수 있습니다. 다른 요인이 변경되지 않았을 때 백업이 평소보다 오래 걸리는 경우 영역에서 백업 작업 예약이 지연되었기 때문일 수 있습니다. 이 과정에는 최대 30분이 소요될 수 있습니다. 백업을 취소하고 다시 시작하지 않는 것이 좋습니다. 새로운 백업 작업에 동일한 예약 지연이 발생할 수 있습니다.
백업 복사 시 성능
백업을 복사하는 데 걸리는 시간은 복사한 백업에 대해 선택한 소스 백업 및 대상 리전의 크기와 같은 요소에 따라 달라집니다. 일반적으로 대부분의 복사는 1~4시간 안에 완료됩니다. 일부 사본은 백업 크기와 대상 리전에 따라 더 오래 걸릴 수 있습니다. 백업을 복사해도 소스 인스턴스 또는 데이터베이스에 대한 성능 영향이 없습니다. 성능에 영향을 주지 않고 다른 리전의 인스턴스에 소스 백업의 여러 복사본을 동시에 만들 수 있습니다.
증분 백업을 복사하면 Spanner는 체인의 모든 최신 백업을 복사합니다. Spanner는 백업 체인을 하나씩 복사하는 대신 성능을 개선하기 위해 모든 백업을 동시에 복사합니다.
백업 삭제
증분 백업을 삭제할 때 동일한 체인에 최신 증분 백업이 있는 경우 스토리지가 복구되지 않을 수 있습니다.
최신 증분 백업은 삭제된 증분 백업 및 체인의 이전 백업에 있는 데이터에 종속됩니다. Spanner는 데이터를 유지하고 모든 최신 증분 백업이 만료될 때만 스토리지를 해제합니다.
freeableSizeBytes 필드는 백업을 삭제할 경우 얼마나 많은 저장용량을 다시 확보할 수 있는지 보여줍니다.
가격 책정
백업에 사용되는 단위 시간별 스토리지 사용량을 기준으로 청구됩니다. 청구는 백업 작업이 완료된 후 시작되며 백업이 삭제될 때까지 계속됩니다. 완료된 백업은 최소 24시간 단위로 청구됩니다. 백업을 만든 후 완료되자마자 삭제하더라도 24시간에 대한 비용이 청구됩니다.
백업 사본에는 원래 백업과 동일한 스토리지 비용이 적용됩니다. 서로 다른 리전을 사용하는 두 인스턴스 간에 복사본을 만드는 경우 아웃바운드 데이터 전송 비용이 적용됩니다.
예를 들어 데이터베이스를 소스 멀티 리전 인스턴스 구성 nam7에서 대상 멀티 리전 인스턴스 구성 nam-eur-asia3로 복사할 경우 다음 요금이 적용됩니다.
us-central1리전 중복에 요금이 부과되지 않음us-central2리전에 요금이 부과되지 않음- 대륙 간 데이터 전송 요금은 신 대륙(유럽 및 아시아)마다 한 번씩 두 번 적용됩니다.
- 동일한 대륙 내 리전 간 데이터 전송 요금은
us-east1에 한 번만 적용됩니다. - 동일한 대륙 내 리전 간 데이터 전송 요금은 유럽에서 한 번 적용됩니다.
Spanner는 교차 리전 전송 수를 최소화하기 위해 복사 프로세스를 최적화합니다. 이렇게 하면 빠른 복사 백업 경험을 제공하면서도 데이터 전송 비용을 최소화할 수 있습니다.
백업은 개별적으로 저장되고 청구됩니다. 백업 스토리지는 데이터베이스 스토리지 청구 또는 데이터베이스 스토리지 한도에 영향을 주지 않습니다. 자세한 내용은 스토리지 사용량 측정항목도 참조하세요.
백업 비용에 대한 자세한 내용은 Spanner 가격 책정을 참조하세요.