O que é um backup de baixo impacto?
Em um dispositivo de backup/recuperação do Backup e DR em circunstâncias normais, o Backup e DR faz um backup completo inicial de um banco de dados, que leva muito tempo, e todos os backups subsequentes são incrementais e muito mais rápidos. Um backup incremental compara bitmaps do snapshot atual e do anterior e aplica apenas as mudanças incrementais.
Um backup de baixo splash é um tipo especial de job de backup que ocorre quando algum erro do sistema no job de backup anterior resulta em uma imagem de bitmap não confiável ou na impossibilidade de ler o bitmap. O serviço que lê o bitmap é cbt_server em um ambiente Linux e AAMService em um ambiente Windows.
Os backups com poucos respingos são mais demorados do que os feitos em condições normais porque precisam fazer uma ingestão completa novamente para recriar um bitmap confiável. Em seguida, ele pode aplicar as mudanças incrementais sem precisar substituir o backup completo.
O que não causa backups com pouco respingo
- Upgrades de conectores
- Reinicializações normais do sistema
- Reinicializações normais de cbt_server ou AAMService, supondo que o serviço ainda esteja em execução no momento do backup
Failovers que não apresentaram os erros que causam bitmaps não confiáveis.
Causas de bitmaps não confiáveis
Um bitmap não confiável ocorre quando algo interrompe o job de backup, incluindo:
- Um encerramento incorreto do host:
- Um desligamento não normal causa um splash baixo devido à falta de confiabilidade dos bitmaps. Isso inclui desligar uma máquina física ou qualquer outro método de desligar o Windows sem passar por um desligamento normal ou um erro de tela azul. Isso é válido mesmo que uma máquina em um cluster apresente um erro de tela azul que acione o failover, já que o bitmap da máquina com falha não é confiável.
- Se todos os servidores Windows em um cluster que hospedaram o banco de dados desde o backup anterior não estiverem disponíveis e executando o agente do Backup e DR. Extraímos bitmaps de cada host de cluster que hospedou o banco de dados desde o backup anterior para encontrar mudanças. Sem todos os bitmaps, precisamos executar o low-splash para manter a integridade de dados. Observação: se um host de cluster que hospedou um banco de dados apresentar uma tela azul da morte, o bitmap poderá estar disponível no backup, mas ainda não ser confiável. Por isso, é necessária uma recuperação de baixo splash.
- Uma atualização com falha do módulo do kernel
- Uma falha ou reinicialização no daemon do modo de usuário
- Um erro de impressão digital durante a execução de um backup. O Backup e DR realiza uma "verificação de impressão digital" em cada job de backup para verificar se há erros.
- Erro durante o arquivamento, se durante o desligamento do SO o disco de armazenamento estiver cheio e o sistema não conseguir gravar todos os dados no cofre.
- Failover do nó do SAP HANA, fazendo com que o backup seja redirecionado para um nó diferente.
- O backup está sendo executado no modo degradado porque não foi possível carregar o módulo do kernel. Isso geralmente acontece quando o SO é uma versão não compatível.
- Se cbt_server ou AAMService for interrompido durante o backup, os bitmaps não poderão
ser buscados, e o job de backup será executado no modo de baixa tela inicial.
Se o AAMService não ficar inativo por muito tempo, iniciar o AAMService vai resultar
em bitmaps disponíveis para um backup normal.
- Se o cbt_server ou o AAMService for interrompido por tempo suficiente para que alguns gigabytes de eventos sejam enfileirados pelo driver, os bitmaps não poderão ser recriados e o backup estará no modo de baixa exibição. O tempo necessário para isso depende da quantidade de E/S de disco no banco de dados. Isso normalmente exige dias de inatividade do AAMService.
- O encerramento não normal do cbt_server ou do AAMService pode fazer com que os bitmaps se tornem não confiáveis para qualquer bitmap carregado no momento. Os bitmaps são carregados se o arquivo rastreado tiver sido gravado nos últimos 15 minutos. Portanto, geralmente, para um banco de dados ocupado, isso causaria um splash baixo.
- Se um volume que contém um arquivo rastreado (por exemplo, um arquivo .mdf do SQL Server) for desmontado no host e remontado, os bitmaps não serão confiáveis, já que não há como saber o que foi gravado no arquivo enquanto ele estava desmontado.