Spanner 데이터베이스 백업을 새 데이터베이스로 복원할 수 있습니다. 복원된 데이터베이스는 ALTER DATABASE SET OPTIONS 명령어로 설정된 모든 데이터베이스 옵션을 포함하여 백업의 version_time 시점에 원본 데이터베이스의 모든 데이터 및 스키마를 갖습니다. 그러나 다음은 복원된 데이터베이스에 포함되지 않습니다.
IAM 권한(복원된 데이터베이스를 포함하는 인스턴스에서 상속된 권한 제외) 복원 완료 후 적절한 IAM 권한을 적용해야 합니다.
변경 내역의 내부 데이터
행 삭제 정책에 의해 정의된 TTL(수명)입니다. 복원이 완료된 후 이러한 정책을 다시 구성해야 합니다. 자세한 내용은 백업 및 TTL을 참조하세요.
데이터베이스를 사전 분할할 때 만든 분할 지점입니다. 자세한 내용은 사전 분할 개요를 참조하세요.
백업에서 복원할 때 복원된 데이터베이스는 해당 소스 백업과 동일한 인스턴스, 리전, 프로젝트에 상주합니다. 규정 준수 또는 비즈니스 연속성 이유로 다른 리전 또는 프로젝트의 백업에서 복원해야 하는 경우 별도의 리전 또는 프로젝트의 인스턴스에 백업을 복사한 다음 복사된 백업에서 복원할 수 있습니다.
Spanner 데이터베이스를 복원하려면 소스 백업 및 새 대상 데이터베이스를 지정해야 합니다. 기존 데이터베이스로는 복원할 수 없습니다.
새로 복원된 데이터베이스는 백업과 동일한 프로젝트에 있어야 하며, 백업과 동일한 인스턴스 구성 및 동일한(또는 더 높은 등급의) Spanner 버전의 인스턴스에 있어야 합니다. 예를 들어 백업이 us-west3로 구성된 인스턴스에 있고 Enterprise 버전을 사용하는 경우 us-west3로 구성되고 Enterprise 버전을 사용하는 프로젝트의 모든 인스턴스로 복원할 수 있습니다. Enterprise 버전 인스턴스의 백업을 Standard 버전 인스턴스로 복원하면 데이터베이스에서 Enterprise 버전 기능을 사용하는 경우 복원이 실패할 수 있습니다. 인스턴스의 컴퓨팅 용량은 동일할 필요가 없습니다.
복원 프로세스는 고가용성을 위해 설계되었습니다. 인스턴스에서 리전 및 영역의 쿼럼을 대부분 사용할 수 있는 한 데이터베이스를 복원할 수 있습니다.
CMEK 사용 백업을 복원하려면 키 및 키 버전을 모두 Spanner에 사용할 수 있어야 합니다. 기본적으로 복원된 데이터베이스에는 백업과 동일한 암호화 구성이 사용됩니다. 데이터베이스를 복원할 때 다른 암호화 구성을 지정하여 이 동작을 재정의할 수 있습니다. 자세한 내용은 CMEK 사용 백업에서 복원을 참조하세요.
백업을 다른 리전 또는 프로젝트로 복원
백업을 다른 리전 또는 프로젝트로 복원하려면 먼저 선택한 리전 또는 프로젝트에 백업을 복사합니다. 복사된 백업은 복사가 완료되는 즉시 복원할 수 있습니다. 대상 인스턴스(소스 백업 인스턴스와 동일한 버전을 사용하는 경우) 또는 인스턴스 구성이 대상 인스턴스와 동일하고 버전이 대상 인스턴스와 동일하거나 더 높은 버전인 모든 인스턴스에서 백업을 복원할 수 있습니다. 복원하기 전에 대상 인스턴스에 노드당 10TB 스토리지 한도에 따라 데이터베이스 크기를 지원할 수 있는 충분한 노드나 처리 장치가 프로비저닝되었는지 확인합니다(즉, 20TB 백업을 복원하려면 노드가 최소 2개 이상 필요함). 백업을 다른 프로젝트에 복사하고 해당 프로젝트에서 복원하려면 대상 프로젝트에 복원에 필요하는 데 충분한 노드 할당량이 확인합니다. 복사된 백업 복원은 일반 복원과 같은 방식으로 작동합니다.
복원 상태
복원된 데이터베이스는 3개의 상태를 통해 전환되며. 이는 2개의 장기 실행 작업으로 추적할 수 있습니다.
CREATING: Spanner는 백업에서 새 데이터베이스를 만들고 파일을 마운트하여 복원을 시작합니다. 이 초기 CREATING 상태 중에는 복원된 데이터베이스를 아직 사용할 준비가 되지 않습니다. 이 상태는 일반적으로 1시간 내에 완료됩니다. CREATING 상태가 완료되면 데이터베이스를 사용할 준비가 완료됩니다.
다른 인스턴스로 복원하는 경우, 복원 작업은 백업이 포함된 인스턴스가 아니라 복원된 데이터베이스가 포함된 인스턴스에 속합니다.
Spanner에서는 복원 중 백업 삭제가 허용되지 않습니다. 복원이 완료되고 데이터베이스가 READY 상태로 전환된 다음 삭제할 수 있습니다.
인스턴스는 백업에서 복원으로 인해 CREATING 상태의 데이터베이스를 최대 10개 포함할 수 있습니다. 복원된 10개의 데이터베이스 중 하나가 READY_OPTIMIZING 또는 READY 상태로 전환될 때까지는 인스턴스에 대한 다른 백업을 복원할 수 없습니다.
READY_OPTIMIZING: Spanner가 백업을 마운트한 후 저장 크기를 최적화하면서 새 데이터베이스로 백업 데이터 복사가 시작됩니다. 이 프로세스 중에 데이터베이스 사용이 준비됩니다. 이 복원 단계는 크기가 100TB 미만인 데이터베이스에서 일반적으로 완료되는 데 몇 시간이 걸립니다.
READY_OPTIMIZING 중에도 데이터베이스를 평소와 같이 사용할 수 있지만 다음과 같은 제한사항이 있습니다.
읽기 지연 시간이 평소보다 약간 높아질 수 있습니다.
스토리지 측정항목에 백업이 아닌 새 데이터베이스 크기가 표시됩니다. 따라서 데이터 전송이 여전히 진행되는 동안에는 Spanner 스토리지 측정항목에 모든 데이터의 총 크기가 반영되지 않은 결과가 표시될 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Restore overview\n\nYou can restore a backup of a Spanner database into a new database. The\nrestored database will have all the data and schema from the original database\nat the `version_time` of the backup, including all database options that are set\nwith the [`ALTER DATABASE SET OPTIONS`](/spanner/docs/reference/standard-sql/data-definition-language#alter-database)\ncommand. However, the following aren't included in the restored database:\n\n- IAM permissions (except for those inherited from the instance containing the restored database). You must apply appropriate IAM permissions after the restore completes.\n- Internal data of any change streams.\n- Time to live (TTL) defined by a row deletion policy. You must reconfigure these policies after the restore completes. For more information, see [Backups and TTL](/spanner/docs/ttl#backups).\n- Split points you created when pre-splitting a database. For more information, see [Pre-splitting overview](/spanner/docs/pre-splitting-overview).\n\nWhen you restore from a backup, the restored database resides in the same\ninstance, region, and project as its source backup. If you need to restore from\nthe backup in a different region or project for compliance or business\ncontinuity reasons, you can\n[copy the backup](/spanner/docs/backup/manage-backups#copy-backup) to an\ninstance in a separate region or project, then restore from the copied backup.\n\nYou can use restore from a backup in the following ways:\n\n- In the [Google Cloud console](/spanner/docs/backup/gcp#restore)\n- Using the [Google Cloud CLI](/spanner/docs/backup/gcloud#restore)\n- Using the [client libraries](/spanner/docs/backup/libraries#restore)\n- Using the [REST](/spanner/docs/reference/rest/v1/projects.instances.backups#restore) or [RPC](/spanner/docs/reference/rpc/google.spanner.admin.database.v1#google.spanner.admin.database.v1.Backup) APIs\n\nHow database restoration from a backup works\n--------------------------------------------\n\nWhen you restore a Spanner database, you must specify a source\nbackup and a new target database. You cannot restore to an existing database.\nThe newly restored database must be in the same project as the backup and be in\nan instance with the same\n[instance configuration](/spanner/docs/instances#configuration) and same (or\nhigher-tier) [Spanner edition](/spanner/docs/editions-overview) as\nthe backup. For example, if a backup is in an instance configured `us-west3` and\nuses the Enterprise edition, it can be restored to any instance in the\nproject that is also configured `us-west3` and uses the\nEnterprise edition. If you restore a backup in an\nEnterprise edition instance into a Standard edition\ninstance, the restore might fail if the database uses\nEnterprise edition features. The [compute capacity](/spanner/docs/compute-capacity) of the\ninstances doesn't need to be the same.\n\nThe restore process is designed for high-availability. The database can be\nrestored provided that the majority quorum of the regions and zones in the\ninstance is available.\n\nTo restore a CMEK-enabled backup, both the key and key version must be available\nto Spanner. The restored database, by default, uses the same\n[encryption configurations](/spanner/docs/reference/rest/v1/projects.instances.databases/restore#RestoreDatabaseEncryptionConfig)\nas the backup. You can override this behavior by specifying a different\nencryption configuration when restoring the database. For more information, see\n[restore from a CMEK-enabled backup](/spanner/docs/use-cmek#restore).\n| **Note:** Before restoring a database, make sure your instance is properly provisioned with enough storage and compute capacity to handle the additional storage and traffic associated with the restored database. If the target instance is not properly provisioned, restoring a database could adversely affect the performance of existing databases in the instance.\n\n### Restore a backup to a different region or project\n\nIf you need to restore the backup to a different region or project, first,\n[copy the backup](/spanner/docs/backup/manage-backups#copy-backup) to the\nchosen region or project. Copied backups are restorable as soon as the copy\nfinishes. You can restore the backup either in the destination instance (as long\nas it uses the edition as the source backup instance) or in any instance that\nhas the same instance configuration and same (or higher-tier) edition as the\ndestination instance. Before restoring, make sure that the destination instance\nhas enough nodes or processing units provisioned to support the database size\naccording to the 10 TB per node storage limit (that is, you need at least 2\nnodes to restore a 20 TB backup). If you have copied the backup to a different\nproject, and if you want to restore it there, make sure that your destination\nproject has enough node quotas required for the restore. Restoring a copied\nbackup works the same way as a normal restore.\n\nRestoration states\n------------------\n\nA restored database transitions through three [states](/spanner/docs/reference/rest/v1/projects.instances.databases#state),\ntracked by two [long-running operations](/spanner/docs/manage-long-running-operations).\n\n- `CREATING`: Spanner begins restoring by creating a new\n database and mounting files from the backup. During this initial `CREATING`\n state, the restored database is not yet ready for use. This state typically\n completes within one hour. Once the `CREATING` state is complete, your\n database is ready to use.\n\n To track the progress of this state, you can query the [long-running restore\n operation](/spanner/docs/manage-long-running-operations) that\n Spanner makes available during this process. It returns a\n [`RestoreDatabaseMetadata`](/spanner/docs/reference/rest/v1/RestoreDatabaseMetadata) object.\n\n Note the following caveats regarding the `CREATING` state:\n - If you are restoring to a different instance, the restore operation belongs to the instance containing the restored database, not the instance containing the backup.\n - Spanner won't allow you to delete the backup while it is being restored. You can delete it after the restore completes and the database enters the `READY` state.\n - An instance can have at most ten databases in the `CREATING` state due to restoration from backups. You won't be able to restore another backup to the instance until one of the ten restored databases transitions to the `READY_OPTIMIZING` or `READY` state.\n- `READY_OPTIMIZING`: After Spanner mounts the backup, it starts\n to copy the backup data into the new database while optimizing its stored\n size. Your database is ready for use during this process. This phase of the\n restore usually takes a few hours to complete for databases less than 100TB\n in size.\n\n While you can use your database as usual during `READY_OPTIMIZING`, the\n following caveats apply:\n - Read latencies might be slightly higher than usual.\n - [Storage metrics](/spanner/docs/storage-utilization) display the size of the new database, not the backup. Therefore, with the data transfer still in progress, Spanner storage metrics might show results that don't reflect the total size of all your data.\n - As with the `CREATING` state, Spanner won't allow you to delete the mounted backup.\n\n Spanner makes another [long-running restore operation](/spanner/docs/manage-long-running-operations)\n available during this state, this time returning a [`OptimizeRestoredDatabaseMetadata`](/spanner/docs/reference/rest/v1/OptimizeRestoredDatabaseMetadata)\n metadata object.\n- `READY`: Once the copy-and-optimize operation completes, the database\n transitions to the `READY` state. The database is fully restored, and no\n longer references or requires the backup.\n\nAccess control (IAM)\n--------------------\n\nThe role `spanner.restoreAdmin` gives you permission to restore from a backup.\nFor more information, see [Access control with IAM](/spanner/docs/backup#iam).\n\nThe following roles also have access to Spanner restore operations:\n\n- `spanner.admin`: has full access to restore. This role has complete access to all Spanner resources.\n- `owner`: has full access to restore.\n- `editor`: has full access to restore.\n- `viewer`: has access to view restore and restore operations. This role can't create, update, delete, or copy a backup.\n\nPricing\n-------\n\nThere is no charge for restoring from a backup.\n\nWhat's next\n-----------\n\n- To restore a database from a backup, see [Restore from a backup](/spanner/docs/backup/restore-backups)."]]
