Sobre os backups do Cloud SQL

Nesta página, descrevemos como os backups funcionam nas instâncias do Cloud SQL e as opções disponíveis para você escolher. Para ter uma visão geral de como restaurar dados de uma instância por meio do backup, consulte Visão geral da restauração de uma instância.

Com o Cloud SQL, é possível fazer backup das instâncias sob demanda ou automaticamente usando um cronograma de backup. Os backups do Cloud SQL são incrementais e ajudam a restaurar dados perdidos na instância do Cloud SQL. Com os backups, você pode:

  • Restaure a instância para um estado anterior se ela estiver enfrentando um problema.
  • Configure a recuperação de desastres (DR) criando uma nova instância usando um backup em uma região ou zona diferente.
  • Crie várias instâncias usando backups para ajudar no desenvolvimento, teste e migração.

Os backups do Cloud SQL também são criptografados por padrão usando chaves de criptografia gerenciadas pelo Google ou pelo cliente (CMEK).

Para manter esses backups, defina as configurações de retenção de backup da sua instância. As configurações de retenção podem variar de acordo com a edição do Cloud SQL e a opção de backup da instância. Além disso, é possível reter backups depois que a instância é excluída para permitir a restauração dela após a exclusão.

O Cloud SQL oferece duas opções de serviços de backup para gerenciar seus backups:

  • Backups aprimorados: os backups são gerenciados e armazenados em um projeto centralizado de gerenciamento de backups que usa o serviço de Backup e DR e oferece retenção forçada, agendamento granular e monitoramento.
  • Backups padrão: são criados, gerenciados e armazenados no mesmo projeto das instâncias do Cloud SQL.

Para mais informações sobre cada opção de backup e seus recursos, consulte Opções de backup.

Tipos de backup

O Cloud SQL realiza backups sob demanda ou automáticos das suas instâncias do Cloud SQL.

Backups sob demanda

Os backups sob demanda podem ser criados a qualquer momento. Eles são úteis se você estiver prestes a executar uma operação arriscada no banco de dados ou se precisar de um backup e não quiser esperar pela janela de backup. É possível criar backups sob demanda para qualquer instância, mesmo que ela não tenha backups automáticos ativados.

Backups automatizados

Os backups automatizados são feitos em uma cadência programada, como por hora, dia, semana ou mês. A cadência programada depende da opção de backup da sua instância. O backup é iniciado durante essa janela. O Cloud SQL recomenda programar os backups quando a instância tiver menos atividade, se possível.

Recomendamos que você não exclua manualmente nenhum backup automatizado porque eles são necessários para permitir a recuperação pontual.

Durante a janela de backup, os backups automatizados são feitos regularmente com base na cadência programada quando a instância está em execução. Um backup automático extra é feito após a interrupção da instância para proteger todas as mudanças realizadas antes da interrupção. A retenção automatizada de backup depende da política de retenção configurada na opção de backup escolhida para sua instância.

Fazer um backup final antes de excluir a instância

Com os backups finais, é possível fazer um backup da instância do Cloud SQL antes de excluí-la. Isso é útil para reter os dados da instância depois que ela é excluída. Você pode usar o backup final mais tarde para criar uma instância ou restaurar uma instância atual. Para mais informações sobre como acessar e ver detalhes do backup final, consulte Ver uma lista de backups finais.

Por padrão, o Cloud SQL retém o backup final por 30 dias. No entanto, é possível personalizar por quanto tempo o Cloud SQL retém o backup. Esse período pode variar de 1 dia a 365 dias para backups padrão ou de 1 dia a 99 anos para backups avançados. Em seguida, restaure a instância do backup enquanto ele estiver disponível. Os backups finais são cobrados de maneira semelhante a outros backups pelo número de dias retidos.

Reter backups após a exclusão da instância

Os backups retidos são aqueles que o Cloud SQL mantém após a exclusão de uma instância. Esses backups consistem em backups sob demanda e automatizados criados quando a instância estava ativa. Quando você exclui uma instância, esses backups se tornam independentes dela e são armazenados no nível do projeto. Os backups retidos são diferentes dos backups finais, que são os últimos backups feitos no momento da exclusão da instância.

É possível atualizar a descrição desses backups para facilitar o gerenciamento deles no projeto Google Cloud . Os backups retidos podem ser restaurados para uma instância do Cloud SQL nova ou atual a qualquer momento.

Para esses backups, o período de armazenamento é definido pelo tipo de backup e não pode ser alterado depois que a instância é excluída. Para backups padrão, os backups sob demanda são mantidos indefinidamente até que sejam excluídos manualmente ou que o projeto que os contém seja excluído. Para backups avançados, os backups sob demanda são mantidos com base na regra de retenção selecionada. Os backups automatizados são excluídos de forma contínua, um backup por dia, depois que a instância é excluída. O período contínuo é definido com base nas configurações de retenção da instância antes da exclusão, que podem variar de 1 dia a 99 anos, dependendo da opção de backup selecionada da instância. Por exemplo, se a configuração de retenção de backup automático da instância estiver definida como 7, o backup automático mais recente será excluído 7 dias após a exclusão da instância.

Os backups retidos podem ser excluídos manualmente a qualquer momento. No entanto, quando você exclui um backup retido, ele não pode ser recuperado.

Como os nomes de instâncias podem ser usados depois que uma instância é excluída no Cloud SQL, os backups retidos são armazenados no seu projeto Google Cloud com um campo chamado instance_deletion_time. Esse campo permite identificar se um backup específico pertence a uma instância ativa ou excluída. Você também pode atualizar a descrição de um backup para facilitar o gerenciamento.

Retenção de registros de transações

A retenção do registro de transações ocorre em dias. Para instâncias do Cloud SQL edição Enterprise Plus, o intervalo é de 1 a 35 dias, com um padrão de 14 dias. Para instâncias do Cloud SQL edição Enterprise, o intervalo é de um a sete dias, com um padrão de sete dias. Nas instâncias do Cloud SQL edição Enterprise Plus e do Cloud SQL edição Enterprise, a configuração de armazenamento de registros de transações precisa ser menor que a configuração de armazenamento de backups.

Backups para réplicas

Os backups não estão disponíveis para instâncias de réplica. Como as instâncias de réplica são cópias das instâncias principais, os backups são mantidos com a instância principal. Se uma instância de réplica for promovida a uma instância independente devido a um failover ou switchover, ela será ativada para backups e exigirá sua própria configuração de backup. As réplicas promovidas não herdam as configurações de backup da instância principal e não podem acessar os backups dela.

Opções de backup

O Cloud SQL oferece duas opções de serviços de backup para gerenciar os backups da instância: Standard e Enhanced. É possível escolher entre as opções de backup padrão e avançado com base nos requisitos e necessidades da sua instância. Embora as instâncias não possam usar as duas opções de backup ao mesmo tempo, o Cloud SQL permite alternar entre elas conforme necessário.

A tabela a seguir fornece uma visão geral dos recursos disponíveis com cada opção de backup:

Recursos Backups padrão Backups aprimorados
Backup vault -
Retenção obrigatória com bloqueio de retenção -
Reter backups na exclusão do projeto -
Gerenciamento centralizado de backups entre projetos -
Período de armazenamento de backup 1 ano Ilimitado
Programação de backup automatizada Diariamente Por hora, dia, semana, mês ou ano
Recuperação pontual usando registros
Backup e restauração entre regiões. -
Backups sob demanda
Backups multirregionais -
Reter todos os backups na exclusão da instância
Backup final na exclusão da instância
Suporte à CMEK -

Para mais informações sobre essas opções de backup, consulte Backups padrão e Backups avançados.

Backups aprimorados

Com os backups avançados, é possível usar o Backup e DR para gerenciar e armazenar todos os backups das instâncias do Cloud SQL em vários projetos em um projeto de backup central. O Backup e DR oferece gerenciamento, monitoramento e relatórios centralizados das operações de backup diárias em um só lugar. Os backups são armazenados em um backup vault, que é um recurso de armazenamento seguro e isolado gerenciado pelo Google, gerenciado pelo Backup e DR, e os planos de backup gerenciam as configurações de backup e restauração. Isso fornece backups imutáveis e indeléveis que são independentes do projeto de origem. Para mais informações sobre como os backups funcionam com o Backup e DR, consulte Visão geral do Backup e DR.

Os backups avançados usam o Backup e DR para criar um projeto de backup centralizado em que você gerencia os planos de backup e o backup vault nas instâncias do Cloud SQL. Esses planos podem ser vinculados a vários projetos.

Quando você anexa um plano de backup a uma instância do Cloud SQL, as configurações de backup e restauração atuais são substituídas pelo plano de backup. O plano que contém suas configurações de backup e restauração é armazenado no projeto de backup centralizado, e todos os backups criados quando o plano está ativo na instância do Cloud SQL são armazenados no backup vault no projeto de backups.

Como o Backup e DR é gerenciado em um Google Cloud projeto separado, os backups são protegidos quando um projeto de origem ou de carga de trabalho é excluído. As funções e responsabilidades são gerenciadas pelo Backup and DR Admin e são separadas das funções e responsabilidades do Cloud SQL Admin.

Você pode reter backups após a exclusão da instância ou fazer um backup final da instância antes da exclusão. Todos os backups feitos como parte dos backups avançados podem ser usados para restaurar uma instância enquanto ela está ativa ou depois de ser excluída.

Retenção de backup

É possível manter backups em um backup vault por até 99 anos ao usar backups avançados. O backup vault tem um período mínimo de retenção obrigatória entre 1 dia e 99 anos.

Armazenamento de backup

Os backups são armazenados em um local centralizado chamado backup vault. Um backup vault é um armazenamento seguro e isolado, gerenciado pelo Backup e DR. Com um backup vault, é possível reter backups de 1 dia a 99 anos. Para mais informações, consulte Coffers de backup.

Custos de backup

Nos backups avançados, o custo é baseado no tamanho total do backup armazenado no backup vault. Esses backups são criados com base na configuração do plano de backup associado à instância. O custo total é calculado pelo Backup e DR e com base nos preços do Backup e DR.

Limitações

As seguintes limitações se aplicam ao usar backups avançados:

  • O cofre de backup e a instância do Cloud SQL precisam estar na mesma região.
  • Para mudar o plano de backup associado a uma instância, é necessário mudar a instância para backups padrão. Para isso, exclua a associação do plano de backup atual e associe o novo plano.
  • Não é possível criar uma réplica de recuperação de desastres (DR) para uma instância usando backups avançados.
  • Se a instância tiver uma réplica de recuperação de desastres (DR), não será possível ativar backups avançados para ela.
  • Não é possível associar um plano de backup a uma instância de réplica.
  • Se a instância estiver usando backups avançados, não será possível fazer downgrade dela para uma réplica.

Backups padrão

Os backups padrão são gerenciados pelo Cloud SQL com sua instância do Cloud SQL. Os backups do Cloud SQL são incrementais e contêm apenas dados que foram alterados após o backup anterior. Por padrão, o Cloud SQL mantém sete backups automatizados para cada instância da edição Enterprise e 15 backups automatizados para cada instância da edição Enterprise Plus, além dos backups sob demanda. É possível configurar quantos backups automáticos serão retidos (de 1 a 365).

Como parte da exclusão de uma instância, você pode manter todos os backups no momento da exclusão e fazer um backup final dos dados. Isso permite recriar as instâncias excluídas. No entanto, se você não mantiver backups ou fizer um backup final antes de excluir a instância, o Cloud SQL vai excluir todos os backups de instância automaticamente.

Retenção de backup

Os backups sob demanda não são excluídos automaticamente. Eles persistem até que você os exclua manualmente ou até que a instância seja excluída. Como os backups sob demanda não são excluídos automaticamente, eles podem afetar o faturamento a longo prazo.

Os backups automáticos podem ser retidos de 1 a 365 dias ao configurar o período de armazenamento nas configurações de backup da sua instância. Embora os registros de transação sejam contados em dias, não há garantia de que os backups automáticos ocorram em um dia.

Se você ativar a retenção de backup após a exclusão da instância para seus backups sob demanda e automáticos, eles seguirão as mesmas configurações de retenção de 1 a 365 dias para backups automáticos e indefinidamente para backups sob demanda. Para mais informações, consulte Reter backups após a exclusão da instância.

Os registros são limpados uma vez por dia, e não continuamente. Se o número de dias de retenção de registros for igual ao número de backups, isso poderá resultar em uma retenção de registros insuficiente. Por exemplo, definir a retenção de registros para 7 dias e a retenção de backup para 7 backups significa que entre 6 e 7 dias de registros serão retidos.

Recomendamos que você defina o número de backups para, pelo menos, um dia a mais de dias de retenção de registros. Dessa forma, é possível garantir um mínimo de dias especificados para a retenção de registros.

Para mais informações sobre como ativar backups retidos para instâncias novas ou atuais, consulte Gerenciar backups retidos. Para mais informações sobre como restaurar uma instância de um backup retido, consulte Restaurar de um backup retido.

Armazenamento de backup

Em uma configuração de região única, os backups são replicados nas diferentes zonas da região. Em uma configuração multirregional, é recomendável que os backups estejam na mesma região da instância para minimizar a latência e evitar possíveis falhas de backup devido a políticas da organização ou limitações baseadas em local.

Os backups são armazenados no mesmo local para instâncias em configurações de alta disponibilidade (HA) ou não HA. Em configurações de alta disponibilidade, ainda será possível acessar os backups da instância em caso de failover ou switchover para a instância secundária.

Você pode definir os locais de backup da seguinte maneira:

  • Locais padrão selecionados pelo Cloud SQL com base na localização da instância original
  • Locais personalizados escolhidos por você quando não quiser usar o local padrão
Locais de backup padrão

Se um local de armazenamento não for especificado, os backups serão armazenados na multirregião geograficamente mais próxima do local da instância do Cloud SQL. Por exemplo, se a sua instância do Cloud SQL estiver em us-central1, seus backups serão armazenados na multirregião us por padrão. No entanto, um local padrão, como australia-southeast1, estará fora de uma multirregião. A multirregião mais próxima é asia.

Locais de backup personalizados

O Cloud SQL permite que você selecione um local personalizado para seus dados de backup. Isso será útil se sua organização precisar obedecer aos regulamentos de residência de dados que exigem que você mantenha seus backups em um limite geográfico específico. Se sua organização tiver esse tipo de requisito, ela provavelmente usará uma política organizacional de restrição de local de recursos. Com essa política, quando você tenta usar um local geográfico que não está em conformidade com a política, um alerta é exibido na página Backups. Se você vir esse alerta, precisará alterar o local de backup para um local permitido pela política.

Ao selecionar um local personalizado para o backup, considere o seguinte:

  • Custo: Um dos clusters na sua instância pode estar em uma região de custo menor que os outros.
  • Proximidade do servidor do aplicativo:armazene o backup o mais próximo possível do aplicativo de veiculação.
  • Uso do armazenamento:você precisa de espaço de armazenamento suficiente para manter seu backup conforme ele aumentar de tamanho. Dependendo da carga de trabalho, você pode ter clusters de tamanhos diferentes ou com usos de disco distintos. Isso pode ser um fator relevante para a escolha do cluster.

Para uma lista completa de valores regionais válidos, consulte Locais de instância. Para uma lista completa de valores multirregionais, consulte Locais multirregionais.

Para mais informações sobre como definir locais para backups e ver os locais de backups de uma instância, consulte Definir um local personalizado para backups e Ver locais de backup.

Limitações da taxa de backup

O Cloud SQL limita a taxa para operações de backup no disco de dados. É permitido um máximo de cinco operações de backup a cada 50 minutos, por instância e por projeto. Se uma operação de backup falhar, ela não será contabilizada nessa cota. Se você atingir o limite, a operação vai falhar com uma mensagem de erro informando quando será possível tentar novamente.

Vamos ver como o Cloud SQL realiza a limitação de taxa para backups.

O Cloud SQL usa tokens de um bucket para determinar quantas operações de backup estão disponíveis por vez. Cada instância tem um bucket. É possível usar no máximo cinco tokens no bucket para operações de backup. A cada 10 minutos, um novo token é adicionado ao bucket. Se o bucket estiver cheio, o token estoura.

Cada vez que você emite uma operação de backup, um token é concedido do bucket. Se a operação for realizada, o token será removido do bucket. Se falhar, o token será retornado. O diagrama a seguir mostra como isso funciona:

Como os tokens funcionam

Backups e exportações

Os backups são gerenciados pelo Cloud SQL de acordo com as políticas de retenção e armazenados separadamente da instância do Cloud SQL. Os backups do Cloud SQL são diferentes de uma exportação enviada ao Cloud Storage, em que você gerencia o ciclo de vida. Os backups englobam todo o disco da instância. As exportações podem selecionar conteúdos específicos.

Não é possível usar as operações de backup e restauração para fazer upgrade de um banco de dados para uma versão posterior. Só é possível restaurar de um backup para uma instância com a mesma versão do banco de dados de quando o backup foi feito.

Para fazer upgrade para uma versão posterior, use o Database Migration Service ou exporte e importe o banco de dados para uma nova instância do Cloud SQL.

Custos de backup

Por padrão, o Cloud SQL mantém sete backups automatizados para cada instância da edição Enterprise e 15 backups automatizados para cada instância da edição Enterprise Plus, além dos backups sob demanda. É possível configurar quantos backups automáticos são retidos, de 1 a 365. Nós cobramos uma taxa mais baixa pelo armazenamento de backup do que por outros tipos de instâncias.

Para mais informações sobre preços relacionados a backups, consulte a página de preços.

Tamanho do backup

Todos os backups do Cloud SQL, exceto o primeiro, são incrementais. Eles contêm apenas dados que foram alterados após o backup anterior. O backup mais antigo tem um tamanho semelhante ao do banco de dados, mas os tamanhos dos próximos backups dependem da taxa de alteração dos dados. Quando o backup mais antigo é excluído, o tamanho do segundo mais antigo aumenta para se tornar um backup completo e é ajustado para capturar a diferença entre os backups. Cada backup incremental a seguir também é atualizado para corresponder ao novo backup completo.

É possível verificar o tamanho de um backup individual. O tamanho do backup representa o tamanho faturável de cada backup.

Solução de problemas

Problema Solução de problemas
Não é possível ver o status da operação atual. O console Google Cloud informa apenas o sucesso ou falha no momento da operação. Ele não foi criado para mostrar avisos ou outras atualizações.

Execute o comando gcloud sql operations list para listar todas as operações da instância do Cloud SQL especificada.

Você quer descobrir quem emitiu uma operação de backup sob demanda. A interface do usuário não mostra o usuário que iniciou uma operação.

Procure nos registros e filtre por texto para encontrar o usuário. Talvez seja necessário usar registros de auditoria para informações particulares. Os arquivos de registro relevantes incluem:

  • cloudsql.googleapis.com/postgres.log
  • Se os registros de auditoria do Cloud estiverem ativados e você tiver as permissões necessárias para visualizá-los, cloudaudit.googleapis.com/activity também poderá estar disponível.
Depois que uma instância é excluída, não é possível fazer backup dela.

Se você excluir uma instância sem fazer um backup final dos dados, não será possível recuperar nada. No entanto, se você restaurar a instância, o Cloud SQL também vai restaurar os backups. Para mais informações sobre como recuperar uma instância excluída, consulte Backups de recuperação.

Se você tiver feito uma operação de exportação, crie uma nova instância e faça uma operação de importação para recriar o banco de dados. As exportações são gravadas no Cloud Storage e as importações são lidas de lá.

O backup automático fica paralisado por muitas horas e não pode ser cancelado. Os backups podem levar muito tempo, dependendo do tamanho do banco de dados.

Se você realmente precisa cancelar a operação, peça ao suporte ao cliente para aplicar force restart à instância.

Uma operação de restauração pode falhar quando um ou mais usuários referenciados no arquivo dump SQL não existem. Antes de restaurar um arquivo dump SQL, todos os usuários do banco de dados com objetos ou que receberam permissões para os objetos do banco de dados despejado precisam existir no banco de dados de destino. Caso contrário, a operação de restauração não recriará os objetos com a propriedade ou as permissões originais.

Crie os usuários do banco de dados antes de restaurar do dump SQL.

Você quer aumentar o número de dias em que pode manter backups automáticos, de sete para 30 dias ou mais. É possível configurar o número de backups automatizados que serão retidos, de 1 a 365. Os backups automatizados são removidos regularmente com base no valor de retenção configurado. Infelizmente, isso significa que os backups visíveis atuais são os únicos backups automatizados que podem ser usados para restaurar.

Para manter os backups indefinidamente, crie um backup sob demanda. Ele não é excluído da mesma forma que backups automáticos. Os backups sob demanda permanecem indefinidamente. Ou seja, eles permanecem até que sejam excluídos ou a instância a que pertencem seja excluída. Como esse tipo de backup não é excluído automaticamente, ele pode afetar o faturamento.

Um backup automático falhou e você não recebeu uma notificação por e-mail. Para que o Cloud SQL notifique você sobre o status do backup, configure um alerta com base em registros.
Uma instância está falhando repetidamente porque está alternando entre os estados de falha e de restauração de backup. As tentativas de conexão e uso do banco de dados após a restauração falham.
  • Pode haver muitas conexões abertas. Conexões em excesso podem resultar de erros que ocorrem no meio de uma conexão em que não há configurações autovacuum para limpar conexões inativas.
  • A alternância pode ocorrer se qualquer código personalizado estiver usando uma lógica de repetição que não pare após algumas falhas.
  • Pode haver muito tráfego. Use o pool de conexões e outras práticas recomendadas para conectividade.

O que tentar

  1. Verifique se o banco de dados está configurado para autovacuum.
  2. Verifique se há alguma lógica de repetição de conexão configurada no código personalizado.
  3. Reduza o tráfego até que o banco de dados seja recuperado e aumente lentamente o tráfego.
Você descobre que está faltando dados ao executar uma operação de backup/restauração. As tabelas foram criadas como não registradas. Por exemplo:

CREATE UNLOGGED TABLE ....

Estas tabelas não estão incluídas em uma restauração de um backup:

  • O conteúdo de tabelas não registradas não sobrevive ao failover na instância de alta disponibilidade.
  • Tabelas não registradas não sobrevivem a falhas postgres.
  • As tabelas não registradas não são replicadas para réplicas de leitura.
  • As tabelas não registradas são automaticamente excluídas durante a restauração do backup.

A solução é evitar o uso de tabelas não registradas se você quiser restaurar essas tabelas com um backup. Ao restaurar um banco de dados que já tem tabelas não registradas, é possível despejar o banco de dados em um arquivo e recarregar os dados depois de modificar o arquivo despejado para ALTER TABLE para SET LOGGED nessas tabelas.

A seguir