Vista geral das cópias de segurança do Bigtable

Esta página apresenta uma vista geral das cópias de segurança do Bigtable. O conteúdo apresentado aqui destina-se a administradores e programadores do Bigtable.

As cópias de segurança permitem-lhe guardar uma cópia do esquema e dos dados de uma tabela e, em seguida, restaurar a partir da cópia de segurança para uma nova tabela mais tarde. O Bigtable oferece dois tipos de cópias de segurança. O tipo de cópia de segurança que cria depende dos seus requisitos de recuperação de desastres (DR) e do tipo de armazenamento (HDD ou SSD) que o seu cluster do Bigtable usa.

• As cópias de segurança padrão são otimizadas para retenção a longo prazo. Quando restaura a partir de uma cópia de segurança padrão para um cluster de SSDs, a operação de restauro requer uma otimização adicional pelo Bigtable para colocar a tabela no desempenho ao nível da produção. Para mais informações, consulte a secção Desempenho ao restaurar.
• As cópias de segurança a quente oferecem o restauro mais eficiente para o desempenho ao nível da produção e o serviço de baixa latência. Para mais informações, consulte o artigo Cópias de segurança rápidas.

Pode criar cópias de segurança das seguintes formas:

• Ative a cópia de segurança automática para permitir que o Bigtable crie cópias de segurança diárias para si.
• Crie uma cópia de segurança a pedido através da Google Cloud consola, da gcloud CLI ou de uma biblioteca cliente do Bigtable.
• Crie uma cópia de uma cópia de segurança.

Antes de ler esta página, deve conhecer a vista geral do Bigtable e a gestão de tabelas.

Funcionalidades

• Totalmente integrado: as cópias de segurança são processadas totalmente pelo serviço Bigtable, sem necessidade de importação nem exportação.
• Incremental: uma cópia de segurança partilha o armazenamento físico com a tabela de origem e outras cópias de segurança da tabela.
• Rentável: a utilização de cópias de segurança do Bigtable permite-lhe evitar os custos associados à exportação, ao armazenamento e à importação de dados através de outros serviços.
• Expiração automática: cada cópia de segurança tem uma data de validade definida pelo utilizador que pode ser até 90 dias após a criação da cópia de segurança. Pode armazenar uma cópia de uma cópia de segurança durante um máximo de 30 dias.
• Opções de restauro flexíveis: pode restaurar a partir de uma cópia de segurança para uma tabela numa instância diferente daquela em que a cópia de segurança foi criada.
• Cópia de segurança automática: ative a cópia de segurança automática para permitir que o Bigtable crie cópias de segurança diárias.
• Cópias de segurança a quente: planeie a recuperação de desastres com cópias de segurança a quente prontas para produção.

Exemplos de utilização

As cópias de segurança são úteis para os seguintes exemplos de utilização:

• Continuidade do negócio
• Conformidade regulamentar
• Testes e desenvolvimento
• Recuperação de desastres

Considere os seguintes cenários de recuperação de desastres:

Objetivo	Estratégia de cópia de segurança	Estratégia de restauro
Proteja-se contra erros humanos: é recomendável ter sempre uma cópia de segurança recente dos seus dados pronta em caso de eliminação ou dano acidental.	Determine a programação de criação de cópias de segurança adequada às necessidades da sua empresa, como diariamente. Opcionalmente, crie cópias periódicas das cópias de segurança e armazene-as num projeto ou numa região diferente para aumentar o isolamento e a proteção. Para ainda mais proteção, armazene as cópias de segurança num projeto ou numa instância com autorizações de acesso restritas.	Restaurar para uma nova tabela a partir da cópia de segurança ou da cópia e, em seguida, reencaminhar pedidos para a nova tabela.
Indisponibilidade da zona: tem de se certificar de que, na improvável eventualidade de uma Google Cloud zona ficar indisponível, os seus dados continuam disponíveis.	Ative a cópia de segurança automática para permitir que o Bigtable crie uma cópia de segurança diária em todos os clusters na instância. Em alternativa, crie cópias de segurança com regularidade e, em seguida, crie periodicamente uma cópia da cópia de segurança mais recente e armazene-a num ou mais clusters em diferentes zonas (opcionalmente, numa instância ou num projeto diferente).	Se a zona onde o cluster de publicação ficar indisponível, restaure a partir da cópia de segurança remota para uma nova tabela e, em seguida, reencaminhe os pedidos para a nova tabela.
Corrupção de dados: use uma cópia de segurança para recuperar alguns dos dados de uma tabela, como quando parte da tabela de origem fica corrompida.	Ative a replicação e a cópia de segurança automática para criar cópias de segurança diárias em várias regiões, para que, se uma tabela ficar danificada num cluster, tenha uma ou mais cópias de segurança que não partilham armazenamento no cluster danificado.	Restaure a partir da cópia de segurança para uma nova tabela no novo cluster ou instância. Em seguida, escreva uma aplicação com uma biblioteca de cliente do Bigtable ou Dataflow que leia a partir da nova tabela e, em seguida, escreva os dados novamente na tabela de origem. Quando os dados tiverem sido copiados para a tabela original, elimine a nova tabela.
Recuperação rápida: restaure rapidamente os níveis de desempenho de produção completos, minimizando o tempo de inatividade.	Mantenha sempre uma cópia de segurança ativa recente da sua tabela.	Restaurar para uma nova tabela a partir da cópia de segurança ativa e, em seguida, reencaminhar pedidos para a nova tabela.

Cópias de segurança a quente

Uma cópia de segurança a quente é uma cópia de segurança pronta para produção otimizada para uma recuperação rápida, com uma latência inferior ao ler da nova tabela pouco depois do restauro. O restauro para o desempenho de produção a partir de uma cópia de segurança ativa é mais rápido do que o restauro a partir de uma cópia de segurança padrão.

Pode converter uma cópia de segurança ativa numa cópia de segurança padrão, mas não pode converter uma cópia de segurança padrão numa cópia de segurança ativa.

Não pode criar cópias de segurança a quente com a cópia de segurança automática, nem criar uma cópia de segurança a quente num cluster de HDD.

Trabalhar com cópias de segurança do Bigtable

As seguintes ações estão disponíveis para as cópias de segurança do Bigtable. Em todos os casos, o projeto, a instância e o cluster de destino já têm de existir. Não pode criar estes recursos como parte de uma operação de cópia de segurança.

Não pode criar uma cópia de uma cópia de segurança. Uma cópia de uma cópia de segurança é sempre uma cópia de segurança padrão, mesmo que a origem seja uma cópia de segurança a quente.
Ação	Opções de destino
Crie uma cópia de segurança padrão	Qualquer cluster na mesma instância que a tabela de origem
Crie uma cópia de segurança a quente	Qualquer cluster na mesma instância que a tabela de origem. A instância tem de usar armazenamento SSD.
Restaurar a partir de uma cópia de segurança padrão ou ativa para uma nova tabela	Qualquer instância Qualquer região do Bigtable Qualquer projeto
Copie uma cópia de segurança^1, 2	Qualquer instância Qualquer região do Bigtable Qualquer projeto

Consulte o artigo Faça a gestão das cópias de segurança para ver instruções passo a passo sobre estas ações, bem como operações como a atualização e a eliminação de cópias de segurança.

Use o seguinte para trabalhar com cópias de segurança do Bigtable:

• A Google Cloud consola
• A CLI do Google Cloud
• As bibliotecas de cliente do Cloud Bigtable

Armazenamento de cópias de segurança

Uma cópia de segurança de tabelas que cria manualmente ou programaticamente é armazenada num único cluster que especifica. Quando a cópia de segurança automática está ativada, é armazenada uma cópia de segurança em cada cluster na instância.

Se o cluster exceder os limites recomendados para a utilização da CPU ou do armazenamento quando cria uma cópia de segurança, a criação da cópia de segurança pode ser atrasada. Para mais informações, consulte o artigo Compreenda a utilização do CPU e do disco.

Uma cópia de segurança de uma tabela inclui todos os dados que estavam na tabela no momento em que a cópia de segurança foi criada, no cluster onde a cópia de segurança é criada. Uma cópia de segurança nunca é maior do que o tamanho da tabela de origem no momento em que é criada.

As cópias de segurança do Bigtable são incrementais. A quantidade de armazenamento que uma cópia de segurança consome depende do tamanho da tabela e da medida em que pode partilhar o armazenamento de dados inalterados com a tabela original ou outras cópias de segurança da mesma tabela. Por esse motivo, o tamanho de uma cópia de segurança depende da quantidade de divergência de dados desde a cópia de segurança anterior.

Pode criar até 150 cópias de segurança por tabela por cluster.

Pode eliminar uma tabela que tenha uma cópia de segurança. Para proteger as suas cópias de segurança, não pode eliminar um cluster que contenha uma cópia de segurança, nem pode eliminar uma instância que tenha uma ou mais cópias de segurança em qualquer cluster.

A cópia de segurança continua a existir depois de a restaurar para uma nova tabela. Pode eliminá-lo ou deixá-lo expirar quando já não precisar dele. O armazenamento de cópias de segurança não é contabilizado para o limite de armazenamento de nós de um projeto.

Os dados nas cópias de segurança são encriptados.

Retenção

Pode especificar um período de retenção de até 90 dias para uma cópia de segurança. Se criar uma cópia de uma cópia de segurança, o período de retenção máximo da cópia é de 30 dias a partir do momento em que a cópia é criada.

Pode alterar o período de retenção de uma cópia de segurança para a manter até 90 dias após a hora de criação da cópia de segurança. Para mais informações, consulte o artigo Modifique uma cópia de segurança ou uma cópia de segurança.

Para tabelas com a cópia de segurança automática ativada, o período de retenção é de sete dias se definir a política através da flag --enable-automated-backup. Pode definir um período de retenção personalizado transmitindo a flag --automated-backup-retention-period, que aceita um valor de 3 a 90 dias. Para mais informações, consulte o artigo Atualize uma política de cópia de segurança automatizada.

Armazenamento após o restauro

O custo de armazenamento de uma nova tabela restaurada a partir de uma cópia de segurança é o mesmo que o de qualquer tabela.

Uma tabela restaurada a partir de uma cópia de segurança pode não consumir a mesma quantidade de armazenamento que a tabela original e pode diminuir de tamanho após o restauro. A diferença de tamanho depende da antiguidade da compactação no cluster de origem e no cluster de destino.

Uma vez que a compactação ocorre de forma contínua, é possível que a compactação ocorra assim que a tabela for criada. No entanto, a compactação pode demorar até uma semana a ocorrer.

Uma nova tabela restaurada a partir de uma cópia de segurança não herda as políticas de recolha de lixo da tabela de origem. Configure as políticas de recolha de lixo na nova tabela antes de começar a escrever novos dados na tabela. Para mais informações, consulte o artigo Configure a recolha de lixo.

Custos

Aplicam-se os custos de rede padrão quando trabalha com cópias de segurança. Não lhe é cobrado nenhum valor pelas operações de cópia de segurança, incluindo a criação, a cópia ou o restauro a partir de uma cópia de segurança.

Custos de armazenamento

Os custos de armazenamento são diferentes para as cópias de segurança padrão e as cópias de segurança rápidas.

Custos de armazenamento de cópias de segurança padrão

Para armazenar uma cópia de segurança padrão ou uma cópia de uma cópia de segurança, é-lhe cobrada a taxa de armazenamento de cópias de segurança padrão para a região em que se encontra o cluster que contém a cópia de segurança ou a cópia de segurança.

Uma cópia de segurança padrão é uma cópia lógica completa de uma tabela. Nos bastidores, o Bigtable otimiza a utilização do armazenamento de cópias de segurança padrão. Esta otimização significa que uma cópia de segurança padrão é incremental, ou seja, partilha o armazenamento físico com a tabela original ou com outras cópias de segurança da tabela sempre que possível. Devido às otimizações de armazenamento incorporadas do Bigtable, o custo de armazenamento de uma cópia de segurança padrão ou de uma cópia de uma cópia de segurança pode, por vezes, ser inferior ao custo de uma cópia física completa da cópia de segurança da tabela.

Em instâncias replicadas onde a cópia de segurança automática está ativada, os custos de armazenamento podem ser mais elevados porque é criada uma cópia de segurança em cada cluster diariamente.

Custos de armazenamento de cópias de segurança a quente

Para armazenar uma cópia de segurança ativa, é-lhe cobrada a taxa de armazenamento de cópias de segurança ativas para a região em que se encontra o cluster que contém a cópia de segurança ativa.

Uma vez que uma cópia de segurança ativa é armazenada num estado pronto, otimizado para um restauro rápido, é-lhe cobrado o armazenamento de toda a cópia lógica da tabela, em vez de porções incrementais, como acontece com uma cópia de segurança padrão.

Custos ao copiar uma cópia de segurança

Quando cria uma cópia de uma cópia de segurança numa região diferente da cópia de segurança de origem, são-lhe cobradas as tarifas de rede padrão pelo custo de cópia dos dados para o cluster de destino. Não lhe é cobrado tráfego de rede quando cria uma cópia na mesma região que a cópia de segurança de origem.

Custos ao restaurar

Quando restaura uma nova tabela a partir de uma cópia de segurança, é-lhe faturado o custo de rede da replicação. Se a nova tabela estiver numa instância que usa a replicação, é-lhe cobrado um custo de replicação único para que os dados sejam copiados para todos os clusters na instância.

Se fizer o restauro para uma instância diferente daquela onde a cópia de segurança foi criada e a instância da cópia de segurança e a instância de destino não tiverem, pelo menos, um cluster na mesma região, é-lhe cobrado um custo único pela cópia de dados inicial para o cluster de destino às tarifas de rede padrão.

CMEK

Quando cria uma cópia de segurança num cluster protegido por uma chave de encriptação gerida pelo cliente (CMEK), a cópia de segurança é associada à versão principal da chave CMEK do cluster no momento em que é criada. Depois de criar a cópia de segurança, não é possível modificar a respetiva chave nem versão da chave, mesmo que a chave do KMS seja rodada.

Quando faz o restauro a partir de uma cópia de segurança, a versão da chave à qual a cópia de segurança está associada tem de estar ativada para que o processo de desencriptação da cópia de segurança seja bem-sucedido. A nova tabela está protegida com a versão principal mais recente da chave CMEK para cada cluster na instância de destino. Se quiser fazer o restauro a partir de uma cópia de segurança protegida por CMEK para uma instância diferente, a instância de destino também tem de estar protegida por CMEK, mas não precisa de ter a mesma configuração de CMEK que a instância de origem.

Considerações sobre a replicação

Esta secção descreve conceitos adicionais a compreender quando faz uma cópia de segurança e restaura uma tabela numa instância que usa a replicação.

Replicação e cópia de segurança

Quando faz uma cópia de segurança de uma tabela manualmente numa instância replicada, escolhe o cluster onde quer criar e armazenar a cópia de segurança. Para tabelas com a cópia de segurança automática ativada, é criada uma cópia de segurança diária em cada cluster na instância.

Não tem de parar de escrever no cluster que contém a cópia de segurança, mas deve compreender como o Bigtable processa as escritas replicadas no cluster.

Uma cópia de segurança é uma cópia da tabela no estado em que se encontra no cluster onde a cópia de segurança está armazenada, no momento em que é criada. Os dados da tabela que ainda não foram replicados de outro cluster na instância não estão incluídos na cópia de segurança.

Cada cópia de segurança tem uma hora de início e de fim. As gravações enviadas para o cluster pouco antes ou durante a operação de cópia de segurança podem não ser incluídas na cópia de segurança. Dois fatores contribuem para esta incerteza:

• Pode ser enviado um comando de escrita para uma secção da tabela que a cópia de segurança já copiou.
• Uma gravação noutro cluster pode não ter sido replicada para o cluster que contém a cópia de segurança.

Por outras palavras, existe a possibilidade de algumas gravações com data/hora anteriores à hora da cópia de segurança não serem incluídas na cópia de segurança.

Se esta inconsistência for inaceitável para os requisitos da sua empresa, pode usar um token de consistência com os seus pedidos de gravação para garantir que todas as gravações replicadas são incluídas numa cópia de segurança.

As cópias de segurança de tabelas replicadas criadas como parte da cópia de segurança automática não são cópias exatas umas das outras, porque os horários das cópias de segurança podem variar de cluster para cluster.

Replicação e restauro

Quando restaura uma cópia de segurança para uma nova tabela, a replicação para e a partir dos outros clusters na instância começa imediatamente após a conclusão da operação de restauro no cluster de destino.

Desempenho

Ao criar cópias de segurança, use as seguintes práticas recomendadas para garantir que o desempenho permanece ideal.

Desempenho durante a criação de cópias de segurança

Normalmente, a criação de uma cópia de segurança demora menos de um minuto, embora possa demorar até uma hora. Em circunstâncias normais, a criação de cópias de segurança não afeta o desempenho da publicação.

Para um desempenho ideal, não crie uma cópia de segurança de uma única tabela mais do que uma vez a cada cinco minutos. A criação de cópias de segurança com mais frequência pode levar a um aumento observável na latência de publicação.

Desempenho durante o restauro

O restauro a partir de uma cópia de segurança para uma tabela numa instância de cluster único demora alguns minutos. Nas instâncias replicadas, o restauro demora mais tempo porque os dados têm de ser copiados para todos os clusters. O Bigtable escolhe sempre o caminho mais eficiente para copiar dados.

Se fizer o restauro para uma instância diferente daquela a partir da qual a cópia de segurança foi criada, a operação de restauro demora mais tempo do que se fizer o restauro para a mesma instância. Isto é especialmente verdade se a instância de destino não tiver um cluster na mesma zona que o cluster onde a cópia de segurança foi criada.

Uma tabela maior demora mais tempo a ser restaurada do que uma tabela mais pequena.

Se tiver uma instância de SSD, pode inicialmente sentir uma latência de leitura mais elevada, mesmo após a conclusão de um restauro, enquanto a tabela é otimizada. Pode verificar o estado em qualquer altura durante a operação de restauro para ver se a otimização ainda está em processamento.

Se restaurar para uma instância diferente daquela a partir da qual a cópia de segurança foi criada, a instância de destino pode usar armazenamento HDD ou SSD. Não tem de usar o mesmo tipo de armazenamento que a instância de origem.

Controlo de acesso

As autorizações da IAM controlam o acesso às operações de cópia de segurança e restauro. As autorizações de cópia de segurança estão ao nível da instância e aplicam-se a todas as cópias de segurança na instância.

A conta que usa para criar uma cópia de segurança de uma tabela tem de ter autorização para ler a tabela e criar cópias de segurança na instância em que a tabela se encontra (a instância de origem).

A conta que usa para copiar uma cópia de segurança tem de ter autorização para ler a cópia de segurança de origem e criar uma cópia de segurança na instância e no projeto de destino.

A conta que usa para restaurar uma nova tabela a partir de uma cópia de segurança tem de ter autorização para criar uma tabela na instância para a qual está a fazer o restauro.

Ação	Autorização de IAM necessária
Criar uma cópia de segurança	bigtable.tables.readRows, bigtable.backups.create
Obtenha uma cópia de segurança	bigtable.backups.get
Liste as cópias de segurança	bigtable.backups.list
Elimine uma cópia de segurança	bigtable.backups.delete
Atualize uma cópia de segurança	bigtable.backups.update
Copie uma cópia de segurança	bigtable.backups.read, bigtable.backups.create
Restaurar a partir de uma cópia de segurança para uma nova tabela	bigtable.tables.create, bigtable.backups.restore
Obtenha uma operação	bigtable.instances.get
Apresentar operações	bigtable.instances.get

Práticas recomendadas

Antes de criar uma estratégia de cópia de segurança, considere as seguintes práticas recomendadas. Para mais informações sobre o planeamento de recuperação de desastres, consulte a secção do Bigtable do artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem.

Criar cópias de segurança

• Não faça cópias de segurança de uma tabela com uma frequência superior a uma vez a cada cinco minutos.
• Quando faz uma cópia de segurança de uma tabela que usa a replicação, escolha o cluster para armazenar a cópia de segurança depois de considerar os seguintes fatores:
  • Custo. Um cluster na sua instância pode estar numa região de custo inferior do que os outros.
  • Proximidade ao servidor da aplicação. Recomendamos que armazene a cópia de segurança o mais perto possível da sua aplicação de publicação.
• Se precisar de garantir que todas as escritas replicadas estão incluídas numa cópia de segurança quando faz uma cópia de segurança de uma tabela numa instância que usa a replicação, use um token de consistência com os seus pedidos de escrita.

Restaurar a partir de cópias de segurança

• Planeie o nome que vai dar à nova tabela se precisar de fazer um restauro a partir de uma cópia de segurança. O ponto essencial é preparar-se antecipadamente para não ter de tomar decisões quando estiver a lidar com um problema.
• Se estiver a restaurar uma tabela por um motivo que não seja a eliminação acidental, certifique-se de que todas as leituras e escritas estão a ser feitas na nova tabela antes de eliminar a tabela original.
• Se planeia fazer o restauro para uma instância diferente, crie a instância de destino antes de iniciar a operação de restauro da cópia de segurança.
• Para evitar uma restauração lenta da tabela, aguarde que uma operação de restauração seja concluída antes de iniciar outra restauração para a mesma tabela de origem na mesma zona.
• Aguarde, pelo menos, uma hora após a criação antes de restaurar a partir de uma cópia de segurança padrão. Se precisar de fazer o restauro mais rapidamente, use uma cópia de segurança ativa.

Quotas e limites

Os pedidos de cópia de segurança e restauro, bem como o armazenamento de cópias de segurança, estão sujeitos a quotas e limites do Bigtable.

Limitações

As seguintes limitações aplicam-se às cópias de segurança do Bigtable:

Geral

• Não pode ler diretamente a partir de uma cópia de segurança.
• Uma cópia de segurança é uma versão de uma tabela num único cluster num momento específico. As cópias de segurança não representam um estado consistente. O mesmo também se aplica às cópias de segurança da mesma tabela em clusters diferentes.
• Não pode fazer uma cópia de segurança de mais do que uma tabela numa única operação.
• Não pode exportar, copiar nem mover uma cópia de segurança do Bigtable para outro serviço, como o Cloud Storage.
• As cópias de segurança do Bigtable contêm apenas dados do Bigtable e não estão integradas nem relacionadas com cópias de segurança de outros serviços Google.
• Não pode criar uma cópia de segurança de uma vista.

A restaurar

• Não é possível restaurar a partir de uma cópia de segurança para uma tabela existente.
• Só pode restaurar para uma instância que já exista. O Bigtable não cria uma nova instância quando faz o restauro a partir de uma cópia de segurança. Se a instância de destino especificada num pedido de restauro não existir, a operação de restauro falha.
• Se restaurar uma cópia de segurança para uma tabela num cluster de SSD e, em seguida, eliminar a tabela restaurada recentemente, a eliminação da tabela pode demorar algum tempo a ser concluída porque o Bigtable aguarda que a otimização da tabela termine.

A copiar

• Não pode criar uma cópia de uma cópia de segurança que esteja a 24 horas da expiração.
• Não pode criar uma cópia de uma cópia de segurança.

CMEK

• Uma cópia de segurança protegida por CMEK tem de ser restaurada para uma nova tabela numa instância protegida por CMEK.
• Quando cria uma cópia de uma cópia de segurança protegida por CMEK, o cluster de destino também tem de estar protegido por CMEK.

O que se segue?

• Saiba como fazer uma cópia de segurança e restaurar tabelas.
• Saiba como ativar a cópia de segurança automática.