PolarDB:Backup and recovery FAQ

O PolarDB mede os backups com duas métricas: o tamanho lógico de cada conjunto de backup e o tamanho físico de todos os backups combinados.

• Tamanho lógico: volume de dados (dados e logs) capturado em um ponto consistente no tempo via snapshot (③ na figura abaixo).

• Tamanho físico: tamanho total da cadeia de snapshots de backup. O PolarDB utiliza um mecanismo de cadeia de snapshots incrementais. 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 apenas quando snapshots anteriores expiram.

Exemplo: suponha que um cluster comece com 100 GB de dados, os backups de nível 1 sejam executados uma vez por dia e o período de retenção seja de 3 dias.

Data	Modificação de dados	Tamanho de armazenamento	Tamanho da cadeia de snapshots (backup físico)
Segunda-feira	Adicionar 100 GB	100 + 100 = 200 GB	+0 = 0 GB
Terça-feira	Modificar 1 GB + adicionar 1 GB	200 + 1 = 201 GB	0 + 1 = 1 GB
Quarta-feira	Excluir 100 GB (dados de segunda-feira)	201 − 100 = 101 GB	1 + 100 = 101 GB
Quinta-feira	Modificar 1 GB + adicionar 1 GB	101 + 1 = 102 GB	101 + 1 = 102 GB
Sexta-feira	Modificar 1 GB + adicionar 1 GB	102 + 1 = 103 GB	102 + 1 = 103 GB
Sábado	Modificar 1 GB + adicionar 1 GB	103 + 1 = 104 GB	103 + 1 − 100 = 4 GB

Observações sobre o exemplo:

• Segunda-feira: o crescimento de +0 GB na cadeia de snapshots é uma simplificação que não considera o tamanho da cadeia antes dessa data. Na prática, gravar dados após a criação de um snapshot causa algum crescimento, pois novos blocos de dados são copiados para preservar a consistência do snapshot.

• Sexta-feira: o snapshot de segunda-feira expirou, mas o tamanho da cadeia de snapshots ainda não diminui. O sistema ainda retém blocos de dados históricos para o conjunto de backup de terça-feira.

• Sábado: o snapshot de terça-feira expira. Os 100 GB adicionados na segunda-feira e excluídos na quarta-feira não precisam mais ser retidos na cadeia, então o tamanho físico cai 100 GB.

• Este exemplo cobre apenas dados de negócios e exclui arquivos de sistema. Os tamanhos reais serão diferentes.

Não. O tamanho físico é menor — muitas vezes muito menor — porque a cadeia de snapshots do PolarDB armazena cada bloco de dados único apenas uma vez.

Backup de nível 1

O tamanho físico de um backup de nível 1 (① 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 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). Representa a soma do espaço físico ocupado exclusivamente por todos os backups de dados (snapshots).

A cadeia de snapshots do PolarDB armazena cada bloco de dados único apenas uma vez em todos os snapshots. Devido a essa deduplicação, o tamanho físico total é menor que a soma dos tamanhos lógicos e, às vezes, pode ser menor que o tamanho lógico de um único conjunto de 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 estão ativados por padrão, e uma cota gratuita está disponível. Os backups de nível 2 estão desativados por padrão. Para obter mais informações, consulte Armazenamento de backup (cobrado pelo uso que excede a cota gratuita).

A fórmula de custo depende 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 (China continental): o tamanho total do backup de dados é de 700 GB e o armazenamento do banco de dados é de 1.000 GB.

Custo horário = (700 GB − 1.000 GB × 50%) × USD 0,00003231/GB/hora = USD 0,006462/hora

Para detalhes de preços, 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: Varia conforme o Storage Payment Method:

  • Subscription (cobrado por espaço): Capacidade de armazenamento × 50%

  • Pay-as-you-go (cobrado por capacidade): Uso de armazenamento × 50%

Exemplo (PSL5, China continental): o tamanho total do backup de nível 1 é de 700 GB e o uso de armazenamento do banco de dados é de 1.000 GB.

Custo horário = (700 GB − 1.000 GB × 50%) × USD 0,000464/GB/hora = USD 0,0928/hora

Para detalhes de preços, consulte Armazenamento de backup (cobrado pelo uso que excede a cota gratuita).

As abordagens a seguir reduzem o armazenamento de backup. Cada uma envolve contrapartidas; analise-as antes de fazer alterações.

Reduzir períodos de retenção — configure em Configurar uma política de backup:

Tipo de backup	Exemplo de alteração	Contrapartida
Backup de nível 1	7 dias → 3 dias	Conjuntos de backup anteriores ao período de retenção ficam indisponíveis para restauração.
Backup de nível 2	70 dias → 30 dias	Mesma situação do nível 1.
Backup de log	7 dias → 3 dias	Não é possível realizar uma restauração point-in-time para um momento anterior ao backup de log retido mais antigo.

Diminuir a frequência de backup — configure em Configurar uma política de backup:

Tipo de backup	Exemplo de alteração	Contrapartida
Backup de nível 1	Uma vez por dia → três vezes por semana	Uma frequência menor pode aumentar o tempo necessário para uma restauração point-in-time.
Backup de nível 2	Três vezes por semana → duas vezes por semana	Nenhuma documentada.

Adquira um plano de armazenamento para compensar os custos de backups de nível 1, backups de nível 2 e backups de log. Planos de armazenamento são uma forma econômica de pagar por backups. Para obter mais informações, consulte Planos de armazenamento.

Excluir conjuntos de backup desnecessários da lixeira do cluster para reduzir custos de backup de nível 2. Para obter detalhes, consulte Excluir um backup.

Sim.

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

Acesse Settings and Management > Backup and Restoration no console e abra a aba Data Backups.

Se você optou por reter conjuntos de backup ao liberar o cluster, visualize-os na lixeira do cluster no console do PolarDB. Para obter detalhes, consulte Lixeira do cluster.

Siga as etapas em Baixar um arquivo de backup. Os dados de backup baixados não permitem restaurar diretamente um cluster PolarDB for MySQL, mas você pode usá-los para restaurar dados em um banco de dados MySQL autogerenciado. Para obter detalhes, consulte Restauração de um arquivo de backup para um banco de dados MySQL autogerenciado.

Dois métodos estão disponíveis.

Método 1: Usar o Alibaba Cloud Database Backup Service (DBS)

1. No console do OSS, crie um bucket.

2. Configure um cronograma de backup lógico para PolarDB for MySQL no DBS.

3. Após a conclusão do backup, consulte conjuntos de backup ou baixe conjuntos de backup conforme necessário.

Método 2: Usar mysqldump ou Data Management (DMS)

1. Exporte arquivos de backup usando mysqldump ou DMS.

2. Faça upload dos arquivos exportados para o OSS.

Atualmente, o produto não suporta configuração direta de alertas para falhas de backup. No entanto, você pode 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 um e-mail, uma mensagem de texto ou uma 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, e um backup é acionado somente após a gravação completa de um arquivo de 1 GB. Se o cluster foi criado recentemente ou tem pouco tráfego, o arquivo de redo log pode não ter sido preenchido ainda. Portanto, nenhum backup foi acionado e nenhum registro aparece na lista.

Sim.

Não. Uma restauração point-in-time primeiro restaura um backup completo de dados anterior ao ponto no tempo selecionado e, em seguida, aplica redo logs incrementalmente para atualizar os dados até o ponto escolhido.

Sim.

Sim.

Não. O PolarDB for MySQL cria um novo banco de dados e tabela no cluster atual para a operação de recuperação. O banco de dados original não sofre modificações.