Visão geral dos backups

Com o backup do Spanner, é possível criar backups de bancos de dados do Spanner sob demanda e restaurá-los para fornecer proteção contra erros do operador e do aplicativo, que resultam em corrupção lógica de dados. Os backups são altamente disponíveis, criptografados e podem ser retidos por até um ano a partir do momento em que são criados. Quando você cria um backup, ele fica na mesma instância, região e projeto que o banco de dados de origem. Se você precisar restaurar o backup em uma região ou projeto diferente por motivos de conformidade ou continuidade de negócios, copie o backup para uma instância em uma região ou projeto separado. Para manter backups por mais de um ano, recomendamos exportar seu banco de dados. Para proteção contra a corrupção lógica de dados, o Spanner também oferece recuperação pontual. Também é possível ativar a proteção contra exclusão de banco de dados para evitar a exclusão acidental de bancos de dados.

principais recursos

  • Consistência de dados: os backups são uma cópia transacional e consistente externamente de um banco de dados do Spanner no version_time do backup.

  • Replicação: os backups residem na mesma instância do banco de dados de origem e são replicados nas mesmas localizações geográficas. Para instâncias regionais, o backup é armazenado em cada uma das três zonas de leitura/gravação. Para instâncias birregionais e multirregionais, o backup é armazenado em todas as zonas que contêm uma réplica de leitura/gravação ou somente leitura. Se for necessário armazenar o backup do banco de dados em uma região ou um projeto diferente, copie o backup concluído da instância de origem para uma instância de destino localizada em uma região ou projeto diferente. Para mais informações, consulte Copiar um backup.

  • Expiração automática: todos os backups têm uma data de validade especificada pelo usuário que determina quando ela será excluída automaticamente. O Spanner exclui backups expirados de forma assíncrona. Portanto, pode haver um atraso entre a expiração e a exclusão de um backup.

A tabela a seguir descreve várias estratégias de backup, a abordagem recomendada para implementar o plano e o tempo máximo de retenção da abordagem sugerida.

Estratégia de backup Abordagem recomendada Tempo de retenção máximo para a abordagem sugerida
Armazenar o backup de um banco de dados na mesma instância, região e projeto que o banco de dados de origem Crie um backup. 1 ano
Armazenar o backup de um banco de dados em uma instância, região ou projeto diferente do banco de dados de origem (ou seja, um backup entre projetos) Crie um backup e copie-o para uma instância em uma região ou projeto diferente. 1 ano
Como armazenar o backup no Cloud Storage Exportar o banco de dados para um bucket do Cloud Storage. Para uma comparação detalhada entre o backup e a exportação, consulte Escolher entre fazer backup e restaurar ou importar e exportar. Ilimitado (retido até a exclusão)
Recuperação pontual (PITR) Para recuperar dados de um momento no passado, escolha PITR. É possível alterar o version_retention_period do banco de dados do padrão de 1 hora para, no máximo, 7 dias. 7 dias

Controle de acesso com o Identity and Access Management (IAM)

Com o IAM, você controla o acesso aos recursos do Spanner, incluindo backups. Se você é novo no IAM, papéis e permissões, consulte a Visão geral do IAM para uma introdução.

Os recursos de backup são organizados em instâncias na hierarquia de recursos do Spanner. Recomendamos aplicar as políticas do IAM no nível do projeto ou da instância. Para um controle mais refinado, as políticas do IAM também podem ser aplicadas no backup e no banco de dados, mas isso não é recomendado devido à complexidade. Lembre-se de que os backups não contêm metadados de banco de dados, como políticas do IAM. Portanto, quando você restaurar um banco de dados, ele inicialmente herdará as políticas da instância pai.

Nesta seção, descrevemos os papéis predefinidos que têm acesso ao backup e à restauração.

Os papéis a seguir foram criados especificamente para backup:

  • spanner.backupAdmin: tem acesso para criar, visualizar, atualizar, copiar e excluir backups. Esse papel também pode visualizar e gerenciar a política do IAM de um backup. Esse papel não pode restaurar um banco de dados a partir de um backup.
  • spanner.backupWriter: tem acesso para criar e copiar backups, mas não pode atualizá-los ou excluí-los. Esse papel se destina a ser usado por scripts que automatizam a criação de backups.

Os papéis a seguir também têm acesso aos backups do Spanner:

  • spanner.admin: tem acesso total ao backup. Esse papel tem acesso total a todos os recursos do Spanner.
  • owner: tem acesso total ao backup.
  • editor: tem acesso total ao backup.
  • viewer: tem acesso para visualizar backups e operações de backup. Esse papel não pode criar, atualizar, excluir ou copiar um backup.

Para mais informações, consulte Spanner IAM.

Como funciona a criação de backup

É possível criar um backup de qualquer banco de dados do Spanner. Esses backups são concluídos, no sentido de que contêm todos os dados no 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 políticas de Identity and Access Management (IAM). Quando você cria um backup, ele fica na mesma instância, região e projeto que o banco de dados de origem.

É possível criar um backup das seguintes maneiras:

Ao criar um backup, você precisa 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 horário de criação do backup). Também é possível especificar um version_time, que permite 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 acompanhar 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 ajudar a garantir a consistência externa do backup, o Spanner fixa o conteúdo do banco de dados em create_time. Isso evita 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 volte a ficar on-line e seja concluído. Os backups podem ser restaurados assim que a operação for concluída. Para instâncias multirregionais, todas as zonas de leitura/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 atuais. Os dados do fluxo de alterações devem ser transmitidos e consumidos quase simultaneamente com as alterações descritas. Assim, o Spanner exclui esses dados dos backups.

Como a cópia de backup funciona

O backup e a restauração do Spanner permitem copiar um backup do banco de dados dele de uma instância para outra em uma região ou projeto diferente, oferecendo mais recursos de proteção de dados e conformidade. O backup copiado tem os mesmos recursos principais que o backup original. Além disso, é possível restaurar um backup copiado na mesma instância dele para oferecer suporte a casos de uso de backup e restauração entre regiões e projetos.

Casos de uso comuns entre regiões

Alguns casos de uso comuns entre regiões para copiar um backup incluem:

  • Manter um backup em outra região para atender aos requisitos regulatórios e de compliance.

    Por exemplo, é possível copiar um backup do banco de dados para uma instância em uma região que esteja a uma distância mínima dos dados de produção para atender aos requisitos de conformidade.

  • Manter um backup em uma região separada para fins de recuperação de desastres e continuidade de negócios.

    Por exemplo, é possível copiar um banco de dados de backup em uma instância de destino para recuperação de desastres com um objetivo do tempo de recuperação (RTO) e objetivo do ponto de recuperação (RPO) diferentes de zero. Depois, quando necessário, restaure o banco de dados usando o backup copiado na instância de destino. Se o aplicativo tiver requisitos de zero RTO e RPO, recomendamos configurações multirregionais do Spanner para os planos de recuperação de desastres.

Casos de uso comuns entre projetos

Alguns casos de uso comuns de vários projetos para copiar um backup incluem:

  • Manter uma cópia de backup em um projeto separado para atender aos requisitos operacionais, de segurança ou de conformidade.

  • Copiar e mover dados entre projetos de desenvolvimento, teste e produção.

    Por exemplo, se você quiser mover dados do projeto de produção para um projeto de teste, crie um backup dos dados de produção e copie o backup para o projeto de teste. Depois que a operação de cópia for concluída, será possível restaurar o backup copiado para uma instância no projeto de teste.

  • Mova o banco de dados de um projeto para outro (observe que pode haver inatividade durante a migração).

É possível copiar um backup para uma instância de destino em uma região ou projeto diferente especificando um backup de origem, um backup de destino e uma data de validade de até um ano a partir do horário de criação do backup de origem. Isso significa que o valor de expiration_date precisa ser pelo menos seis horas a partir do momento em que a solicitação de cópia atual é processada e no máximo 366 dias após o backup de origem create_time.

No início da solicitação de cópia de backup, o Spanner cria um recurso de backup e uma operação de backup de longa duração para ajudar a acompanhar o progresso do backup. O backup é copiado para cada zona de leitura/gravação e somente leitura na instância de destino. Se uma zona estiver temporariamente indisponível, a cópia do backup não será concluída até que a zona volte a ficar on-line. Não é possível excluir a instância de destino durante a cópia. Para acompanhar o progresso e o status de conclusão da operação de backup de cópia, siga as etapas em Mostrar progresso do backup. Após a conclusão da cópia, é possível excluir o backup de origem se não precisar mais dele. Quando a cópia for concluída, será possível usar operações como GetBackup, UpdateBackup e DeleteBackup com o backup copiado.

Pré-requisitos para iniciar a cópia de um backup

Se você estiver copiando um backup para uma instância em uma região ou projeto diferente, precisará configurar e configurar a instância de destino primeiro. A instância de destino é aquela em que a cópia do backup reside. Ela pode ter apenas 100 unidades de processamento e não precisa ter a mesma configuração de instância que a de origem (a instância em que reside o backup de origem). Antes de restaurar, verifique se a instância de destino tem nós ou unidades de processamento suficientes provisionadas para aceitar o tamanho do banco de dados de acordo com o limite de armazenamento de 4 TB por nó (por exemplo, você precisa de pelo menos dois nós para restaurar um backup de 8 TB). Para criar uma nova instância de destino, consulte Criar e gerenciar instâncias.

Outras considerações

Confira outras considerações:

  • Quando você copia um backup de uma instância de origem para uma instância de destino, ele existe independentemente do backup de origem. Quando a operação de cópia for concluída, haverá um backup na instância de origem e um backup na instância de destino. Se você não precisa mais do backup na instância de origem, é possível excluí-lo.
  • Quando você copia um backup para uma instância regional, os dados de backup são copiados para cada uma das três zonas de leitura e gravação na instância de destino.
  • Quando você copia um backup para uma instância multirregional, os dados de backup são copiados para cada zona na instância que contém uma réplica de leitura/gravação ou somente leitura.
  • É possível copiar vários backups ao mesmo tempo.
  • É possível atualizar ou excluir o backup de destino enquanto um processo de cópia ainda está em andamento. Se você excluir o backup de destino, a operação de cópia em andamento será cancelada.
  • É possível restaurar um backup na instância de origem enquanto há uma operação de cópia em andamento.
  • É possível cancelar uma operação de cópia antes que ela seja concluída.

As seguintes operações não são permitidas durante o processo de cópia:

  • Não é possível excluir o backup de origem enquanto uma operação de cópia está em andamento.
  • Não é possível iniciar uma nova cópia ou restauração no backup copiado de destino enquanto a cópia ainda está em andamento. Depois de concluída, a cópia pode ser copiada novamente ou restaurada.

Onde os backups do Spanner são armazenados

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 de 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 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.

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.

Por padrão, um backup copiado usa a mesma configuração de criptografia, gerenciada pelo Google ou gerenciada pelo cliente (CMEK, na sigla em inglês), que a criptografia do backup de origem. É possível modificar esse comportamento especificando uma configuração de criptografia diferente ao copiar o backup. Se você quiser que o backup copiado seja criptografado com CMEK ao copiar entre regiões, especifique a chave KMS correspondente à região de destino.

Desempenho

Nesta seção, descrevemos o desempenho ideal do backup no Spanner.

Desempenho ao fazer backup

Ao executar um backup, o Spanner cria um job 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. Esse job de backup não usa recursos de CPU alocados à 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.

Geralmente, 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. Esse processo pode levar até 30 minutos. Recomendamos não cancelar e reiniciar o backup, porque é provável que você encontre o mesmo atraso de programação com a nova operação de backup.

Desempenho ao copiar um backup

O tempo necessário para copiar um backup depende de fatores como o tamanho do backup de origem e a região de destino escolhida para o backup copiado. Geralmente, a maioria das cópias é concluída em 1 a 4 horas. Algumas cópias podem demorar mais, dependendo do tamanho do backup e da região de destino. A cópia de um backup não afeta o desempenho da instância ou do banco de dados de origem. É possível fazer várias cópias simultâneas do backup de origem para instâncias em diferentes regiões sem problemas de impacto no desempenho.

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 backup é concluída e continua até que o backup seja excluído. Um backup concluído é cobrado pelo mínimo de 24 horas. Se você criar um backup e excluí-lo um minuto depois de terminar, você ainda será cobrado por 24 horas.

Uma cópia de um backup está sujeita aos mesmos custos de armazenamento do backup original. Se você criar uma cópia entre duas instâncias que ocupam regiões diferentes, serão aplicados custos de transferência de dados de saída.

Por exemplo, se você copiar o banco de dados da configuração da instância multirregional de origem nam7 para a configuração da instância multirregional de destino nam-eur-asia3, as seguintes cobranças serão aplicadas:

  • Sem custo financeiro para a região us-central1 sobreposta
  • Sem custo financeiro para a região us-central2 das testemunhas
  • A cobrança da transferência de dados intercontinental é aplicada duas vezes: uma para cada novo continente (Europa e Ásia)
  • A cobrança da transferência de dados entre regiões no mesmo continente é aplicada uma vez para us-east1
  • A cobrança da transferência de dados entre regiões dentro do mesmo continente é aplicada uma vez na Europa

O Spanner otimiza o processo de cópia para minimizar o número de transferências entre regiões. Isso ajuda a minimizar os custos de transferência de dados e oferece uma experiência rápida de backup de cópia.

Os backups são armazenados e faturados separadamente. O armazenamento de backup não afeta o faturamento para armazenamento de bancos de dados ou os limites de armazenamento de bancos de dados. Para mais informações, consulte também Métricas de utilização do armazenamento.

Para informações mais completas sobre os custos de backup, consulte Preços do Spanner.

A seguir