Visão geral dos backups

Nesta página, descrevemos como funcionam os backups da sua instância do Cloud SQL.

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.

Quanto custam os backups

Por padrão, para cada instância, o Cloud SQL mantém sete backups automatizados, além de todos os backups sob demanda. É possível configurar quantos backups automáticos são retidos. Nós cobramos uma taxa mais baixa pelo armazenamento de backup do que por outros tipos de instâncias.

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 dos backups

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.

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.

Para ver o status de uma operação de backup sob demanda:

  1. use o comando gcloud sql operations list para receber o ID da operação;
  2. use o comando gcloud sql operations describe para ver o status da operação.
ou
  1. use a chamada da API operations.list REST para obter o ID da operação;
  2. use a chamada de API operations.get REST para ver o status da operação.

Backups automatizados

Os backups automáticos usam uma janela de backup de quatro horas. O backup é iniciado durante essa janela. Sempre que possível, programe backups quando a instância tiver a menor atividade.

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 backups automáticos serão interrompidos se a instância for interrompida por mais de 36 horas. 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, seus backups serão armazenados na multirregião geograficamente mais próxima do local da sua instância do Cloud SQL. Por exemplo, caso sua instância do Cloud SQL esteja 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.

Se você especificar uma única região, e ela tiver uma interrupção, não será possível restaurar o backup enquanto a instância estiver inativa.

Quando o backup é armazenado em várias regiões e há uma interrupção na região que contém a instância de origem, é possível restaurar um backup para uma instância nova ou que já existe em uma região diferente. O backup escolhido para restauração precisa estar em uma região que não tenha uma interrupção. Para recuperar uma lista de todos os backups no projeto, consulte Como ver uma lista de backups durante uma interrupção. Para restaurar um backup para uma instância diferente, consulte esta página.

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.

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

Consulte Como configurar um local personalizado para backups e Como visualizar locais para backups.

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 automatizados e registros de transações é usada para executar uma recuperação pontual.

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 um a 365 backups. A retenção de registros de transações é em dias e pode ser definida de um a sete. O valor padrão para ambos é sete.

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.

Tabelas não registradas

Solução de problemas

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Não é possível ver o status atual da operação. A interface do usuário mostra apenas sucesso ou falha. Use estes comandos do banco de dados para saber mais.
Não é possível encontrar o criador da operação. A interface do usuário não mostra quem iniciou uma operação. Use o registro de auditoria para descobrir.
Sem espaço em disco durante o backup automatizado. A instância atingiu os limites de espaço do disco rígido. Verifique o tamanho e a cota do sistema de arquivos.
Não é possível fazer backup após a instância ser excluída. A instância foi excluída. Recrie de uma exportação ou entre em contato com o suporte ao cliente se estiver dentro do período de carência.
O backup automatizado parece travado. O tempo de backup está correlacionado ao tamanho do banco de dados. Entre em contato com o suporte ao cliente se você realmente precisar cancelar a operação.
Falha na restauração. O arquivo dump pode conter usuários de banco de dados que ainda não existem. Crie os usuários do banco de dados antes de restaurar.
A operação não é válida para esta instância. O tamanho da instância de destino é menor que a origem. Aumente o tamanho da instância de destino.
Aumente o número de dias que backups automáticos precisam ser mantidos. Apenas sete backups automáticos são mantidos. Gerencie seus próprios backups manuais.
Erro desconhecido de falha do backup É possível que o backup tenha expirado. Marque estas sinalizações.
Nenhuma notificação sobre falha no backup. As notificações não são compatíveis com falhas no backup. Use os comandos da API REST ou da gcloud para verificar o status de um backup.
A instância está paralisada entre os estados de falha e restauração de backup. Excesso de tráfego ou muitas conexões abertas. Verifique as autovacuum configurações e tente a lógica novamente.
Os dados estão ausentes em um backup. As tabelas não registradas não são restauradas a partir de backup. Consulte estas observações sobre tabelas não registradas.

Não é possível ver o status atual da operação

Não é possível ver o status de uma operação no Console do Google Cloud.

O problema pode ser

O Console do Google Cloud informa apenas o sucesso ou falha no momento da conclusão e não foi projetado para retornar avisos.

O que você pode tentar

Conecte-se ao banco de dados e execute SHOW WARNINGS.


Não é possível encontrar o criador da operação

Você quer descobrir quem emitiu uma operação de backup sob demanda.

O problema pode ser

A página de operações da instância no Console do Google Cloud não mostra quem iniciou uma operação.

O que você pode tentar

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
  • cloudaudit.googleapis.com/activity também pode estar disponível, caso os Cloud Audit Logs estejam ativados.


Sem espaço em disco durante o backup automatizado

Você vê a mensagem de erro [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written..

Possível problema

A instância atingiu um limite absoluto durante um backup automatizado. Os arquivos temporários podem se expandir além do espaço em disco disponível durante um backup.

O que você pode tentar

Verifique se o disco não está cheio ou com cota de disco insuficiente. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.


Não é possível fazer backup após a instância ser excluída

Não é possível fazer um backup depois de excluir a instância.

O problema pode ser

A instância foi excluída.

O que você pode tentar

  • O período de carência para uma limpeza de instância do Cloud SQL é de quatro dias. Durante esse período, o suporte ao cliente pode recriar a instância. Depois que as instâncias são removidas, não é possível recuperar dados.
  • Se você tiver feito uma exportação, crie uma nova instância e faça uma 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 está paralisado

O backup automático fica paralisado por muitas horas e não pode ser cancelado.

O problema pode ser

Os backups podem levar muito tempo, dependendo do tamanho do banco de dados.

O que você pode tentar

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


Falha na restauração do backup

Uma operação de restauração pode falhar quando um ou mais usuários referenciados no arquivo dump SQL não existem.

O problema pode ser

Antes de restaurar um despejo 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. Caso contrário, a restauração não recriará os objetos com a propriedade e/ou as permissões originais.

O que você pode tentar

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


A operação não é válida para esta instância

Você vê a mensagem de erro HTTP Error 400: This operation isn't valid for this instance de uma chamada de API para instances.restoreBackup.

O problema pode ser

Não é possível restaurar de um backup de uma instância com um tamanho de armazenamento (XX GB) menor que o tamanho de backup (YY GB).

O que você pode tentar

Edite a instância de destino para aumentar o tamanho de armazenamento dela.


A instância está paralisada entre os estados de falha e restauração de backup

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.

O problema pode ser

  • Pode haver muitas conexões abertas. Muitas conexões 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 você pode 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.

Os dados ausentes em um backup

Você descobre que está faltando dados ao executar uma operação de backup/restauração.

O problema pode ser

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 apagadas durante a restauração de backup.

O que você pode tentar

A solução é evitar o uso de tabelas não registradas se você quiser restaurar essas tabelas por meio de 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.


Aumentar o número de dias que backups automáticos precisam ser mantidos

Você quer aumentar o número de dias em que pode manter backups automáticos, de sete para 30 dias ou mais.

O problema pode ser

Apenas sete backups são mantidos. Os backups são removidos regularmente devido ao custo e ao tamanho da retenção de backups. Infelizmente, isso significa que os backups visíveis atualmente são os únicos backups automatizados que podem ser usados para restaurar.

O que você pode tentar

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.


Erro desconhecido de falha do backup

O backup falhou e você vê Unknown error.

Possível problema

A criação do backup atingindo o tempo limite.

O que você pode tentar

Há duas sinalizações que influenciam a criação de backup: checkpoint_timeout e checkpoint_completion_target. No início do backup, um checkpoint slow é executado e usa checkpoint_completion_target multiplicado por checkpoint_timeout.

Por exemplo, 900 sec * 0.9 sec = 810 sec = 13.5 min Por isso, o tempo limite é atingido. Diminuir o valor de checkpoint_completion_target corrige o problema nesse caso.

Nenhuma notificação sobre falha no backup

Um backup automático falhou e você não recebeu uma notificação por e-mail.

Possível problema

As notificações não são compatíveis com falhas no backup.

Quando um backup automático falha, uma mensagem Operation error é exibida na página Details da instância do Cloud SQL.

O que você pode tentar

É possível encontrar o status de um backup usando a API REST ou os comandos da gcloud. Por exemplo, primeiro liste os backups de uma instância e, em seguida, descreva um backup específico pelo ID:

gcloud sql --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

A seguir