Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
É possível restaurar um backup de um banco de dados do Spanner em um novo banco de dados. O
banco de dados restaurado terá todos os dados e o esquema do banco de dados original
no version_time do backup, incluindo todas as opções de banco de dados definidas
com o comando ALTER DATABASE SET OPTIONS. No entanto, o seguinte não está incluído no banco de dados restaurado:
Permissões do IAM (exceto as herdadas da instância que contém o banco de dados restaurado). Você precisa aplicar as permissões adequadas do IAM após a conclusão da restauração.
Dados internos de qualquer fluxo de alterações.
Time to live (TTL) definido por uma política de exclusão de linha. Você precisa reconfigurar essas políticas depois que a restauração for concluída. Para mais informações, consulte
Backups e TTL.
Pontos de divisão criados ao pré-dividir um banco de dados. Para mais informações, consulte Visão geral da pré-divisão.
Quando você restaura de um backup, o banco de dados restaurado fica na mesma instância, região e projeto do backup de origem. Se você precisar restaurar o backup em uma região ou projeto diferente por motivos de conformidade ou continuidade dos negócios, copie o backup para uma instância em uma região ou projeto separado e restaure do backup copiado.
É possível usar a restauração de um backup das seguintes maneiras:
Como funciona a restauração de um banco de dados a partir de um backup
Ao restaurar um banco de dados do Spanner, especifique um backup de origem e um novo banco de dados de destino. Não é possível restaurar para um banco de dados atual.
O banco de dados recém-restaurado precisa estar no mesmo projeto que o backup e em uma instância com a mesma configuração de instância e a mesma edição do Spanner (ou de nível superior) que o backup. Por exemplo, se um backup estiver em uma instância configurada em us-west3 e
usar a edição Enterprise, ele poderá ser restaurado para qualquer instância no
projeto que também esteja configurada em us-west3 e use a
edição Enterprise. Se você restaurar um backup de uma instância da edição Enterprise em uma instância da edição Standard, a restauração poderá falhar se o banco de dados usar recursos da edição Enterprise. A capacidade de computação das instâncias não precisa ser a mesma.
O processo de restauração foi projetado para alta disponibilidade. O banco de dados pode ser restaurado desde que a maioria das regiões e zonas da instância esteja disponível.
Para restaurar um backup ativado para CMEK, a chave e a versão da chave precisam estar disponíveis
para o Spanner. Por padrão, o banco de dados restaurado usa as mesmas
configurações de criptografia
do backup. É possível substituir esse comportamento especificando uma configuração de criptografia diferente ao restaurar o banco de dados. Para mais informações, consulte como restaurar um backup ativado para CMEK.
Restaurar um backup para outra região ou projeto
Se você precisar restaurar o backup para uma região ou projeto diferente, primeiro copie o backup para a região ou o projeto escolhido. Os backups copiados podem ser restaurados assim que a cópia
terminar. É possível restaurar o backup na instância de destino (desde que ela use a edição como a instância de backup de origem) ou em qualquer instância que tenha a mesma configuração e a mesma edição (ou uma de nível superior) da instância de destino. Antes de restaurar, verifique se a instância de destino tem nós ou unidades de processamento suficientes provisionados para oferecer suporte ao tamanho do banco de dados de acordo com o limite de armazenamento de 10 TB por nó. Ou seja, você precisa de pelo menos dois nós para restaurar um backup de 20 TB. Se você copiou o backup para um projeto diferente e quer restaurá-lo lá, verifique se o projeto de destino tem cotas de nós suficientes para a restauração. A restauração de um backup copiado
funciona da mesma forma que uma restauração normal.
CREATING: o Spanner começa a restauração criando um novo banco de dados e ativando arquivos do backup. Durante esse estado inicial CREATING, o banco de dados restaurado ainda não está pronto para uso. Esse estado normalmente é concluído em uma hora. Quando o estado CREATING for concluído, seu banco de dados estará pronto para uso.
Observe as seguintes ressalvas sobre o estado CREATING:
Se você estiver restaurando para uma instância diferente, a operação de restauração
pertencerá à instância que contém o banco de dados restaurado, não à instância
que contém o backup.
O Spanner não permite excluir o backup enquanto ele está
sendo restaurado. É possível excluir o bucket depois que a restauração for concluída e o banco de dados entrar no estado READY.
Uma instância pode ter no máximo dez bancos de dados no estado CREATING devido à restauração de backups. Não será possível restaurar outro backup para a instância até que um dos dez bancos de dados restaurados faça a transição para o estado READY_OPTIMIZING ou READY.
READY_OPTIMIZING: depois que o Spanner monta o backup, ele começa
a copiar os dados para o novo banco de dados e otimiza o tamanho
armazenado. Seu banco de dados está pronto para uso durante esse processo. Essa fase da restauração geralmente leva algumas horas para ser concluída em bancos de dados com menos de 100 TB.
Embora seja possível usar seu banco de dados normalmente durante o READY_OPTIMIZING, as seguintes ressalvas se aplicam:
As latências de leitura podem ser um pouco maiores do que o normal.
As métricas de armazenamento mostram o tamanho do novo banco de dados, não do backup. Portanto, com a transferência de dados ainda em andamento, as métricas de armazenamento do Spanner podem mostrar resultados que não refletem o tamanho total de todos os seus dados.
Assim como no estado CREATING, o Spanner não permite excluir o backup ativado.
READY: após a conclusão da operação de cópia e otimização, o banco de dados
faz a transição para o estado READY. O banco de dados é totalmente restaurado e não faz mais referência nem exige o backup.
Controle de acesso (IAM)
A função spanner.restoreAdmin concede permissão para restaurar de um backup.
Saiba mais em Controle de acesso com o IAM.
Os seguintes papéis também têm acesso às operações de restauração do Spanner:
spanner.admin: tem acesso total à restauração. Essa função tem acesso completo a todos os recursos do Spanner.
owner: tem acesso total à restauração.
editor: tem acesso total à restauração.
viewer: tem acesso para visualizar restaurações e operações de restauração. Esse papel não pode criar, atualizar, excluir ou copiar um backup.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-17 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)."]]