Backup e restauração

Visão geral

O Backup e restauração do Cloud Spanner permite criar backups de bancos de dados do Cloud Spanner sob demanda e restaurá-los para fornecer proteção contra erros de operador e aplicativo, o que resulta em dados corrompidos. Os backups são altamente disponíveis, criptografados e podem ser retidos por até um ano a partir do momento da criação. Se você precisar de tempos de retenção mais longos, recomendamos exportar seu banco de dados.

Você pode usar o Backup e restauração das seguintes maneiras:

Principais recursos

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

  • Replicação: os backups residem na mesma instância do banco de dados de origem e são replicados nos mesmos locais geográficos. Para instâncias regionais, uma cópia do backup é armazenada em cada uma das três zonas de leitura e gravação. Para instâncias multirregionais, uma cópia é armazenada em todas as zonas que contêm uma réplica de leitura / gravação ou somente leitura.

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

Escolher entre Backup e Restauração ou Importar e Exportar

A importação e a exportação do Cloud Spanner atendem a casos de uso semelhantes aos do Backup e restauração. A tabela a seguir descreve semelhanças e diferenças entre elas para ajudar você a decidir qual usar.

Backup e restauraçãoImportar e exportar
Consistência de dados Os backups e os bancos de dados exportados são consistentes de maneira transacional e externa.
Impacto no desempenho Ambos são executados com baixa prioridade para minimizar o impacto no desempenho do banco de dados. A exportação usa a CPU de baixa prioridade do usuário, enquanto o backup usa a CPU de baixa prioridade do sistema. Para mais informações, consulte prioridade de tarefas.
Formato de armazenamento Usa um formato reservado e criptografado projetado para restauração rápida. Compatível com os formatos de arquivo CSV e Avro.
Portabilidade Os backups residem na mesma instância do banco de dados de origem e não podem ser movidos.

Você pode restaurar um banco de dados para qualquer instância no projeto com a mesma configuração de instância do backup.
Os bancos de dados exportados residem no Google Cloud Storage, e os dados podem ser migrados para qualquer sistema compatível com CSV ou Avro.
Retenção Os backups podem ser mantidos por até um ano. Os bancos de dados exportados são armazenados no Cloud Storage, onde, por padrão, são retidos até serem excluídos. Você pode personalizar as políticas de ciclo de vida e retenção.
Cobrança Os backups são cobrados no projeto do Cloud Spanner com base no armazenamento usado por unidade de tempo. Para mais detalhes, consulte a seção Faturamento. O faturamento para importação e exportação é mais complicado devido ao uso do Google Cloud Storage e do Dataflow. Para mais informações, consulte Preços de exportação e importação de banco de dados.
Tempo de restauração A restauração acontece em duas operações: restaurar e otimizar. A operação de restauração oferece um rápido tempo para o primeiro byte, porque o banco de dados monta diretamente o backup sem copiar os dados. Após a conclusão da operação de restauração, o banco de dados estará pronto para uso, embora a latência de leitura possa ser um pouco maior durante a otimização. Para mais informações, consulte Como a restauração funciona. A importação é mais lenta. Você precisa aguardar a gravação de todos os dados no banco de dados.

Como o backup funciona

Índice

Os usuários podem criar um backup de qualquer banco de dados do Cloud Spanner. Esses backups são concluídos, porque contêm todos os dados no banco de dados (incluindo o esquema e os índices secundários) no create_time do backup. Qualquer modificação nos dados ou no esquema após a criação do backup não será incluída no backup. Os backups não contêm metadados de banco de dados, como políticas de gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Processo de criação

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 momento da criação 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.

Para garantir a consistência externa do backup, o Cloud Spanner fixa o conteúdo do banco de dados no momento da criação. 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 na instância começa a copiar os dados em paralelo. Se uma zona estiver temporariamente indisponível, o backup não será concluído até que a zona fique on-line novamente e termine. Os backups são restauráveis assim que a operação é concluída.

Hierarquia de recursos

Os backups são recursos no Cloud 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 formulário projects/<project>/instances/<instance>/backups/<backup>. Um backup continua existindo mesmo depois que o banco de dados de origem é excluído, mas não pode durar mais que a instância pai. Para evitar a exclusão acidental de backups, não é possível excluir uma instância do Cloud Spanner se houver backups. Para usuários que querem 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

O tempo necessário para criar um backup depende de vários fatores, mas é determinado principalmente pelo tamanho do banco de dados em comparação com o número de nós. Se você precisar de tempos de backup mais rápidos, poderá aumentar o número de nós, mas lembre-se de que as alterações na contagem de nós entram em vigor nos backups subsequentes.

A criação de backup também usa CPU inativa. Portanto, verifique se o uso da CPU está dentro das diretrizes recomendadas. A sobrecarga da CPU pode resultar em tempos de backup muito longos e também afetar negativamente a latência do banco de dados.

A CPU em uma instância é compartilhada por todos os backups em andamento na instância. Criar backups de diferentes bancos de dados na mesma instância ao mesmo tempo pode resultar em longos tempos de backup.

Como funciona a restauração

Ao restaurar, especifique um backup de origem e um novo banco de dados de destino. Não é possível restaurar para um banco de dados existente. O novo banco de dados precisa estar no mesmo projeto que o backup e em uma instância com a mesma configuração de instância que o backup. Por exemplo, se um backup estiver em uma instância configurada us-west3, ele poderá ser restaurado para qualquer instância no projeto que também esteja configurada us-west3. A contagem de nós das instâncias não precisa ser a mesma. O banco de dados restaurado terá todos os dados e o esquema do banco de dados original no create_time do backup. Ele não terá permissões do IAM (exceto as herdadas da instância que contém o banco de dados restaurado), e os usuários deverão aplicar as permissões apropriadas do IAM após a conclusão da restauração. O processo de restauração foi projetado para alta disponibilidade, já que o banco de dados pode ser restaurado, desde que a maioria das regiões e zonas da instância esteja disponível.

É importante entender que um banco de dados restaurado faz a transição entre três States que são rastreados por duas operações.

  • Estado CREATING: quando você inicia uma restauração, o sistema cria um novo banco de dados e uma operação de banco de dados de longa duração com RestoreDatabaseMetadata para acompanhar o progresso da restauração. O novo banco de dados começa e permanece no estado CREATING, o que significa que ele não está pronto para uso até que a operação de restauração seja concluída. Para fornecer tempos de restauração rápidos (normalmente menos de 10 minutos), a operação de restauração funciona montando os arquivos no backup sem copiá-los para o banco de dados.

  • Estado READY_OPTIMIZING: após a conclusão da operação de restauração, o banco de dados faz a transição para o estado READY_OPTIMIZING. Nesse estado, ele está pronto para uso, mas pode haver algumas latências de leitura um pouco mais altas enquanto o banco de dados lê dados do backup. Qualquer tentativa de excluir o backup falhará enquanto ele ainda estiver em uso para restauração ou otimização de banco de dados.

    Quando a operação de restauração for concluída, você receberá outra operação de banco de dados de longa duração com OptimizeRestoredDatabaseMetadata para acompanhar o andamento da otimização. A operação de otimização copia os dados do backup para o banco de dados. Se você quiser acelerar o processo de otimização, adicione mais nós à instância.

  • Estado READY: após a conclusão da operação de otimização, o banco de dados faz a transição para o estado READY. Nesse momento, o banco de dados restaurado tem um bom desempenho e não faz mais referência ao backup.

Uma instância pode ter no máximo um banco de dados no estado de restauração CREATING. Não será possível restaurar outro backup para a instância até que o banco de dados restaurado faça a transição para o estado READY_OPTIMIZING ou READY.

Cobrança

Você é cobrado com base na quantidade de armazenamento usada por seus 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. Não há cobrança pela restauração de um backup.

Os backups são armazenados e faturados separadamente. O armazenamento de backup não afeta o faturamento para armazenamento do banco de dados nem os limites de armazenamento do banco de dados.

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, ainda será cobrado por 24 horas.

Para informações mais completas sobre os custos de backup, consulte a página Preços do Cloud Spanner.

Controle de acesso (IAM)

Com o IAM, você controla o acesso aos recursos do Cloud Spanner, que incluem backups e bancos de dados restaurados. Se você não tem familiaridade com o IAM, papéis e permissões, consulte Visão geral do IAM para uma introdução.

Os recursos de backup são organizados em instâncias na hierarquia de recursos do Cloud Spanner. Recomendamos aplicar políticas de IAM no nível do projeto ou da instância. Se você precisar de um controle mais granular, as políticas do IAM também poderão 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. Portanto, quando você restaura um banco de dados, ele inicialmente herdará as políticas da instância pai.

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

Os papéis a seguir são projetados especificamente para backup e restauração:

  • spanner.backupAdmin: tem acesso para criar, ver, atualizar e excluir backups. Esse papel também pode ver e gerenciar a política de IAM de um backup. Esse papel não pode restaurar um banco de dados a partir de um backup.
  • spanner.restoreAdmin: tem acesso para restaurar bancos de dados de backups. Se você precisar restaurar um backup para uma instância diferente, aplique esse papel no nível do projeto ou nas duas instâncias. Esse papel não pode criar backups.
  • spanner.backupWriter: tem acesso para criar backups, mas não pode atualizá-los ou excluí-los. Esse papel deve ser usado por scripts que automatizam a criação de backup.

Os seguintes papéis também têm acesso ao backup e à restauração:

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

Para mais informações, consulte IAM do Cloud Spanner.