O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Visão geral dos backups do Bigtable

Nesta página, mostramos uma visão geral dos backups do Bigtable. O conteúdo apresentado aqui é destinado a administradores e desenvolvedores do Bigtable.

Os backups permitem salvar uma cópia do esquema e dos dados de uma tabela e restaurá-los do backup para uma nova tabela posteriormente. O Bigtable oferece os seguintes tipos de backups que dependem dos requisitos de recuperação de desastres (DR, na sigla em inglês) e do tipo de armazenamento (HDD ou SSD) que o cluster do Bigtable usa.

Os backups padrão são otimizados para retenção a 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 ao 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 desempenho da produção e veiculação de baixa latência. Para mais informações, consulte Backups dinâmicos.

É possível criar backups das seguintes maneiras:

Ative o backup automatizado para que o Bigtable crie backups diários para você.
Crie um backup sob demanda usando o Google Cloud console, a CLI gcloud ou uma biblioteca de cliente do Bigtable.
Criar uma cópia de um backup.

Antes de ler esta página, consulte as seções Visão geral do Bigtable e Gerenciar tabelas.

Recursos

Os backups do Bigtable oferecem os seguintes recursos e benefícios:

Totalmente integrado: o Bigtable processa backups sem a necessidade de importar ou exportar dados.
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 um período de armazenamento definido pelo usuário. Para mais informações, consulte a seção Retenção deste documento.
Opções de restauração flexíveis: restaure de um backup para uma tabela em uma instância diferente de onde o backup foi criado.
Backup automatizado: ative os backups automatizados para que o Bigtable crie backups diários.
Backups dinâmicos: os backups dinâmicos prontos para produção permitem que você planeje a recuperação de desastres.

Casos de uso

Os snapshot são úteis para os seguintes casos de uso:

Continuidade de negócios
Conformidade regulatória
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.	Ative o backup automatizado 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 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 lê a 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 completos, minimizando o tempo de inatividade.	Configure backups automatizados para criar backups dinâmicos diários ou crie backups dinâmicos sob demanda para garantir que você sempre tenha um backup dinâmico recente da sua tabela.	Restaure uma nova tabela do backup dinâmico 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 menor latência ao ler da nova tabela logo após a restauração. A restauração do desempenho de produção de um backup dinâmico é mais rápida do que a restauração de um backup padrão.

É possível criar um backup dinâmico sob demanda sempre que necessário ou configurar uma política de backup automatizado para criar backups dinâmicos diários:

Backups dinâmicos sob demanda: definir um tempo de transição de dinâmico para padrão é opcional. Se você não definir um tempo de transição, o backup vai permanecer quente até expirar. Para fazer a transição automática do backup para um backup padrão, defina um horário de transição pelo menos 24 horas após o horário de início da criação do backup. Também é possível definir ou modificar esse horário mais tarde. Para mais informações, consulte Criar um backup dinâmico e Modificar um backup ou uma cópia de backup.
Backups automáticos dinâmicos: é necessário definir uma duração de retenção dinâmica. Para ativar backups automatizados em uma instância de SSD, especifique uma duração de 24 horas a 10 dias, sem exceder o período de armazenamento da política. Essa configuração determina por quanto tempo cada backup diário permanece dinâmico antes de fazer a transição automática para um backup padrão pelo restante do período de armazenamento. Para mais informações, consulte Configurar backups automatizados ativos.

Manter o backup mais recente ativo

Para equilibrar a recuperação rápida de desastres com os custos de armazenamento, mantenha apenas o backup mais recente como dinâmico e armazene os backups mais antigos como padrão:

Backups diários automatizados: configure uma política de backup automatizado com uma duração de armazenamento de 24 horas ou 1 dia no console do Google Cloud . Como o Bigtable cria um backup automatizado a cada 24 horas, cada backup diário permanece dinâmico até que o próximo backup diário seja criado e, em seguida, faz a transição automática para um backup padrão pelo restante do período de armazenamento. Para instruções, consulte Configurar backups automatizados em hot.
Backups sob demanda: ao criar backups dinâmicos em uma programação recorrente, defina o tempo de transição de dinâmico para padrão de cada backup para quando o próximo backup dinâmico estiver programado (pelo menos 24 horas após o horário de início da criação do backup). Quando esse tempo é atingido, o backup mais antigo faz a transição automática para um backup padrão, enquanto o backup mais recente permanece dinâmico. Para instruções, consulte Criar um backup dinâmico.

Limitações dos backups dinâmicos

Os backups dinâmicos têm as seguintes limitações:

É possível converter um backup dinâmico em um backup padrão, mas não é possível converter um backup padrão em um backup dinâmico.
É possível criar backups dinâmicos sob demanda e configurar backups automáticos dinâmicos apenas para tabelas em instâncias de SSD. Não é possível criar backups dinâmicos em instâncias de HDD.
O Bigtable não oferece suporte a backups dinâmicos para tabelas com armazenamento em níveis ativado. Para mais informações, consulte Visão geral do armazenamento em níveis.
A cópia de um backup dinâmico é sempre um backup padrão. A cópia de backup não tem a mesma restauração rápida para desempenho da produção e veiculação de baixa latência que o backup dinâmico original.

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
Não é possível criar uma cópia de uma cópia do backup. A cópia de um backup é sempre um backup padrão, mesmo que a origem seja um backup dinâmico.
Criar um backup padrão	Qualquer cluster na mesma instância da tabela de origem
Criar um backup dinâmico	Qualquer cluster na mesma instância da tabela de origem. A instância precisa usar o armazenamento SSD.
Restaurar de um backup padrão ou dinâmico para uma nova tabela	Qualquer instância Qualquer região do Bigtable Qualquer projeto
Copiar um backup^{1, 2}	Qualquer instância Qualquer região do Bigtable Qualquer projeto

Consulte Gerenciar backups para conferir instruções detalhadas 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:

O console do Google Cloud
A Google Cloud CLI
As bibliotecas de cliente do Cloud Bigtable

Armazenamento de backup

Um backup de tabela criado manualmente ou de forma programática é armazenado em um único cluster que você especifica. Quando o backup automatizado está ativado, o Bigtable armazena um backup em cada cluster na instância. Na edição Enterprise Plus, é possível selecionar locais de cluster em que o backup automático está ativado.

Se o cluster exceder os limites recomendados de uso de CPU ou armazenamento ao criar um backup, a criação do backup poderá ser atrasada. Para mais informações, consulte Noções básicas sobre o uso de CPU e disco.

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 o seguinte:

Um cluster que contém um ou mais backups. Para excluir o cluster, é necessário excluir esses backups ou aguardar que eles expirem.
Um cluster configurado como um local na política de backup automatizado de uma tabela. Para excluir o cluster, primeiro atualize a política de backup automático para remover o local do cluster ou desative o backup automático da tabela.
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

Os backups do Bigtable permitem reter os dados por um período especificado. É possível configurar o período de armazenamento para backups individuais ou como parte de uma política de backup automatizado:

O período de armazenamento começa no momento em que o backup é criado.
O período de armazenamento padrão para tabelas com backup automatizado ativado é de sete dias.
É possível configurar um período de armazenamento personalizado para uma política de backup automatizado de até 90 dias nas edições Enterprise e Enterprise Plus. Para backups individuais sob demanda ou quando você atualiza um período de armazenamento de um backup, é possível especificar até 90 dias na edição Enterprise ou até 365 dias na edição Enterprise Plus.
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.
Ao criar um backup, é possível especificar uma data de validade em vez de um período de armazenamento. Uma data de validade é uma data e hora absolutas, enquanto um período de armazenamento especifica uma duração. Os dois métodos resultam em um prazo de validade que segue as mesmas regras e limitações.
A transição de um backup dinâmico para um backup padrão não altera o período de armazenamento ou o prazo de validade. Para backups dinâmicos sob demanda, definir um tempo de transição de dinâmico para padrão é opcional, enquanto os backups automáticos dinâmicos exigem uma duração de manutenção dinâmica.

É possível mudar o período de armazenamento de um backup ou de uma política de backup automatizado. Para mais informações, consulte Modificar um backup ou uma cópia de backup e Atualizar uma política de backup automatizado.

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 dinâmicos.

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 integrado 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 de tabela.

Em instâncias replicadas em que o backup automatizado está ativado, os custos de armazenamento podem ser maiores porque os backups diários são criados em cada cluster. Na edição Enterprise Plus, é possível reduzir esses custos ativando backups automatizados apenas para clusters em locais específicos.

Custos de armazenamento de backup dinâmico

Para armazenar um backup dinâmico, há uma taxa de armazenamento de backup dinâmico, cobrada de acordo com a região em que o cluster que contém o backup 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, em vez de partes incrementais, como acontece com um backup padrão.

Quando um backup dinâmico faz a transição para um backup padrão, incluindo quando a duração de manutenção do backup dinâmico automatizado expira, é cobrada a taxa de armazenamento de backup dinâmico enquanto o backup está ativo e a taxa de armazenamento de backup padrão após a transição. Não há cobrança de taxa adicional pela transição em si. Para verificar a duração de manutenção configurada para uma tabela, consulte Ver a política de backup automatizado. Para mais informações sobre as taxas de armazenamento de backup, consulte Preços.

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ê restaurar em uma instância diferente daquela em que o backup foi criado, e a instância do backup e a de destino não tiverem pelo menos um cluster na mesma região, será cobrado um custo único pela cópia de dados inicial para o cluster de destino de acordo 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 dela não podem ser modificadas, mesmo que a chave do KMS seja alternada.

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 automatizado ativado, um backup diário é criado em cada cluster na instância. Na edição Enterprise Plus, é possível limitar o backup automatizado a clusters apenas em locais específicos.

Não é necessário interromper a gravação no cluster que contém o backup, mas você precisa saber 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.
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 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 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.

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

Antes de criar uma estratégia de backup, considere as práticas recomendadas a seguir. Para mais informações sobre o plano de recuperação de desastres, consulte a seção do Bigtable de Como arquitetar a recuperação de desastres para falhas temporárias na infraestrutura em nuvem.

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 depois de 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.
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 importante é se preparar com antecedência para não precisar tomar decisões enquanto lida 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 estão indo para a nova tabela antes de excluir a original.
Se você planeja restaurar para uma instância diferente, crie a instância de destino antes de iniciar a operação de restauração de backup.
Para evitar a restauração lenta de tabelas, aguarde a conclusão de uma operação de restauração antes de iniciar outra para a mesma tabela de origem na mesma zona.
Aguarde pelo menos uma hora após a criação antes de restaurar um backup padrão. Se você precisar restaurar mais rapidamente, use um backup dinâmico.

Cotas e limites

As solicitações de backup e restauração e o armazenamento de backup estão sujeitos às 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.
Não é possível criar um backup de uma visualização.

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 de um backup para 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.