Visão geral dos backups do Bigtable
Nesta página, você encontra uma visão geral dos backups do Bigtable. O conteúdo apresentado aqui é destinado a administradores e desenvolvedores do Bigtable.
Com os backups, você salva uma cópia do esquema e dos dados de uma tabela e restaurar do backup para uma nova tabela mais tarde. Bigtable oferece dois tipos de backup. 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. Ao restaurar de um backup padrão para um cluster SSD, a operação de restauração exige otimização adicional pelo Bigtable para disponibilizar a tabela desempenho da produção. Para mais informações, consulte Desempenho ao restaurar.
- Os backups dinâmicos fornecem a restauração mais eficiente no nível de produção. e 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 automatizado: ative o backup automatizado para o Bigtable criar backups diários.
- Backups dinâmicos: planeje a recuperação de desastres com backups dinâmicos 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 |
|---|---|---|
| Proteger-se contra erros humanos : é sempre bom tenha um backup recente dos dados pronto em caso de exclusão ou corrupção. | Determine a programação de criação de backups mais adequada ao seu às necessidades comerciais, por exemplo, diariamente. Opcionalmente, crie cópias periódicas dos os backups e armazená-los em um projeto ou região diferente para maior isolamento e proteção. Para ter ainda mais proteção, armazene o backup cópias em um projeto ou instância com permissões de acesso restrito. | Restaurar para uma nova tabela a partir do backup ou da cópia e, em seguida, redirecionar para a nova tabela. |
| Indisponibilidade de zona : você precisa verificar se, o evento improvável de uma zona do Google Cloud ficar indisponível, seus dados ainda estão 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 serviço ficar indisponível, restaure da cópia do backup remoto para uma nova tabela e, em seguida, redirecionar 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 para 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 o dados foram copiados para a tabela original, exclua o novo tabela. |
| Recuperação rápida: restaurar para níveis de desempenho de produção completos rapidamente, minimizando o tempo de inatividade. | Sempre mantenha um backup 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 e otimizado para recuperação, com menor latência ao ler a nova tabela logo após restauração. Restaurar o desempenho de produção a partir de um backup dinâmico é mais rápido 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 dinâmicos usando o backup automatizado nem criar um backup dinâmico 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 em uso |
|
|
| 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 que você especificar. Quando o backup automatizado está ativado, um backup é criado e armazenado 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 padrão são incrementais. A quantidade de armazenamento que um backup padrão consome depende do tamanho da tabela e da extensão em que ela pode compartilhar armazenamento de dados inalterados com a tabela original ou outros backups do mesmo tabela. Por esse motivo, o tamanho do 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 por causa do armazenamento otimizado; o que permite restaurar com eficiência aos 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 retenção padrão é de três dias. É possível mudar o período de retenção 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 backups padrão. Isso otimização significa que um backup padrão é incremental — ele compartilha armazenamento físico com a tabela original ou com outros backups da tabela sempre que possível. Devido ao armazenamento integrado do Bigtable o custo de armazenar um backup padrão ou a cópia de um backup pode pode ser menor que o custo de uma cópia física completa do backup da tabela.
Nas instâncias replicadas com o backup automatizado ativado, os custos de armazenamento pode ser maior porque um backup é criado em cada cluster diariamente.
Custos de armazenamento de backup acessado com frequência
Para armazenar um backup dinâmico, há uma cobrança pelo armazenamento de backup dinâmico de custo para a região em que está o cluster que contém o backup dinâmico.
Como um backup dinâmico é armazenado em estado pronto, é otimizado para o usuário será cobrado pelo armazenamento de toda a cópia lógica do em vez de partes incrementais, como acontece com 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 estiver ativado, um backup diário será criado em cada cluster da 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.
- Uma gravação em outro cluster pode não ter sido replicada no cluster 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.