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, você pode salvar uma cópia do esquema e dos dados de uma tabela e restaurá-los em outra tabela posteriormente. O Bigtable oferece dois tipos de backups. O tipo de backup criado depende dos seus requisitos de recuperação de desastres (DR, na sigla em inglês) e do tipo de armazenamento (HDD ou SSD) usado pelo cluster do Bigtable.
- Os backups padrão são otimizados para retenção de longo prazo. Quando você restaura de um backup padrão para um cluster SSD, a operação de restauração exige otimização adicional do Bigtable para levar a tabela a um desempenho de nível de produção. Para mais informações, consulte Desempenho ao restaurar.
- Os backups dinâmicos oferecem a restauração mais eficiente para o desempenho no nível de produção e a veiculação de baixa latência. Para mais informações, consulte Backups quentes.
É possível criar backups das seguintes maneiras:
- Ative o backup automático para que o Bigtable crie backups diários para você.
- Crie um backup sob demanda usando o console do Google Cloud, a CLI gcloud ou uma biblioteca de cliente do Bigtable.
- 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 automático: ative o backup automático para que o Bigtable crie backups diários.
- Backups quentes: planeje a recuperação de desastres com backups quentes prontos para produção.
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 um 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, seus dados ainda estejam disponíveis. | Ative o backup automático para que o Bigtable crie um backup diário em todos os clusters da instância. Como alternativa, crie backups regularmente e, 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. | Ative a replicação e o backup automatizado para criar backups diários em várias regiões. Assim, se uma tabela for corrompida em um cluster, você terá um ou mais backups que não compartilham o armazenamento no cluster corrompido. | Restaure o backup em uma nova tabela no novo cluster ou instância. Em seguida, grave um aplicativo usando uma biblioteca de cliente do Bigtable ou o Dataflow, 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. |
| Recuperação rápida : restaure rapidamente os níveis de desempenho de produção total, minimizando o tempo de inatividade. | Sempre mantenha um backup ativo recente da tabela. | Restaure uma nova tabela do backup em funcionamento e redirecione as solicitações para a nova tabela. |
Backups dinâmicos
Um backup dinâmico é um backup pronto para produção otimizado para recuperação rápida, com latência menor ao ler da nova tabela logo após a restauração. A restauração do desempenho de produção a partir de um backup dinâmico é mais rápida do que a restauração de um backup padrão.
É possível converter um backup ativo em um padrão, mas não é possível converter um backup padrão em um ativo.
Não é possível criar backups quentes usando o backup automático nem criar um backup quente em um cluster de HDD.
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.
|
||
| Ação | Opções de destino | |
|---|---|---|
| Criar um backup padrão |
|
|
| Criar um backup dinâmico |
|
|
| Restaurar de um backup padrão ou ativo para uma nova tabela |
|
|
| Copiar um backup1, 2 |
|
|
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.
Armazenamento de backup
Um backup de tabela criado sob demanda é armazenado em um único cluster especificado. Quando o backup automático está ativado, um backup é criado e armazenado em todos os clusters da 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 padrão são incrementais. A quantidade de armazenamento que um backup padrão 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.
Já um backup ativo é uma cópia completa que consome a mesma quantidade de armazenamento no momento do backup, não importa o quanto a tabela de origem mude. O backup é considerado quente devido ao armazenamento otimizado, que permite restaurar de forma eficiente os níveis de desempenho de produção.
É 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 mudar o período de armazenamento de um backup para mantê-lo por até 90 dias após a criação.
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 mais informações, 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
Os custos de armazenamento são diferentes para backups padrão e backups quentes.
Custos de armazenamento de backup padrão
Para armazenar um backup padrão 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 padrão é uma cópia lógica completa de uma tabela. Nos bastidores, o Bigtable otimiza o uso do armazenamento de backup padrão. Essa otimização significa que um backup padrão é 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 integradas ao Bigtable, o custo para armazenar um backup padrão ou uma cópia de um backup pode ser menor do que o custo de uma cópia física completa do backup da tabela.
Em instâncias replicadas em que o backup automatizado está ativado, os custos de armazenamento podem ser mais altos porque um backup é criado diariamente em cada cluster.
Custos de armazenamento de backup dinâmico
Para armazenar um backup ativo, é cobrada a taxa de armazenamento de backup ativo da região em que o cluster que contém o backup ativo está localizado.
Como um backup dinâmico é armazenado em um estado pronto, otimizado para restauração rápida, você é cobrado pelo armazenamento de toda a cópia lógica da tabela, e não por partes incrementais, como em um backup padrão.
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 o 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 automático ativado, um backup diário é criado em cada cluster na instância.
Não é necessário interromper a gravação no cluster que contém o backup, mas você precisa entender como o Bigtable processa as gravações replicadas no cluster.
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 carimbos de data/hora anteriores ao horário do backup possam não estar incluídas no backup.
Se essa inconsistência for inaceitável para os requisitos de negócios, 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.
Os backups de tabelas replicadas criados como parte do backup automatizado não são cópias exatas uns dos outros, porque os tempos de backup podem variar de cluster para cluster.
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.
Performance
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 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 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.