É possível criar um backup de qualquer banco de dados do Spanner. Esses backups são
concluídos, ou seja, contêm todos os dados do banco de dados
(incluindo o esquema e os índices secundários) no version_time
do backup. Modificações nos dados ou no esquema após o version_time
não são incluídas no backup. Os backups incluem todas as opções de banco de dados
definidas com o comando ALTER DATABASE SET OPTIONS
, mas não incluem as políticas do Identity and Access Management (IAM). Quando você cria um backup, ele fica na mesma instância,
região e no projeto que o banco de dados de origem.
É possível criar um backup das seguintes maneiras:
- No console do Google Cloud
- usando a Google Cloud CLI;
- com as bibliotecas de cliente
- Como usar as APIs REST ou RPC
Para ter uma visão geral do backup e da restauração, consulte Sobre backup e restauração.
Como funciona a criação de um backup
Ao criar um backup, é necessário especificar um banco de dados de origem, um nome para o
recurso de backup e uma data de validade (até um ano a partir do momento de criação do
backup). Também é possível especificar um
version_time
para fazer backup do
banco de dados para um momento anterior. Normalmente, o campo version_time
é usado para sincronizar os backups de vários bancos de dados ou recuperar dados usando a recuperação pontual. Se version_time
não for
especificado, ele será definido como o create_time
do backup. O sistema cria
um recurso de backup e uma
operação de backup de longa duração para rastrear
o progresso do backup. O backup recém-criado fica na mesma
instância, região e projeto que o banco de dados de origem.
Para garantir a consistência externa do backup, o Spanner fixa o conteúdo do banco de dados em create_time
. Isso impede que o sistema de coleta
de lixo remova os valores de dados relevantes durante a operação de
backup. Em seguida, cada zona de leitura/gravação e somente leitura na instância começa a copiar os dados em paralelo. Se alguma zona estiver temporariamente indisponível, o backup
não será concluído até que a zona fique on-line novamente e seja concluída. Os backups são
restauráveis assim que a operação é concluída. Para instâncias multirregionais, todas
as zonas de leitura e gravação e somente leitura em todas as regiões precisam concluir as réplicas de backup
antes que o backup seja marcado como restaurável.
Os backups também incluem o esquema dos fluxo de alterações de um banco de dados, mas não os registros de alterações existentes. Os dados de fluxo de alterações devem ser transmitidos e consumidos quase simultaneamente com as alterações descritas. Assim, o Spanner exclui esses dados dos backups.
Criptografia
Os backups do Spanner, como bancos de dados, são criptografados por criptografia gerenciada pelo Google ou pelo cliente. Por padrão, um backup usa a mesma configuração de criptografia do banco de dados, mas é possível modificar esse comportamento especificando uma configuração de criptografia diferente ao criar o backup. Se o backup estiver ativado para CMEK, ele será criptografado usando a versão primária da chave KMS no momento da criação do backup. Depois que o backup é criado, a chave e a versão de chave do backup não podem ser modificadas, mesmo que a chave KMS seja alternada. Para mais informações, consulte como criar um backup ativado para CMEK.
Hierarquia de recursos
Os backups são recursos no Spanner. Cada recurso de backup
é organizado na mesma instância do banco de dados de origem na hierarquia de recursos
e tem um caminho do recurso no formato projects/<project>/instances/<instance>/backups/<backup>
.
Um backup continua existindo mesmo após a exclusão do banco de dados de origem,
mas não pode sobreviver à instância pai. Para evitar a exclusão acidental de backups, não é possível excluir uma instância do Spanner se houver backups. Se você quiser excluir a instância, recomendamos restaurar o
backup e exportar o banco de dados restaurado antes
de excluir o backup e a instância.
Tempo e desempenho de backup
Ao executar um backup, o Spanner cria uma tarefa de backup para copiar dados diretamente do banco de dados para o armazenamento de backup e dimensiona esse job com base no tamanho do banco de dados. Essa tarefa de backup não usa recursos de CPU alocados para a instância do banco de dados. Portanto, isso não afeta o desempenho da instância. Além disso, a carga de computação na instância do banco de dados não afeta a velocidade da operação de backup. Para acompanhar o progresso e a conclusão de uma operação de backup, consulte Mostrar progresso do backup.
Como ponto de referência geral, a maioria dos backups leva de 1 a 4 horas. Alguns backups podem levar mais tempo devido ao tamanho ou porque há uma fila interna de recursos. Se um backup estiver demorando mais do que o normal quando nenhum outro fator foi alterado, pode ser devido a um atraso na programação da tarefa de backup em uma zona. Isso pode levar até 30 minutos. Recomendamos não cancelar e reiniciar o backup, já que é provável que você encontre o mesmo atraso de programação na nova operação de backup.
Controle de acesso (IAM)
Os papéis spanner.backupAdmin
e spanner.backupWriter
dão permissão
para criar um backup. Com qualquer um desses papéis, é possível invocar uma solicitação de criação de backup na instância. Para mais informações, consulte Controle de acesso com o IAM.
Preços
A cobrança é feita com base na quantidade de armazenamento usado pelos backups por unidade de tempo. O faturamento começa quando a operação de criação de backup é concluída e vai continuar até que o backup seja excluído. Um backup concluído é cobrado por no mínimo 24 horas. Se você criar um backup e excluí-lo um minuto após a conclusão, você ainda será cobrado por 24 horas.
A seguir
Saiba mais sobre backup e restauração.
Saiba como trabalhar com backups usando o Console do Google Cloud.
Saiba como trabalhar com backups usando a Google Cloud CLI.
Saiba como trabalhar com backups usando bibliotecas de cliente.