Sobre backups do Cloud SQL

Esta página descreve como funcionam os backups da sua instância do Cloud SQL. Você pode realizar backups na sua instância primária.

Para obter instruções passo a passo sobre como agendar ou gerenciar backups, consulte Criar e gerenciar backups automáticos e sob demanda .

Para obter uma visão geral de como restaurar dados de uma instância a partir do backup, consulte Visão geral da restauração de uma instância .

O que os backups fornecem

Os backups ajudam a restaurar dados perdidos na sua instância do Cloud SQL. Além disso, se uma instância apresentar problemas, você pode restaurá-la para um estado anterior usando o backup para sobrescrevê-la. Habilite backups automatizados para qualquer instância que contenha os dados necessários. Os backups protegem seus dados contra perdas ou danos.

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

Quanto custam os backups

Por padrão, o Cloud SQL mantém 7 backups automatizados para cada instância da edição Enterprise do Cloud SQL e 15 backups automatizados para cada instância da edição Enterprise Plus do Cloud SQL, além dos backups sob demanda. Você pode configurar quantos backups automatizados deseja manter (de 1 a 365). Cobramos uma tarifa menor para armazenamento de backup do que para outros tipos de instância.

Como parte da exclusão de uma instância, você pode fazer um backup final dos seus dados. Dessa forma, você pode recriar quaisquer instâncias excluídas. No entanto, se você não fizer um backup final, após a exclusão de uma instância, o Cloud SQL excluirá todos os backups. Para obter mais informações, consulte Backups de recuperação .

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

Backups versus 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 para o Cloud Storage, onde você gerencia o ciclo de vida. Os backups abrangem todo o banco de dados. As exportações podem selecionar conteúdos específicos.

Operações de backup e restauração não podem ser usadas para atualizar um banco de dados para uma versão posterior. Você só pode restaurar a partir de um backup para uma instância com a mesma versão do banco de dados.

Para atualizar para uma versão posterior, considere usar o Database Migration Service ou exportar e depois importar seu 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 os dados que foram alterados após o backup anterior. O backup mais antigo tem um tamanho semelhante ao do seu banco de dados, mas o tamanho dos backups subsequentes depende da taxa de alteração dos seus dados. Quando o backup mais antigo é excluído, o tamanho do próximo backup mais antigo aumenta, de modo que um backup completo ainda existe.

Você pode verificar o tamanho de um backup individual . O tamanho do backup representa o tamanho faturável de cada backup.

Tipos de backups

O Cloud SQL executa três tipos de backups:

Backups sob demanda

Você pode criar um backup a qualquer momento. Isso pode ser útil se você estiver prestes a realizar uma operação arriscada no seu banco de dados ou se precisar de um backup e não quiser esperar pela janela de backup. Você pode criar backups sob demanda para qualquer instância, independentemente de ela ter backups automáticos habilitados ou não.

Os backups sob demanda não são excluídos automaticamente como os backups automatizados. Eles persistem 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 podem ter um efeito de longo prazo nas suas cobranças.

Backups automatizados

Os backups automatizados são realizados diariamente, dentro de uma janela de backup de 4 horas. O backup começa durante a janela de backup. Sempre que possível, agende backups para quando sua instância tiver menos atividade.

Recomendamos que você não exclua nenhum backup automatizado porque eles são necessários para dar suporte à recuperação em um ponto específico .

Durante a janela de backup, backups automatizados são realizados todos os dias em que a instância estiver em execução. Um backup automatizado adicional é realizado após a interrupção da instância para proteger todas as alterações anteriores à interrupção. Até sete backups mais recentes são retidos por padrão. Você pode configurar quantos backups automatizados serão retidos , de 1 a 365. Os valores de retenção de backup e log de transações podem ser alterados em relação à configuração padrão. Saiba mais .

Backups finais

Os backups finais permitem que você faça um backup da sua instância do Cloud SQL antes de excluí-la. Isso é útil para reter os dados da instância após a exclusão. Você pode usar o backup final posteriormente para criar uma instância ou restaurar uma instância existente. Para obter mais informações sobre como acessar e visualizar detalhes sobre seu backup final, consulte Exibir uma lista de backups finais .

Por padrão, o Cloud SQL retém o backup final por 30 dias. No entanto, você pode personalizar por quanto tempo o Cloud SQL retém o backup, de 1 a 365 dias. Você pode então restaurar a instância a partir do backup, desde que ele esteja disponível. Os backups finais são cobrados de forma semelhante a outros backups, de acordo com o número de dias retidos.

Ao contrário dos backups automatizados e sob demanda, que são associados a uma instância e ficam disponíveis somente quando ela existe, você pode visualizar e usar backups finais para operações de restauração depois que o Cloud SQL exclui a instância.

Backups retidos

Backups retidos são backups mantidos pelo Cloud SQL após a exclusão de uma instância. Esses backups consistem em backups sob demanda e backups automatizados criados enquanto a instância estava ativa. Quando você exclui uma instância, esses backups se tornam independentes da sua instância 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.

Você pode atualizar a descrição desses backups para facilitar o gerenciamento deles em seu Google Cloud projeto. Os backups retidos podem ser restaurados para uma instância nova ou existente do Cloud SQL a qualquer momento.

Para esses backups, o período de retenção é definido pelo tipo de backup e não pode ser alterado após a exclusão da instância. Os backups sob demanda são mantidos indefinidamente até que o backup seja excluído manualmente ou o projeto que o contém seja excluído. Os backups automatizados são excluídos de forma contínua, um backup por dia, após a exclusão da instância. O período contínuo é definido com base na configuração de retenção da instância antes da exclusão. Por exemplo, se a configuração de retenção de backup automatizado da sua instância foi definida como 7, o backup automatizado 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, ao excluir um backup retido, os backups excluídos não poderão ser recuperados.

Como os nomes de instância podem ser usados ​​após uma instância ser excluída no Cloud SQL, os backups retidos são armazenados em seu Google Cloud projeto com um campo chamado instance_deletion_time . Este 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.

Para obter mais informações sobre como habilitar backups retidos para suas instâncias novas ou existentes, consulte Gerenciar backups retidos . Para obter mais informações sobre como restaurar uma instância a partir de um backup retido, consulte Restaurar a partir de um backup retido .

Onde os backups são armazenados

Os locais de backup incluem:

Locais de backup padrão

Se você não especificar um local de armazenamento, seus backups serão armazenados na multirregião geograficamente mais próxima da localização da sua instância do Cloud SQL. Por exemplo, se 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 está fora de uma multirregião. A multirregião mais próxima é asia .

Locais de backup personalizados

O Cloud SQL permite selecionar um local personalizado para seus dados de backup. Isso é útil se sua organização precisa estar em conformidade com regulamentações de residência de dados que exigem que você mantenha seus backups dentro de um limite geográfico específico. Se sua organização tiver esse tipo de requisito, provavelmente ela usa uma política organizacional de Restrição de Localização de Recursos . Com essa política, ao tentar usar uma localização geográfica que não esteja em conformidade com a política, você verá um alerta na página Backups . Se você vir esse alerta, precisará alterar o local do backup para um local permitido pela política.

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

  • Custo: um cluster na sua instância pode estar em uma região de custo mais baixo que os outros.
  • Proximidade do seu servidor de aplicativos: talvez você queira armazenar o backup o mais próximo possível do seu aplicativo de serviço.
  • Utilização do armazenamento: você precisa de espaço de armazenamento suficiente para manter seu backup à medida que ele cresce. Dependendo da sua carga de trabalho, você pode ter clusters de tamanhos diferentes ou com usos de disco diferentes. Isso pode influenciar na escolha do cluster.

Para obter uma lista completa de valores regionais válidos, consulte Locais de Instâncias . Para obter uma lista completa de valores multirregionais, consulte Locais multirregionais .

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

Backup automatizado e retenção de log de transações

Backups automatizados são usados ​​para restaurar uma instância do Cloud SQL. Uma combinação de backups automatizados e logs de transações é usada para realizar uma recuperação pontual .

Os backups automatizados podem ser retidos por até um ano configurando o período de retenção, enquanto os backups sob demanda persistem até que você os exclua ou até que sua instância seja excluída.

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

A retenção do log de transações é em dias. Para instâncias do Cloud SQL Enterprise Plus, o intervalo é de 1 a 35 dias, com o padrão de 14 dias. Para instâncias do Cloud SQL Enterprise, o intervalo é de 1 a 7 dias, com o padrão de 7 dias. Para instâncias do Cloud SQL Enterprise Plus e do Cloud SQL Enterprise, a configuração de retenção do log de transações deve ser menor que a configuração de retenção do backup.

Os limites inferiores são úteis para instâncias de teste, pois logs e backups são excluídos mais rapidamente. Para logs de transações, o tamanho do disco não aumenta tanto com limites inferiores. Usar valores mais altos para retenção automatizada de backups permite restaurar dados de um período anterior.

Os logs são limpos uma vez por dia, não continuamente. Quando o número de dias de retenção de logs é igual ao número de backups, pode ocorrer retenção insuficiente de logs. Por exemplo, definir a retenção de logs para sete dias e a retenção de backups para sete backups significa que entre seis e sete dias de logs serão retidos.

Recomendamos definir o número de backups como pelo menos um a mais que os dias de retenção de log para garantir um mínimo de dias especificados de retenção de log.

Alta atividade de gravação no banco de dados pode gerar um grande volume de logs de transações, o que pode consumir espaço em disco significativo e levar ao crescimento do disco para instâncias com aumento automático de armazenamento. Recomendamos dimensionar o armazenamento de instâncias para levar em conta a retenção de logs de transações.

Consulte Configurando retenção de backup automatizada .

Consulte Configurando retenção de log de transações .

Posso exportar um backup?

Não, você não pode exportar um backup. Você só pode exportar dados de instância. Consulte Exportando 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 específica para cada instância. O Cloud SQL efetua login como o usuário cloudsqladmin para realizar backups automatizados.

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

Gravações e outras operações não são afetadas pelas operações de backup.

Limitações da taxa de backup

O Cloud SQL limita a taxa de operações de backup no disco de dados. Você tem direito a 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 o limite for atingido, a operação falhará e uma mensagem de erro será exibida informando quando você poderá tentar novamente.

Vamos dar uma olhada em como o Cloud SQL executa 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 a qualquer momento. Cada instância possui um bucket. Há um máximo de cinco tokens no bucket que você pode usar para operações de backup. A cada 10 minutos, um novo token é adicionado ao bucket. Se o bucket estiver cheio, o token transborda.

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

How tokens work

Verificações de backup e integridade de dados

O Cloud SQL realiza verificações automáticas de integridade do banco de dados em segundo plano para identificar possíveis problemas de integridade dos dados. Essas verificações são realizadas como processos offline, restaurando uma amostra de backups iniciados pelo cliente ou backups de recuperação.

Backups de recuperação

Antes de excluir uma instância, você pode fazer um backup final dos seus dados. Você também pode ativar backups retidos antes de excluir sua instância para manter todos os backups automáticos e sob demanda. Para obter mais informações, consulte Gerenciar backups retidos .

Você pode restaurar um backup retido ou final para uma nova instância, uma instância existente, uma instância em um projeto diferente ou uma nova instância em outra região. Para obter mais informações, consulte Restaurar uma instância .

O Cloud SQL também tenta manter pelo menos um último backup diário válido de cada instância ativa, caso não haja backups válidos disponíveis como parte da política de backup automatizado. Esse backup pode ser usado para fins de recuperação, entrando em contato com o Atendimento ao Cliente do Google Cloud.

Tabelas não registradas

Tabelas não registradas são apagadas automaticamente durante a restauração do backup.

Solução de problemas

Emitir Solução de problemas
Você não pode ver o status da operação atual. O Google Cloud O console informa apenas o sucesso ou a falha quando a operação é concluída. Ele não foi projetado para exibir avisos ou outras atualizações.

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

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.

Consulte os logs e filtre por texto para encontrar o usuário. Pode ser necessário usar logs de auditoria para obter informações privadas. Os arquivos de log relevantes incluem:

  • cloudsql.googleapis.com/postgres.log
  • Se os Logs 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, você não pode fazer um backup dela.

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

Se você tiver realizado uma operação de exportação, crie uma nova instância e, em seguida, execute 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á.

Um backup automatizado fica travado por muitas horas e não pode ser cancelado. Os backups podem demorar muito tempo dependendo do tamanho do banco de dados.

Se você realmente precisar cancelar a operação, pode pedir ao suporte ao cliente para force restart da instância.

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

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

Você quer aumentar o número de dias em que pode manter backups automáticos de sete para 30 dias, ou mais. Você pode configurar o número de backups automatizados a serem mantidos , 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 atualmente visíveis são os únicos backups automatizados dos quais você pode restaurar.

Para manter os backups indefinidamente, você pode criar um backup sob demanda , pois eles não são excluídos da mesma forma que os backups automatizados. Os backups sob demanda permanecem indefinidamente. Ou seja, permanecem até serem excluídos ou até que a instância à qual pertencem seja excluída. Como esse tipo de backup não é excluído automaticamente, ele pode afetar a cobrança.

Um backup automatizado 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 baseado em log .
Uma instância está falhando repetidamente porque está alternando entre os estados de falha e 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. O excesso de conexões pode resultar de erros que ocorrem no meio de uma conexão, sem configurações autovacuum para limpar conexões inativas.
  • O ciclo pode ocorrer se qualquer código personalizado estiver usando uma lógica de repetição que não para após algumas falhas.
  • Pode haver muito tráfego. Use o pool de conexões e outras práticas recomendadas para conectividade .

Coisas para tentar:

  1. Verifique se o banco de dados está configurado para autovacuum .
  2. Verifique se há alguma lógica de nova tentativa de conexão configurada no código personalizado.
  3. Reduza o tráfego até que o banco de dados se recupere e então aumente o tráfego lentamente.
Você percebe que estão 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 em uma instância de HA.
  • Tabelas não registradas não sobrevivem a falhas do postgres.
  • Tabelas não registradas não são replicadas para réplicas de leitura.
  • Tabelas não registradas são apagadas automaticamente durante a restauração do backup.

A solução é evitar o uso de tabelas não registradas se você quiser restaurá-las por meio de um backup. Se estiver restaurando a partir de um banco de dados que já possui tabelas não registradas, você pode despejar o banco de dados em um arquivo e recarregar os dados após modificar o arquivo despejado para ALTER TABLE para SET LOGGED nessas tabelas.

O que vem a seguir