Visão geral dos backups

O backup do Spanner permite criar backups os bancos de dados do Spanner sob demanda e os restaura para fornecer proteção contra erros de operadores e aplicativos que resultam em dados lógicos corrupção. Os backups são altamente disponíveis, criptografados e podem ser retidos por até para um ano a partir do momento da criação. Quando você cria um backup, ele reside na mesma instância, região e projeto que o banco de dados de origem. Se você restaurar o backup em uma região ou projeto diferente para fins de compliance ou por motivos de continuidade dos negócios, é possível copiar o backup para uma instância em uma região ou um projeto separado. Para reter backups por mais de um ano, recomendamos exportar seu banco de dados. Para proteção contra ataques lógicos corrupção de dados, o Spanner também oferece recuperação pontual. Você também pode ativar o banco de dados proteção contra exclusão para impedir exclusão acidental de bancos de dados.

Principais recursos

  • Consistência de dados: os backups são um processo consistente externamente cópia 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, a é armazenado em todas as zonas que contêm uma zona de leitura/gravação réplica. Se for preciso armazenar o backup do banco de dados em um lugar região ou projeto, é possível copiar o backup concluído da para uma instância de destino localizada em uma região diferente ou projeto. 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. Assim, não é possível há um intervalo entre a expiração e a exclusão do backup.

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

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 IAM, papéis e permissões, consulte Visão geral do IAM.

Os recursos de backup são organizados em instâncias no Spanner hierarquia de recursos. Recomendamos que você aplique as políticas do IAM no nível do projeto ou da instância. Se você precisar de um controle mais preciso, As políticas do IAM também podem ser aplicadas no nível do backup e do 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, quando restaurar um banco de dados, ele inicialmente herdará as políticas do banco instância.

Esta seção descreve os papéis predefinidos que têm acesso aos recursos de backup e restaurar dados.

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

  • spanner.backupAdmin: tem acesso para criar, ver, atualizar, copiar e excluir. backups. Esse papel também pode ler e gerenciar as informações do IAM de um backup política. 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á-las ou excluí-las. Esse papel é usado por scripts que automatizar 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. Este 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 completos, 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. Qualquer modificação nos dados ou no esquema após o version_time não estão incluídas no backup. Os backups incluem todas as opções de banco de dados que são definidos com o valor ALTER DATABASE SET OPTIONS mas não inclua o Identity and Access Management (IAM) políticas. Quando você cria um backup, ele reside na mesma instância, e o projeto como banco de dados de origem.

É possível criar um backup das seguintes maneiras:

Ao criar um backup, especifique um banco de dados de origem, um nome para o recurso de backup e uma data de validade (até um ano a partir da criação do backup tempo de resposta). Também é possível especificar version_time, que permite fazer backup seu banco de dados para um momento anterior. O campo version_time normalmente é usados 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 é definido como o create_time do backup. O sistema cria como um recurso de backup e uma operação de backup para rastrear o andamento do backup. O backup recém-criado fica no mesmo instância, região e projeto como banco de dados de origem.

Para garantir a consistência externa do backup, o Spanner fixa conteúdo do banco de dados em create_time. Isso evita que a coleta de lixo sistema de remover os valores de dados relevantes durante o backup operação Depois, cada zona de leitura/gravação e somente leitura na instância começa copiar os dados em paralelo. Se alguma zona estiver temporariamente indisponível, o backup não está completa até que a zona volte a ficar on-line e termine. Os backups são e pode ser restaurado assim que a operação for concluída. Para instâncias multirregionais, todos as zonas somente leitura e de leitura e gravação em todas as regiões precisam concluir o backup réplicas 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ção. Os dados do fluxo de alterações precisam ser transmitidos consumida quase simultaneamente com as mudanças 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 do Spanner de uma instância para outra em uma região ou projeto diferente, para dar mais recursos de conformidade e proteção de dados. O backup copiado tem os mesmos recursos principais da versão original backup. Além disso, é possível restaurar um backup copiado na mesma instância para oferecer suporte entre regiões e de backup e restauração entre projetos.

Casos de uso comuns entre regiões

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

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

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

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

    Por exemplo, você pode copiar um banco de dados de backup em uma instância de destino para para fins de recuperação de desastres com objetivo de tempo de recuperação (RTO) diferente de zero e Objetivo do ponto de recuperação (RPO, na sigla em inglês). Depois, quando necessário, restaure o banco de dados usando o backup copiado instância de destino. Se o aplicativo tiver RTO e RPO zero de desastres, recomendamos as configurações multirregionais do Spanner planos de recuperação de desastres.

Casos de uso comuns entre projetos

Alguns casos de uso comuns entre projetos para copiar um backup incluem o seguintes:

  • Manter uma cópia de backup em um projeto separado para atender a requisitos ou requisitos de conformidade.

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

    Por exemplo, se você quiser migrar dados do projeto de produção para um projeto, você pode criar um backup de seus dados de produção e, em seguida, copiar no projeto de teste. Quando a operação de cópia é concluída, restaurar o backup copiado em uma instância no projeto de teste.

  • Mova seu banco de dados de um projeto para outro (observe que pode haver alguns o tempo de 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 para um ano a partir do horário de criação do backup de origem. Isso significa que o valor expiration_date precisa ser de pelo menos seis horas a partir do momento em que a cópia atual solicitação é processada e, no máximo, 366 dias após o backup create_time de origem.

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 a instância de destino. Se uma zona estiver temporariamente indisponível, a cópia de backup não é concluído até que a zona volte a ficar on-line. Não é possível a instância de destino durante a cópia. Para acompanhar o progresso e de conclusão da operação de backup, siga as etapas em Mostrar backup progresso. Após a conclusão da cópia, é possível excluir o backup de origem se você não precisar mais. 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, é preciso configurar a instância de destino primeiro. O destino é aquela em que reside a cópia do backup. Pode ser pequeno como 100 unidades de processamento precisam ter a mesma configuração de instância da origem (a instância em que fica o backup de origem). Antes de restaurar, certifique-se de que o instância de destino tem nós ou unidades de processamento suficientes provisionados para dar suporte 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 2 nós para restaurar um backup de 8 TB). Para criar uma 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, a backup copiado existe independentemente do backup de origem. Depois que a cópia operação estiver concluída, haverá um backup na instância de origem e outro na instância de destino. Se você não precisar do backup na origem instância, poderá excluí-la.
  • Quando você copia um backup para uma instância regional, os dados de backup são copiados para cada 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 a cada zona na instância que contém uma zona de leitura/gravação réplica.
  • É possível copiar vários backups ao mesmo tempo.
  • É possível atualizar ou excluir o backup de destino enquanto um processo de cópia está em andamento. Se você excluir o backup de destino, a cópia em andamento será cancelada como resultado.
  • É possível restaurar um backup na instância de origem enquanto há uma cópia operação 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 copiado novamente ou restaurado.

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 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 não é possível excluir uma instância do Spanner backups. Se quiser excluir a instância, recomendamos restaurar a backup e exportar o banco de dados restaurado, antes excluindo o backup e a instância.

Encryption

Os backups do Spanner, assim como bancos de dados, são criptografados criptografia gerenciada pelo Google ou pelo cliente. Por padrão, um backup usa mesma configuração de criptografia como seu banco de dados, mas é possível substituir esse comportamento especificando uma configuração de criptografia ao criar o backup. Se o backup for ativado para CMEK, ela é criptografada com a versão principal da chave KMS no momento do backup criação. 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) como origem na criptografia de backup. É possível modificar esse comportamento especificando uma chave de criptografia diferente ao copiar o backup. Se você quiser que o backup copiado seja criptografado com CMEK ao copiar entre regiões, especifique o KMS chave correspondente à região de destino.

Desempenho

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

Desempenho ao fazer backup

Ao fazer um backup, o Spanner cria um job de backup para copiar diretamente do banco de dados para o armazenamento de backup e dimensiona esse job com base o tamanho do banco de dados. Este job de backup não usa recursos de CPU alocados à instância do banco de dados para que não afete 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 a operação de backup. Para acompanhar o progresso e a conclusão de um backup operação, consulte Mostrar progresso do backup.

Geralmente, a maioria dos backups leva de 1 a 4 horas. Alguns backups podem demoram mais devido ao tamanho ou porque há uma fila interna para do Google Cloud. Se um backup estiver demorando mais do que o normal quando nenhum outro fator alterado, isso pode ser devido a um atraso na programação da tarefa de backup em uma zona. Esse processo pode levar até 30 minutos. Recomendamos que você não cancele e reinicie o backup, porque é provável que você se depare com as mesmas atraso 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 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. Copiando 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 as instâncias em regiões diferentes sem problemas no desempenho.

Preços

A cobrança é feita com base na quantidade de armazenamento usado pelos backups por unidade. tempo de resposta. O faturamento começa quando a operação de backup é concluída e vai continuar até que o backup seja excluído. Um backup concluído é cobrado pelo menos de 24 horas. Se você criar um backup e excluí-lo um minuto depois de terminar, você ainda será cobrado por 24 horas.

A cópia de um backup está sujeita aos mesmos custos de armazenamento. como backup original. Se você criar uma cópia entre duas instâncias que ocupam diferentes regiões, os custos da transferência de dados de saída se aplicam.

Por exemplo, se você copiar o banco de dados da instância multirregional de origem configuração 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 fornecendo uma experiência de backup de cópia rápida.

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

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

A seguir