Sobre os backups do Cloud SQL

Nesta página, descrevemos como funcionam os backups da sua instância do Cloud SQL. É possível fazer backups na instância principal.

Para ver instruções passo a passo para programar backups ou criar um backup sob demanda, consulte Como criar e gerenciar backups automáticos e sob demanda.

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.

O que os backups oferecem

Os backups ajudam a restaurar dados perdidos na instância do Cloud SQL. Além disso, se uma instância tiver um problema, restaure-a para um estado anterior usando o backup para substituí-la. Ative backups automáticos para qualquer instância que contenha dados necessários. Os backups protegem seus dados contra perda ou danos.

A ativação de backups automatizados, juntamente com o registro binário, também é necessária para algumas operações, como a criação de clones e réplicas.

Quanto custam os backups

Por padrão, o Cloud SQL mantém sete backups automatizados para cada instância da Cloud SQL edição Enterprise e 15 backups automatizados para cada instância da Cloud SQL 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.

O Cloud SQL não fará um backup de uma instância se você interromper ou excluir a instância. Se você excluir uma instância, os dados serão preservados por apenas quatro dias. Para recuperar a instância e os dados dela, entre em contato com o Suporte do Google Cloud dentro do período de quatro dias com todas as informações necessárias da instância.

Consulte a página de preços para mais informações.

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 banco de dados. 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.

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.

Sobre o tamanho do backup

Os backups do Cloud SQL 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 próximo backup mais antigo aumenta para que um backup completo ainda exista.

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

Tipos de backup

O Cloud SQL realiza dois tipos de backup:

Backups sob demanda

É possível criar um backup a qualquer momento. Isso pode ser útil se você está prestes a executar uma operação arriscada no banco de dados ou se precisa de um backup e não quer esperar pela janela de backup. É possível criar backups sob demanda para qualquer instância, mesmo que a instância não tenha backups automáticos ativados.

Os backups sob demanda não são excluídos automaticamente da mesma forma como os backups automáticos são. Eles perduram até que você os exclua ou até que a instância deles seja excluída. Como não são excluídos automaticamente, os backups sob demanda poderão afetar o faturamento a longo prazo.

Backups automatizados

Os backups automatizados são feitos diariamente em uma janela de backup de quatro horas. O backup é iniciado durante essa janela. Quando possível, programe backups quando a instância tiver a menor atividade.

Recomendamos que você não exclua backups automatizados porque eles são necessários para permitir a recuperação pontual.

Durante a janela de backup, os backups automatizados ocorrem todos os dias em que a instância estiver em execução. Um backup automático extra é feito após a interrupção da instância para proteger todas as alterações realizadas antes da interrupção. Por padrão, até sete backups mais recentes são mantidos. É possível configurar quantos backups automáticos são retidos, de 1 a 365. Os valores de retenção de backup e transação podem ser alterados na configuração padrão. Saiba mais.

Onde os backups são armazenados

Os locais dos backups incluem o seguinte:

  • 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.

Retenção automatizada de registro de transações e backup

Os backups automáticos são usados para restaurar uma instância do Cloud SQL. Uma combinação de backups automáticos e registros de transações é usada para executar uma recuperação pontual.

Os backups automáticos podem ser retidos por até um ano ao configurar o período de armazenamento, enquanto os backups sob demanda são mantidos até que você exclua os backups ou até que a instância seja excluída.

Embora os registros de transação sejam contados em dias, não há garantia de que os backups automáticos ocorram em um limite de dia. Unidades diferentes são usadas para essas configurações de retenção. A retenção automatizada de backup é uma contagem e pode ser definida de 1 a 365 backups.

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.

Os limites mais baixos são úteis para instâncias de teste, porque os registros e backups são excluídos mais rapidamente. Para registros de transações, o tamanho dos discos não aumenta tanto quanto os limites inferiores. Usar valores mais altos para a retenção de backups automáticos permite que você restaure de volta no tempo.

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.

Uma alta atividade de gravação no banco de dados pode gerar um grande volume de registros de transação, o que pode consumir muito espaço no disco e levar ao crescimento do disco das instâncias de aumento de armazenamento automático. Recomendamos dimensionar o armazenamento da instância para considerar a retenção do registro de transações.

Consulte Como configurar a retenção automática de backup.

Consulte Como configurar a retenção de registros de transações.

Posso exportar um backup?

Não é possível exportar um backup. Somente os dados da instância podem ser exportados. Consulte Como exportar dados do Cloud SQL.

Sobre o usuário de backup especial

O Cloud SQL cria um usuário de banco de dados especial, cloudsqladmin, para cada instância e gera uma senha exclusiva e específica da instância para ele. O Cloud SQL faz login como usuário cloudsqladmin para executar backups automatizados.

Como os backups afetam as operações de instância

Gravações e outras operações não são afetadas por operações 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

Verificações de integridade de dados e backup

O Cloud SQL executa automaticamente verificações de integridade do banco de dados em segundo plano para identificar possíveis problemas de integridade de dados. Essas verificações são feitas como processos off-line por meio da restauração de uma amostra de backups iniciados pelo cliente ou de recuperação.

Backups de recuperação

Depois que uma instância é excluída, o Cloud SQL exclui todos os backups. Para evitar a exclusão acidental de instâncias, o Cloud SQL mantém os backups de uma instância por quatro dias. Para recuperar uma instância excluída, entre em contato com o Atendimento ao cliente do Google Cloud em até quatro dias.

O Cloud SQL mantém pelo menos um último backup diário bom de cada instância ativa. Como resultado, se não houver backups bons disponíveis, você pode usar o backup diário para recuperar sua instância, entrando em contato com o atendimento ao cliente do Google Cloud.

Tabelas não registradas

As tabelas não registradas são automaticamente excluídas durante a restauração do backup.

Solução de problemas

Problema Solução de problemas
Não é possível ver o status da operação atual. O Console do 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.

Depois que uma instância é limpa, não é possível recuperar dados. No entanto, se a instância for restaurada, os backups também serão restaurados. 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