Backups

Nesta página, mostraremos uma visão geral dos backups do Cloud Bigtable.

Com os backups do Cloud Bigtable, você pode salvar uma cópia do esquema e dos dados de uma tabela para, depois, restaurá-los em uma nova tabela a partir do backup. Antes de ler esta página, é preciso conhecer a Visão geral do Cloud Bigtable e o Gerenciamento de tabelas.

Para que servem os backups

Os backups podem ajudar você a recuperar dados corrompidos no nível do aplicativo ou por erros do operador, como a exclusão acidental de uma tabela.

Para que não servem os backups

Os backups não se destinam a proteger contra falhas regionais ou zonais. Use a replicação se precisar fazer o failover para diferentes regiões ou zonas.

Como os backups não são legíveis, eles não servem para análises off-line.

Principais recursos

  • Totalmente integrado: os backups são processados totalmente pelo serviço do Cloud Bigtable, sem a necessidade de importar ou exportar.
  • Economia de custos: o uso de backups do Cloud Bigtable permite evitar custos associados à exportação, armazenamento e importação de dados usando outros serviços.
  • Eficiência de armazenamento: os backups são incrementais. O armazenamento é otimizado para que cada backup capture apenas os dados que foram alterados desde o backup anterior.
  • Expiração automática: cada backup tem uma data de validade definida pelo usuário que pode ser de até 30 dias após a criação do backup.

Como trabalhar com backups

Consulte Como gerenciar backups para ver instruções passo a passo sobre como fazer um backup e restaurar uma tabela, além de operações para atualizar e excluir backups.

Use os seguintes instrumentos para trabalhar com backups do Cloud Bigtable:

Você também pode acessar a API diretamente, mas recomendamos fazer isso apenas se não for possível usar uma biblioteca de cliente do Cloud Bigtable que faça chamadas de backup para a API.

Como os backups funcionam

Armazenamento

Um backup de tabela é um recurso no nível do cluster. Mesmo que a tabela esteja em uma instância com vários clusters (ou seja, o cluster está usando replicação), cada backup é criado e armazenado em apenas um cluster da instância.

Backup armazenado em um único cluster

O backup de uma tabela inclui todos os dados que estavam na tabela no momento em que o backup foi criado, no cluster em que o backup foi criado. O backup nunca é maior que o tamanho da tabela de origem no momento em que o backup foi criado. É possível criar até 50 backups por tabela por cluster.

Você pode excluir uma tabela que tenha um backup. Para proteger seus backups, não é possível excluir um cluster que contenha um backup e não é possível excluir uma instância que tenha um ou mais backups em qualquer cluster.

O backup continua existindo depois de ter sido restaurado para uma nova tabela. Você pode excluir ou deixar o backup expirar quando não precisar mais dele. O armazenamento de backup não é contabilizado no limite de armazenamento do nó de um projeto.

Os dados dos backups são criptografados e armazenados usando um formato proprietário.

Custos

Não há cobrança para criar ou restaurar um backup.

Para armazenar um backup, existe uma taxa de armazenamento de backup padrão, cobrada de acordo com a região em que o cluster que contém o backup está localizado.

Os backups do Bigtable otimizam o uso do armazenamento de backups. Os backups são incrementais. Portanto, a quantidade de armazenamento do seu backup depende da quantidade de divergência de dados em relação ao backup anterior.

Considerações sobre a replicação

Esta seção descreve outros conceitos necessários para entender como fazer backups e restaurar tabelas em uma instância que usa a replicação.

Como fazer backup

Ao fazer o backup de uma tabela em uma instância replicada, você escolhe o cluster em que quer criar e armazenar o backup. Não é necessário interromper a gravação no cluster que contém o backup, mas você precisa saber como as gravações replicadas no cluster são processadas.

Um backup é a cópia de uma tabela no estado em que está no cluster em que o backup está armazenado, no momento em que o backup é criado. Os dados da tabela que ainda não foram replicados de outro cluster na instância não são incluídos no backup.

Cada backup tem um horário de início e de término. As gravações enviadas ao cluster um pouco antes ou durante a operação de backup podem não ser incluídas no backup. Dois fatores contribuem para essa incerteza:

  • A gravação pode ser enviada para uma seção da tabela que o backup já tenha copiado.
  • A gravação em outro cluster pode não ter sido replicada para o cluster que contém o backup.

Em outras palavras, há uma chance de que algumas gravações com um carimbo de data/hora anteriores ao horário do backup possam não estar incluídas no backup. Se isso for inaceitável para os requisitos do seu negócio, use um token de consistência com as solicitações de gravação para garantir que todas as gravações replicadas sejam incluídas em um backup.

Como restaurar

Quando você restaura um backup para uma nova tabela, a replicação de e para os outros clusters na instância é iniciada imediatamente após a conclusão da operação de restauração no cluster em que o backup foi armazenado.

Desempenho

Como fazer backup

A criação de um backup geralmente leva menos de um minuto, mas pode levar até uma hora. Em circunstâncias normais, a criação de backups não afeta o desempenho do serviço.

Para um desempenho ideal, não crie backups de uma tabela em intervalos menores que cinco minutos. Criar backups com mais frequência pode levar a um aumento observável na latência do serviço.

Como restaurar

A restauração de um backup para uma tabela em uma instância de cluster único leva alguns minutos. Em instâncias de vários clusters, a restauração leva mais tempo porque os dados precisam ser copiados para todos os clusters.

Se você armazenar suas tabelas em clusters SSD, poderá inicialmente ter uma latência de leitura maior, mesmo após a conclusão da restauração, enquanto a tabela estiver sendo otimizada. Verifique o status a qualquer momento durante a operação de restauração para ver se a otimização ainda está em andamento.

Controle de acesso

As permissões do IAM controlam o acesso a operações de backup e restauração. As permissões de backup estão no nível da instância e se aplicam a todos os backups da instância. Para criar um backup de uma tabela, é necessário ter permissão para ler a tabela e criar backups na instância em que ela está.

Ação Permissão do IAM obrigatória
Criar backup bigtable.tables.readRows, bigtable.backups.create
Receber um backup bigtable.backups.get
Listar backups bigtable.backups.list
Excluir um backup bigtable.backups.delete
Atualizar um backup bigtable.backups.update
Restaurar um backup para uma tabela bigtable.tables.create, bigtable.backups.restore
Acessar uma operação bigtable.instances.get
Listar operações bigtable.instances.get

Práticas recomendadas

Backups

  • Não faça backup de uma tabela mais do que uma vez a cada cinco minutos.
  • Ao fazer backup de uma tabela que usa replicação, escolha o cluster para armazenar o backup após considerar os seguintes fatores:
    • Custo. Um dos clusters na sua instância pode estar em uma região de custo menor que os outros.
    • Proximidade com seu servidor de aplicativos. É conveniente armazenar o backup o mais próximo possível do aplicativo de serviço.
    • Uso do armazenamento. Você precisa de espaço de armazenamento suficiente para manter seu backup à medida que ele cresce. Dependendo da sua carga de trabalho, você pode ter clusters de tamanhos diferentes ou com uso do disco diferente. Isso pode ser um fator relevante para a escolha do cluster.
  • Se precisar garantir que todas as gravações replicadas sejam incluídas no backup ao fazer backup de uma tabela em uma instância que usa replicação, use um token de consistência com suas solicitações de gravação.

Como restaurar backups

  • Pense no nome da nova tabela com antecedência caso precise restaurá-la de um backup. O principal é estar preparado para que você não precise tomar decisões no momento em que estiver lidando com um problema.
  • Se você estiver restaurando uma tabela por um motivo diferente da exclusão acidental, verifique se todas as leituras e gravações foram para a nova tabela antes de excluir a tabela original.

Cotas e limites

As solicitações de backup e de restauração e o armazenamento de backups estão sujeitos a cotas e limites do Cloud Bigtable.

Limitações

As limitações a seguir são aplicáveis aos backups do Cloud Bigtable:

  • Não é possível ler diretamente de um backup.
  • Não é possível restaurar uma tabela para uma tabela existente ou para uma nova tabela em uma instância diferente.
  • Se você restaurar um backup em uma tabela em um cluster SSD e excluir a tabela recém-restaurada, a exclusão da tabela poderá levar algum tempo para ser concluída porque o Cloud Bigtable espera a conclusão da otimização da tabela.
  • Os backups são zonais e compartilham as mesmas garantias de disponibilidade que o cluster em que o backup foi criado. Os backups não oferecem proteção contra interrupções regionais.
  • Um backup é uma versão de uma tabela em um único cluster em um horário específico. Os backups não representam um estado consistente. O mesmo se aplica aos backups da mesma tabela em clusters diferentes.
  • Não é possível fazer backup de mais de uma tabela em uma única operação.
  • Não é possível exportar, copiar ou mover um backup do Cloud Bigtable para outro serviço, como o Cloud Storage.

A seguir