PolarDB:Backup and recovery FAQ

Os backups do PolarDB são medidos por duas métricas: o tamanho lógico de cada backup (② na figura a seguir) e o tamanho físico de todos os backups (① na figura a seguir).

• Tamanho lógico: volume de dados (dados e logs) em um ponto consistente no tempo (③ na figura a seguir).

• Tamanho físico: tamanho da cadeia de snapshots de backup. O PolarDB utiliza um mecanismo de cadeia de snapshots incrementais para backups. Esse mecanismo preserva o status do snapshot em cada ponto no tempo. Quando um bloco de dados é modificado, o sistema retém a versão histórica desse bloco para o snapshot. Os dados são removidos da cadeia de snapshots apenas quando snapshots anteriores expiram.

  Exemplo: suponha que o volume de dados de um cluster seja de 100 GB. O ciclo de backup para backups de nível 1/backups de dados ocorre uma vez por dia, com período de retenção de 3 dias.

  Data	Processo de modificação de dados	Tamanho dos dados no armazenamento	Tamanho da cadeia de snapshots correspondente (backup físico)
  Segunda-feira	Adicionar 100 GB de dados	100 GB + 100 GB = 200 GB	+ 0 GB = 0 GB Nota Este cálculo não considera o tamanho da cadeia de snapshots (backup físico) anterior a segunda-feira. Em um cenário real, o incremento não é de 0 GB. Os blocos de dados referenciados por um snapshot podem não estar totalmente gravados. Se for necessário gravar novos dados nesses blocos, o sistema cria uma nova cópia deles. Portanto, gravar dados após a criação de um snapshot também aumenta o tamanho da cadeia de snapshots (backup físico).
  Terça-feira	Modifique 1 GB de dados e adicionar 1 GB de dados	200 GB + 1 GB = 201 GB	0 GB + 1 GB = 1 GB
  Quarta-feira	Exclua 100 GB de dados Nota Os dados excluídos correspondem aos dados adicionados na segunda-feira.	201 GB - 100 GB = 101 GB	1 GB + 100 GB = 101 GB
  Quinta-feira	Modifique 1 GB de dados e adicionar 1 GB de dados	101 GB + 1 GB = 102 GB	101 GB + 1 GB = 102 GB
  Sexta-feira	Modifique 1 GB de dados e adicionar 1 GB de dados	102 GB + 1 GB = 103 GB	102 GB + 1 GB = 103 GB Nota Neste ponto, o snapshot de segunda-feira expirou. No entanto, o tamanho da cadeia de snapshots (backup físico) não diminui. O sistema continua retendo a versão histórica dos blocos de dados para o conjunto de backup de terça-feira.
  Sábado	Modifique 1 GB de dados e adicionar 1 GB de dados	103 GB + 1 GB = 104 GB	103 GB + 1 GB - 100 GB = 4 GB Nota Neste momento, o snapshot de terça-feira expirou. O sistema não precisa mais reter a versão histórica dos blocos de dados referentes aos dados adicionados na segunda-feira e excluídos na quarta-feira. Consequentemente, o tamanho da cadeia de snapshots (backup físico) diminui em 100 GB.

  Nota

  • O exemplo anterior serve apenas como referência. Ele considera somente os dados de negócios no cluster e não inclui arquivos de sistema. O tamanho real pode variar.

  • Para reduzir o tamanho do backup físico sem alterar a frequência de modificações nos blocos de dados, reduza o ciclo de backup e o período de retenção. Para obter mais informações, consulte Como reduzir o volume de dados e os custos de backups de nível 1, backups de nível 2 e backups de log?.

  

Não. As diferenças entre backup de nível 1 e backup de dados são as seguintes:

Backup de nível 1

O tamanho físico de um backup de nível 1 (① na figura a seguir) não equivale à soma de todos os tamanhos de backup lógico (② na figura a seguir). Ele representa a soma do espaço físico ocupado exclusivamente por todos os backups de nível 1 (snapshots).

Backup de dados

O tamanho físico de um backup de dados (① na figura a seguir) não corresponde à soma de todos os tamanhos de backup lógico (② na figura a seguir). Trata-se da soma do espaço físico ocupado exclusivamente por todos os backups de dados (snapshots).

Os backups do PolarDB possuem duas métricas de tamanho: o tamanho lógico de cada conjunto de backup e o tamanho físico de todos os backups. O PolarDB usa um mecanismo de cadeia de snapshots para backups, no qual cada bloco de dados exclusivo é armazenado apenas uma vez. Por isso, o tamanho físico total é menor que a soma dos tamanhos lógicos e, às vezes, pode ser inferior ao tamanho lógico de um único backup.

A cobrança refere-se ao espaço de armazenamento usado por backups de nível 1/backups de dados, backups de nível 2 e backups de log. Os backups de nível 1/backups de dados e os backups de log vêm ativados por padrão, com uma cota gratuita fornecida. Já os backups de nível 2 ficam desativados por padrão. Para obter mais informações, consulte Armazenamento de backup (cobrado pelo uso que excede a cota gratuita).

Os custos de armazenamento de backup dependem do Storage Type do seu cluster.

• Enterprise SSD (PL0, PL1, PL2, PL3 e AutoPL)

  • Fórmula: Custo horário = (Tamanho total do backup de dados - Cota gratuita) × Preço horário

  • Cota gratuita: Capacidade de armazenamento × 50%

  Exemplo: na China continental, se o tamanho total do backup de dados for de 700 GB e o uso de armazenamento do banco de dados for de 1.000 GB, o custo horário será de [700 GB - (1.000 GB × 50%)] × USD 0,00003231/GB/hora = USD 0,006462/hora. Para obter mais informações, consulte Armazenamento de backup (cobrado pelo uso que excede a cota gratuita).

• PSL4/PSL5

  • Fórmula: Custo horário = (Tamanho total do backup de nível 1 - Cota gratuita) × Preço horário

  • Cota gratuita: a fórmula para calcular a cota gratuita varia conforme o Storage Payment Method. As fórmulas são as seguintes:

    • Assinatura (cobrança por espaço): Capacidade de armazenamento × 50%.

    • Pagamento conforme o uso (cobrança por capacidade): Uso de armazenamento × 50%.

  Exemplo: para a classe de armazenamento PSL5 na China continental, se o tamanho total do backup de nível 1 (snapshot) for de 700 GB e o uso de armazenamento do banco de dados for de 1.000 GB, o custo horário será de [700 GB - (1.000 GB × 50%)] × USD 0,000464/GB/hora = USD 0,0928/hora. Para obter mais informações, consulte Armazenamento de backup (cobrado pelo uso que excede a cota gratuita).

• Reduza o período de retenção dos dados de backup conforme necessário. Para obter mais informações, consulte Configure uma política de backup.

  • Diminua o período de retenção dos backups de nível 1, por exemplo, de 7 dias para 3 dias.

  • Encurte o período de retenção dos backups de nível 2, por exemplo, de 70 dias para 30 dias.

    Nota

    Reduzir o período de retenção dos backups de nível 1 e nível 2 envolve riscos. Se um conjunto de backup necessário for anterior ao período de retenção definido, não será possível usá-lo para restaurar dados.

  • Limite o período de retenção dos backups de log, por exemplo, de 7 dias para 3 dias.

    Nota

    Diminuir o período de retenção dos backups de log traz riscos. Não é possível realizar uma restauração point-in-time para um momento anterior ao backup de log retido mais antigo.

• Ajuste a frequência de backup (ciclo de backup) conforme a necessidade. Para obter mais informações, consulte Configure uma política de backup.

  • Diminua a frequência dos backups de nível 1, por exemplo, de uma vez por dia para três vezes por semana.

    Nota

    Reduzir a frequência dos backups de nível 1 pode aumentar o tempo necessário para uma restauração point-in-time.

  • Reduza a frequência dos backups de nível 2, por exemplo, de três vezes por semana para duas vezes por semana.

• Exclua conjuntos de backup desnecessários da lixeira do cluster para reduzir os custos dos backups de nível 2. Para obter mais informações, consulte Exclua um backup.

Sim.

O período de retenção dos arquivos de backup manual é determinado pelo Backup Retention Period definido para Level-1 Backup ou Level-2 Backup em Data Backup, nas Backup Policy Settings.

Visualize o tamanho de um backup de nível 2 na aba Data Backups. Para acessar essa aba, acesse a página Settings and Management > Backup and Restoration no console.

Se você optar por manter conjuntos de backup ao liberar um cluster, poderá visualizá-los na lixeira do cluster no console do PolarDB. Para obter mais informações, consulte Lixeira do cluster.

Você pode baixar um arquivo de backup para o seu computador. No entanto, não é possível usar diretamente os dados de backup baixados para restaurar um cluster PolarDB for MySQL. Use-os para restaurar dados de um arquivo de backup para um banco de dados MySQL autogerenciado.

Use um dos métodos a seguir para realizar o arquivamento de longo prazo de arquivos de backup do PolarDB for MySQL no OSS:

• Utilize o Alibaba Cloud Database Backup Service (DBS) para armazenar arquivos de backup do PolarDB for MySQL no OSS. Execute as etapas a seguir:

  1. No console do OSS, crie um bucket.

  2. Configure manualmente um cronograma de backup lógico para PolarDB for MySQL. Após a conclusão do backup, gerencie o conjunto de backup. Por exemplo, você pode consultar conjuntos de backup ou baixar conjuntos de backup.

• Use mysqldump ou Data Management (DMS) para exportar arquivos de backup e, em seguida, faça upload deles no OSS. Siga estas etapas:

  1. Use o mysqldump ou DMS para exportar arquivos de backup do PolarDB for MySQL.

  2. Faça upload manual dos arquivos de backup exportados para o OSS. Para obter mais informações, consulte Carregar arquivos.

Atualmente, o product não suporta configuração direta de alertas para falhas de backup. Contudo, é possível implementar seu próprio mecanismo de alerta. Por exemplo, chame periodicamente a operação DescribeBackups para recuperar o campo BackupStatus de um job de backup. Em seguida, verifique o status e acione um alerta personalizado — como e-mail, mensagem de texto ou notificação em uma plataforma de monitoramento — caso o status seja Failed.

Os logs físicos de um cluster PolarDB são redo logs. Cada arquivo de redo log tem tamanho fixo de 1 GB. Um backup é acionado somente após um arquivo de 1 GB ser completamente gravado. Se um cluster foi criado recentemente ou apresenta baixo volume de acesso, o arquivo de redo log de 1 GB pode não estar cheio. Nesse caso, nenhum backup é acionado e não aparecem registros na lista de backup de redo log.

Essa funcionalidade é suportada.

Não, não é possível. Uma restauração point-in-time primeiro restaura um backup completo de dados anterior ao ponto no tempo selecionado para o cluster. Depois, utiliza redo logs para restaurar incrementalmente os dados até o ponto no tempo escolhido.

Suportado.

Suportado.

Não, não afeta. O PolarDB for MySQL cria um novo banco de dados e uma nova tabela no cluster atual para a operação de recuperação.