Pré-scripts e postscripts aprimorados para snapshots consistentes com banco de dados

O Backup do Azure oferece uma estrutura interna de pre-script e postscript para garantir a consistência da aplicação para VMs Linux durante o backup. Esta estrutura executa automaticamente um prescript para silenciar aplicações antes das capturas de disco e um postscript para restaurar as aplicações à operação normal após a captura.

O gerenciamento de pré-scripts e postscripts personalizados geralmente é complexo e demorado. Para simplificar esse processo, o Backup do Azure fornece pré-scripts e postscripts prontos para uso para bancos de dados populares para habilitar instantâneos consistentes com aplicativos com o mínimo de esforço e manutenção.

O diagrama a seguir ilustra como o Azure Backup utiliza pré-scripts e pós-scripts aprimorados para obter instantâneos consistentes em aplicações de bancos de dados Linux, garantindo backups e recuperações confiáveis.

Principais benefícios de uma estrutura de prescrição e postscript aprimorada

A nova estrutura melhorada de scripts de pré e pós tem os seguintes benefícios principais:

• Esses scripts de preparação e finalização são instalados diretamente nas VMs do Azure junto com a extensão de backup, o que elimina a necessidade de criá-los e baixá-los de um local externo.
• A definição e o conteúdo de prescripts e postscripts estão disponíveis para visualização no GitHub. Você pode enviar sugestões e alterações via GitHub, que são triadas e adicionadas para beneficiar a comunidade em geral.
• Novos prescripts e postscripts para outros bancos de dados estão disponíveis via GitHub, que são triados e endereçados para beneficiar a comunidade em geral.
• A estrutura robusta é eficiente para lidar com cenários, como falha de execução prescrita ou falhas. Em qualquer caso, o postscript é executado automaticamente para reverter todas as alterações feitas no pré-script.
• A estrutura também fornece um canal de mensagens para ferramentas externas buscarem atualizações e prepararem seu próprio plano de ação em qualquer mensagem ou evento.

Fluxo de solução de framework prescript e postscript aprimorado

O diagrama a seguir ilustra o fluxo de solução da estrutura aprimorada de prescript e postscript para snapshots consistentes na base de dados.

Matriz de suporte

As seguintes bases de dados são abrangidas pelo quadro reforçado:

• Oracle (disponível em geral): consulte Matriz de suporte para backups de VM do Azure.
• MySQL (pré-visualização).

Pré-requisitos

Você precisa modificar apenas um arquivo de configuração, workload.conf em /etc/azure, para fornecer detalhes de conexão. Dessa forma, o Backup do Azure pode se conectar ao aplicativo relevante e executar prescripts e postscripts. O arquivo de configuração tem os seguintes parâmetros:

[workload]
# valid values are mysql, oracle
workload_name =
command_path = 
linux_user =
credString = 
ipc_folder = 
timeout =

A tabela a seguir descreve os parâmetros.

A experiência geral para usar a estrutura de prescrição e postscript aprimorada é:

• Prepare o ambiente de banco de dados.
• Edite o arquivo de configuração.
• Acione o backup da VM.
• Restaure VMs, discos ou arquivos do ponto de recuperação consistente com o aplicativo, conforme necessário.

Crie uma estratégia de backup de banco de dados

Usar instantâneos em vez de streaming

Normalmente, os backups de streaming (como completos, diferenciais ou incrementais) e os logs são usados pelos administradores de banco de dados em sua estratégia de backup. Os pontos-chave do projeto são:

• Desempenho e custo: um backup completo diário mais logs é o mais rápido durante a restauração, mas envolve um custo significativo. A inclusão do tipo de backup de streaming diferencial ou incremental reduz os custos, mas pode afetar o desempenho da restauração. Mas os snapshots oferecem a melhor combinação de desempenho e custo. Como os snapshots são inerentemente incrementais, eles têm o menor efeito sobre o desempenho durante o backup, são restaurados rapidamente e também economizam custos.
• Impacto no banco de dados ou na infraestrutura: o desempenho de um backup de streaming depende das IOPS de armazenamento subjacentes e da largura de banda de rede disponível quando o fluxo é direcionado para um local remoto. Os snapshots não têm essa dependência e a demanda por IOPS e largura de banda de rede é reduzida.
• Reutilização: os comandos para acionar diferentes tipos de backup de streaming são diferentes para cada banco de dados, portanto, os scripts não podem ser facilmente reutilizados. Além disso, se você estiver usando diferentes tipos de backup, certifique-se de avaliar a cadeia de dependência para manter o ciclo de vida. Para snapshots, é fácil escrever scripts porque não há cadeia de dependência.
• Retenção de longo prazo: backups completos são sempre benéficos para a retenção de longo prazo, pois você pode movê-los e recuperá-los de forma independente. Para backups operacionais com retenção de curto prazo, os snapshots são preferíveis.

Um snapshot diário mais logs com backup completo ocasional para retenção de longo prazo é a melhor política de backup para bancos de dados.

Estratégia de backup de log

A estrutura aprimorada de scripts de pré e pós-execução é baseada no sistema de backup de VMs do Azure que programa backups uma vez por dia. Por essa razão, a janela de perda de dados com o RPO (Recovery Point Objective, objetivo de ponto de recuperação) de 24 horas não é adequada para bases de dados de produção. Essa solução é complementada com uma estratégia de backup de log onde os backups de log são transmitidos explicitamente.

O Network File System (NFS) no Armazenamento de Blobs do Azure e o NFS no AFS (visualização) ajudam na montagem fácil de volumes diretamente sobre VMs de base de dados e no uso de clientes de bases de dados para transferir backups de log. A janela de perda de dados que é o RPO depende da frequência das cópias de segurança dos logs. Além disso, os alvos NFS não precisam ser de alto desempenho. Talvez não seja necessário acionar o streaming regular (completo e incremental) para backups operacionais depois de obter instantâneos que sejam consistentes com o banco de dados.

Estratégia de recuperação

Depois que os instantâneos consistentes com o banco de dados são capturados e os backups de log são enviados para um volume NFS, a estratégia de recuperação do banco de dados pode utilizar a capacidade de recuperação dos backups de VM do Azure. A funcionalidade de backups de log também é utilizada nele através do cliente de base de dados. As seguintes opções para a estratégia de recuperação são:

• Crie novas VMs a partir de um ponto de recuperação consistente com o banco de dados. A VM já deve ter o ponto de montagem de log conectado. Utilize clientes de banco de dados para executar comandos de recuperação para recuperação em momento específico.
• Crie discos a partir de um ponto de recuperação consistente com o banco de dados e anexe-os a outra VM de destino. Em seguida, monte o destino do log e use clientes de banco de dados para executar comandos de recuperação para recuperação point-in-time.
• Use uma opção de recuperação de arquivos e gere um script. Execute o script na VM de destino e anexe o ponto de recuperação como discos iSCSI. Em seguida, use clientes de banco de dados para executar as funções de validação específicas do banco de dados nos discos anexados e validar os dados de backup. Além disso, use clientes de banco de dados para exportar ou recuperar algumas tabelas ou arquivos em vez de recuperar o banco de dados inteiro.
• Use a funcionalidade "Cross Region Restore" para realizar as ações acima a partir de regiões secundárias vinculadas durante um desastre regional.

Resumo

Com snapshots consistentes com o banco de dados e o backup de logs usando uma solução personalizada, você pode criar uma solução de backup de banco de dados que seja eficiente e econômica. Essa solução usa os benefícios do backup de VM do Azure e também reutiliza os recursos dos clientes de banco de dados.