O que é um backup de baixo impacto?
Em um dispositivo de backup/recuperação de Backup e DR em circunstâncias normais, o Backup e DR faz um backup inicial demorado de ingestão completa de um banco de dados e, em seguida, todos os backups subsequentes são backups incrementais 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 impacto é 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 incapacidade 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 de baixo impacto levam mais tempo do que os backups feitos em condições normais, porque precisam realizar 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 de baixo impacto
- Upgrades de conectores
- Reinicializações normais do sistema
- Reinicializações informadas do cbt_server ou do 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 o seguinte:
- Um encerramento inadequado do host:
- Um encerramento completo 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 encerramento completo ou um erro de tela azul. Isso é verdade 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 de 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 dos dados. Se um host de cluster que hospedava um banco de dados atingir uma BSOD, o bitmap poderá estar disponível no backup, mas ainda não ser confiável. Portanto, é necessária uma recuperação de baixo impacto.
- Falha na atualização de um módulo do kernel
- Uma falha ou uma reinicialização no daemon do modo de usuário
- Um erro de impressão digital ao executar 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 armazenamento em vault, se durante o desligamento do SO o disco de armazenamento estiver cheio e o sistema não puder gravar todos os dados no vault.
- Failover do nó do SAP HANA, fazendo com que o backup seja redirecionado para um nó diferente.
- O backup está sendo executado em modo degradado porque não é possível carregar o módulo do kernel. Isso geralmente ocorre quando o SO é uma versão não compatível.
- Se o cbt_server ou o AAMService for interrompido durante o backup, os bitmaps não poderão
ser buscados, e o job de backup será executado no modo de baixo impacto.
Se o AAMService não ficar inativo por muito tempo, a inicialização dele vai resultar
na disponibilização de bitmaps para um backup normal.
- Se o cbt_server ou o AAMService for interrompido por tempo suficiente para que alguns gigabytes de eventos sejam colocados em fila pelo driver, os bitmaps não poderão ser recriados e o backup ficará no modo de baixa inicialização. O tempo necessário depende da quantidade de E/S de disco que ocorre no banco de dados. Isso normalmente exige dias de inatividade do AAMService.
- O encerramento completo do cbt_server ou do AAMService pode fazer com que os bitmaps carregados no momento se tornem não confiáveis. Os bitmaps serão carregados se o arquivo rastreado tiver sido gravado nos últimos 15 minutos. Portanto, geralmente, para um banco de dados ocupado, isso causaria um baixo impacto.
- Se um volume que contém um arquivo rastreado (por exemplo, um arquivo .mdf do SQL Server) for desmontado no host e depois remontado, os bitmaps não serão confiáveis, porque não há como saber o que foi gravado no arquivo enquanto ele estava desmontado.