Ative a recuperação em um ponto no tempo (PITR) para sua instância RDS MySQL ativando o switch Point-in-time Recovery e definindo o período de retenção de backup de log. O sistema retém os conjuntos de backup com base nas dependências de backup completo e de log, garantindo a recuperação dentro do intervalo de tempo configurado.
Como funciona
Os backups convencionais retêm conjuntos por ciclo. Mesmo com backups bem-sucedidos, a janela de recuperação real costuma ser menor que o período de retenção de log e varia de acordo com o intervalo de backup completo. Atrasos ou falhas de backup reduzem ainda mais essa janela.
O PITR gerencia a retenção de backup por objetivos de ponto de recuperação. Ele garante a janela de recuperação configurada mantendo um backup completo válido antes do início da janela e uma cadeia contínua de backup de log que cobre todo o período.
PITR versus backups de log legados
O PITR e os backups de log legados compartilham os mesmos mecanismos de geração e backup de log, mas diferem nas políticas de expiração e retenção. O exemplo a seguir considera backups completos três vezes por semana (segunda, quarta e sexta-feira) com o Log Backup Retention Period (Days) definido para 7 dias:
|
Item |
Antes da atualização |
Após a atualização |
|
Janela de recuperação (melhor caso) |
Até 7 dias Nota
A janela de recuperação geralmente é menor que 7 dias. Uma janela de 7 dias ocorre apenas brevemente após a expiração de um conjunto de backup, mas antes que o agendador de limpeza o exclua. |
Fixada em 7 dias |
|
Janela de recuperação (caso típico) |
Geralmente de 4 a 5 dias Nota
A janela de recuperação típica depende do intervalo entre os backups completos. A janela diminui periodicamente para |
Fixada em 7 dias |
|
Janela de recuperação (pior caso) |
Menos de 3 dias Nota
Se backups completos consecutivos falharem (deadlocks de banco de dados, anomalias de dados), a janela de recuperação pode diminuir para 3 dias ou menos. Em casos extremos, a restauração se torna impossível. |
Fixada em 7 dias |
|
Custo de backup |
O sistema retém os dados de backup por 7 dias, gerando custos de armazenamento. |
O sistema retém os dados de backup por 7 a 9 dias, gerando custos de armazenamento. Importante
o sistema retém o backup completo mais recente de mais de 7 dias atrás e a cadeia contínua de backups de log desse backup completo até a marca de 7 dias. No entanto, você é cobrado apenas por um backup completo extra e até uma semana adicional de backups de log. |
Pré-requisitos
Sua instância RDS MySQL deve atender a estes requisitos:
Tipo de armazenamento: SSD local, SSD padrão, disco cloud de uso geral ou ESSD. Instâncias serverless também são suportadas.
Região: sendo implementada gradualmente nas regiões. Verifique a disponibilidade atual no console do ApsaraDB RDS. Phased upgrade of point-in-time recovery for ApsaraDB RDS for MySQL.
Verifique a página Basic Information da sua instância.
Notas de uso
Após ativar o PITR, todos os conjuntos de backup novos e não expirados são retidos com base no Log Backup Retention Period (Days) que você configurar.
Limitações
A página de política de backup avançado (backup esparso) não oferece suporte a essas configurações e disponibiliza apenas o recurso de backup de log legado. Differences between backup policy pages.
Para instâncias serverless, o PITR fica indisponível entre a parada e a reinicialização de uma instância, ou entre uma reinicialização e a conclusão do primeiro backup completo.
Faturamento
O faturamento de backup permanece inalterado. Para garantir o PITR, a instância retém conjuntos de backup extras além do Log Backup Retention Period (Days) especificado. Esses conjuntos contam para o seu total de Backup size. Backups dentro da cota gratuita não geram cobranças; o uso excedente é faturado. Backup fees.
Procedimento
Para instâncias criadas em ou após 11 de janeiro de 2024, siga estas etapas para configurar a política de PITR. Após ativar o PITR, tanto os conjuntos de backup novos quanto os existentes não expirados são retidos para atender ao período de retenção de backup de log especificado.
Para instâncias criadas antes de 11 de janeiro de 2024, atualize do recurso de backup de log legado para o PITR aprimorado na página Backup Strategy. Esta atualização é irreversível. Upgrade to point-in-time recovery.
Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS reside. Em seguida, encontre a instância RDS e clique no ID da instância.
No painel de navegação à esquerda, clique em Backup and Restoration.
Na página Backup and Restoration, clique na guia Backup Strategy e, em seguida, clique em Edit na seção Basic Backup Settings.
-
Configure os seguintes parâmetros e clique em OK.
Parâmetro
Descrição
Log Backup
Faz o backup de logs de transações para o PITR. Ativado por padrão.
Point-in-time recovery
Permite a recuperação para um ponto específico no tempo.
Log Backup Retention Period (Days)
Defina o período de retenção de backup de log.
-
Intervalo: 7 a 730 dias. Padrão: 7 dias.
-
Não deve exceder o período de retenção de backup completo.
NotaPara instâncias do RDS Basic Edition executando MySQL 5.7, este valor é fixo em 7 dias.
ImportantePara garantir o PITR, conjuntos de backup extras são retidos além do período de retenção de backup de log especificado.
Exemplo: com o Log Backup Retention Period (Days) definido para 7 dias, o sistema retém os dados de backup por 7 a 9 dias — o backup completo mais recente antes da marca de 7 dias, mais os backups contínuos de log para cobrir a lacuna. Você é cobrado apenas por um backup completo extra e até uma semana adicional de backups de log.
-
Desativar a recuperação em um ponto no tempo
Na guia Backup Strategy, clique em Edit na seção Basic Backup Settings e desative o switch Point-in-time Recovery.
Desativar a point-in-time recovery também desativa os backups de log, tornando o PITR impossível. Prossiga com cautela.
Operações relacionadas
Restaure dados de backups para uma instância existente, nova instância ou banco de dados local. Overview of data restoration methods.
Baixe backups para um dispositivo local ou faça upload deles para o OSS. Download backups.