Visão geral dos backups do Bigtable
Esta página fornece uma visão geral dos backups do Bigtable. O conteúdo apresentado aqui é destinado a administradores e desenvolvedores do Bigtable.
Com os backups do Bigtable, é possível salvar uma cópia do esquema e dados de uma tabela para, depois, restaurar do backup em uma nova tabela. É possível criar backups manualmente ou ativar o backup automatizado para permitir que o Bigtable crie backups diários. Também é possível criar uma cópia de um backup.
Antes de ler esta página, familiarize-se com a Visão geral do Bigtable e Gerencie tabelas.
Recursos
- Totalmente integrado: os backups são processados totalmente pelo serviço do Bigtable, sem a necessidade de importar ou exportar.
- Incremental: um backup compartilha o armazenamento físico com a tabela de origem e com outros backups da tabela.
- Economia de custos: o uso de backups do Bigtable permite evitar custos associados à exportação, armazenamento e importação de dados usando outros serviços.
- Expiração automática: cada backup tem uma data de validade definida pelo usuário que pode ser de até 90 dias após a criação do backup. É possível armazenar uma cópia de um backup por até 30 dias.
- Opções de restauração flexíveis: é possível restaurar de um backup para uma tabela em uma instância diferente de onde o backup foi criado.
- Backup automatizado: ative o backup automatizado para permitir que o Bigtable crie backups diários.
Casos de uso
Os snapshot são úteis para os seguintes casos de uso:
- Continuidade dos negócios
- Conformidade com as normas
- Teste e desenvolvimento
- Recuperação de desastres
Considere os seguintes cenários de recuperação de desastres:
| Meta | Estratégia de backup | Estratégia de restauração |
|---|---|---|
| Proteção contra erros humanos: tenha sempre em mãos o backup recente dos dados em caso de exclusão ou corrupção acidental. | Determine a programação de criação de backups adequada às suas necessidades de negócios, como as diárias. Opcionalmente, crie cópias periódicas dos backups e armazene-os em um projeto ou região diferente para maior isolamento e proteção. Para ter ainda mais proteção, armazene as cópias de backup em um projeto ou instância com permissões de acesso restritas. | Restaure uma cópia de backup ou cópia em uma nova tabela e redirecione as solicitações para a nova tabela. |
| Indisponibilidade da zona: é necessário garantir que, no caso improvável de uma zona do Google Cloud ficar indisponível, os dados ainda estejam disponíveis. | Crie backups regularmente, todos os dias. Em seguida, crie periodicamente uma cópia do backup mais recente e armazene-a em um ou mais clusters em zonas diferentes (opcionalmente em uma instância ou projeto diferente). | Se a zona em que o cluster de exibição estiver indisponível, restaure a cópia do backup remoto em uma nova tabela e redirecione as solicitações para a nova tabela. |
| Corrupção de dados: use um backup para recuperar alguns dados de uma tabela, como quando parte da tabela de origem for corrompida. | Crie backups dos dados periodicamente. | Restaure o backup em uma nova tabela na nova instância. Em seguida, crie um aplicativo usando uma biblioteca de cliente do Bigtable ou o Datafalow, que faz leituras na nova tabela e grava os dados na tabela de origem. Quando os dados forem copiados para a tabela original, exclua a nova tabela. |
Como trabalhar com backups do Bigtable
As ações a seguir estão disponíveis para backups do Bigtable. Em todos os casos, é preciso que o projeto de destino, a instância e o cluster já existam. Não é possível criar esses recursos como parte de uma operação de backup. Não é possível criar uma cópia de uma cópia de backup.
| Ação | Opções de destino |
|---|---|
| Criar backup |
|
| Restaurar de um backup para uma nova tabela |
|
| Copiar um backup |
|
Consulte Gerenciar backups para conferir Instruções passo a passo sobre essas ações, assim como operações como atualização e exclusão de backups.
Use os seguintes instrumentos para trabalhar com backups do Bigtable:
- Console do Google Cloud
- A Google Cloud CLI
- As bibliotecas de cliente do Cloud Bigtable
Também é possível acessar a API Cloud Bigtable Admin diretamente, mas recomendamos que você faça 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 funcionam os backups do Bigtable
A criação de um backup envolve a compreensão do armazenamento e da retenção de backup no Bigtable.
Armazenamento de backup
Um backup de tabela pode ser criado manualmente ou você pode ativar o backup automatizado para permitir que o Bigtable faça backups diários. Um backup de tabela é armazenado em um cluster em uma instância. No caso de backups manuais, o backup de tabela é armazenado em um cluster na instância selecionada. Quando o backup automatizado está ativado, um backup de tabela é armazenado em cada cluster na instância.
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.
Os backups do Bigtable são incrementais. A quantidade de armazenamento que um backup consome depende do tamanho da tabela e da possibilidade dela de compartilhar o armazenamento de dados inalterados com a tabela original ou com outros backups da mesma tabela. Por isso, o tamanho de um backup depende da quantidade de divergência de dados desde o backup anterior.
É possível criar até 150 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 da restauração 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.
Retenção
É possível especificar um período de armazenamento de até 90 dias para um backup. Se você criar uma cópia de um backup, o período de armazenamento máximo da cópia será de 30 dias a partir do momento em que a cópia for criada.
Para tabelas com backup automatizado ativado, o período de armazenamento padrão é de três dias. É possível modificar o período de armazenamento de um backup até 90 dias a partir do momento de criação dele.
Armazenamento pós-restauração
O custo de armazenamento de uma nova tabela restaurada de um backup é o mesmo de qualquer tabela.
Uma tabela restaurada de um backup pode não consumir a mesma quantidade de armazenamento que a tabela original e pode diminuir de tamanho depois da restauração. A diferença de tamanho depende de há quanto tempo a compactação aconteceu no cluster de origem e de destino.
Como a compactação ocorre de maneira contínua, é possível que ela aconteça assim que a tabela for criada. No entanto, a compactação pode levar até uma semana para acontecer.
Uma nova tabela restaurada de um backup não herda as políticas de coleta de lixo da tabela de origem. Configure as políticas de coleta de lixo na nova tabela antes de começar a gravar novos dados nela. Para saber mais, consulte Configurar a coleta de lixo.
Custos
Os custos de rede padrão são aplicáveis ao trabalhar com backups. Você não é cobrado por operações de backup, incluindo criação, cópia ou restauração a partir de um backup.
Custos de armazenamento
Para armazenar um backup ou uma cópia de um backup, é cobrada a taxa de armazenamento de backup padrão de acordo com a região em que o cluster que contém o backup ou a cópia de backup está.
Um backup é uma cópia lógica completa de uma tabela. Em segundo plano, o Bigtable otimiza o uso do armazenamento de backup. Essa otimização significa que um backup é incremental. Ele compartilha o armazenamento físico com a tabela original ou com outros backups da tabela sempre que possível. Devido às otimizações de armazenamento integrado ao Bigtable, o custo para armazenar um backup ou uma cópia de um backup pode ser menor do que o custo de uma cópia física completa do backup de tabela.
Em instâncias replicadas em que o backup automatizado está ativado, os custos de armazenamento podem ser maiores porque os backups são criados em cada cluster diariamente.
Custos ao copiar um backup
Quando você cria uma cópia de um backup em uma região diferente do backup de origem, são cobradas taxas de rede padrão pelo custo de copiar os dados para o cluster de destino. Você não é cobrado pelo tráfego de rede ao criar uma cópia na mesma região do backup de origem.
Custos durante a restauração
Ao restaurar uma nova tabela a partir de um backup, você é cobrado pelo custo de rede da replicação. Se a nova tabela estiver em uma instância que usa replicação, será cobrado um custo de replicação única para que os dados sejam copiados para todos os clusters da instância.
Se você fizer a restauração em uma instância diferente daquela em que o backup foi criado, e se a instância do backup e a instância de destino não tiverem pelo menos um cluster na mesma região, será cobrado um valor único pela cópia inicial de dados no cluster de destino com as taxas de rede padrão.
CMEK
Quando você cria um backup em um cluster protegido por uma chave de criptografia gerenciada pelo cliente (CMEK), o backup é fixado na versão primária da chave CMEK do cluster na tempo que levou. 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 girada
Quando você restaura um backup, a versão de chave fixada ao backup precisa estar ativada para que o processo de descriptografia de backup seja bem-sucedido. A nova tabela é protegida pela versão principal mais recente da chave CMEK para cada cluster na instância de destino. Se você quiser restaurar de um backup protegido por CMEK para uma instância diferente, a instância de destino também precisará ser protegida por CMEK, mas não precisará ter a mesma configuração de CMEK que a instância de origem de dados.
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.
Replicação e backup
Ao fazer um backup de uma tabela manualmente em uma instância replicada, você escolhe o cluster em que quer criar e armazenar o backup. Para tabelas com backup automatizado ativado, um backup diário é feito em cada cluster na instância.
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.
- Uma 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. Isso também vale para backups criados quando o backup automatizado está ativado. Os backups de uma instância não são cópias exatas um do outro, porque o tempo de backup pode variar de cluster para cluster.
Se essa inconsistência for inaceitável para os requisitos do 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.
Replicação e restauração
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 de destino.
Desempenho
Ao criar backups, use as práticas recomendadas a seguir para garantir que o desempenho permaneça ideal.
Desempenho ao 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 um backup com base em uma única tabela mais de uma vez a cada cinco minutos. Criar backups com mais frequência pode levar a um aumento observável na latência do serviço.
Desempenho ao restaurar
A restauração de um backup para uma tabela em uma instância de cluster único leva alguns minutos. Em instâncias replicadas, a restauração leva mais tempo porque os dados precisam ser copiados para todos os clusters. O Bigtable sempre escolhe a rota mais eficiente para copiar dados.
Se você fizer a restauração em uma instância diferente daquela em que o backup foi criado, a operação de restauração levará mais tempo do que se você restaurar na mesma instância. Isso acontece principalmente se a instância de destino não tiver um cluster na mesma zona do cluster em que o backup foi criado.
A restauração de uma tabela maior leva mais tempo do que a de uma tabela menor.
Se você tem uma instância de SSD, pode ocorrer inicialmente uma latência de leitura maior, mesmo após a conclusão da restauração, enquanto a tabela é otimizada. Verifique o status a qualquer momento durante a operação de restauração para ver se a otimização ainda está em andamento.
Se você fizer a restauração em uma instância diferente daquela em que o backup foi criado, a instância de destino poderá usar o armazenamento HDD ou SSD. Não é necessário usar o mesmo tipo de armazenamento que a instância de origem.
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.
A conta usada para criar um backup de uma tabela precisa ter permissão para ler a tabela e criar backups na instância em que a tabela está (a instância de origem).
A conta usada para copiar um backup precisa ter permissão para ler o backup de origem e criar um backup na instância de destino e no projeto.
A conta usada para restaurar uma nova tabela com um backup precisa ter permissão para criar tabelas na instância que será restaurada.
| 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 |
| Copiar um backup | bigtable.backups.read, bigtable.backups.create |
| Restaurar de um backup para uma nova tabela | bigtable.tables.create, bigtable.backups.restore |
| Acessar uma operação | bigtable.instances.get |
| Listar operações | bigtable.instances.get |
Práticas recomendadas
É preciso levar em consideração as práticas recomendadas a seguir antes de criar uma estratégia de backup.
Como criar 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 considerando 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 seus backups à medida que eles se acumulam. 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.
Restaurar a partir de um backup
- 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.
- Caso você planeje fazer a restauração em uma instância diferente, crie a instância de destino antes de iniciar a operação de restauração de backup.
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 Bigtable.
Limitações
As limitações a seguir são aplicáveis aos backups do Bigtable:
Geral
- Não é possível fazer leituras diretamente de um backup.
- 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 Bigtable para outro serviço, como o Cloud Storage.
- Os backups do Bigtable contêm apenas dados do Bigtable e não estão integrados ou relacionados com backups de outros serviços do Google.
Restaurando
- Não é possível restaurar de um backup para uma tabela existente.
- A restauração só é possível em uma instância que já existe. O Bigtable não cria uma nova instância ao restaurar um backup. Se a instância de destino especificada em uma solicitação de restauração não existir, a operação de restauração falhará.
- 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 Bigtable espera a conclusão da otimização da tabela.
Copiar
- Não é possível criar uma cópia de um backup em até 24 horas após a expiração.
- Não é possível criar uma cópia de uma cópia do backup.
CMEK
- Um backup protegido por CMEK precisa ser restaurado para uma nova tabela em uma instância protegida por CMEK.
- Quando você cria uma cópia de um backup protegido por CMEKs, o cluster de destino também precisa ser protegido por CMEKs.