Causas das cópias de segurança de bases de dados com poucos dados

O que é uma cópia de segurança com pouca atividade?

Em circunstâncias normais, o serviço de cópia de segurança e recuperação de desastres faz uma cópia de segurança de ingestão completa inicial demorada de uma base de dados e, em seguida, todas as cópias de segurança subsequentes são cópias de segurança incrementais muito mais rápidas. Uma cópia de segurança incremental compara os mapas de bits do instantâneo atual e do instantâneo anterior, e aplica apenas as alterações incrementais.

Uma cópia de segurança com poucos detalhes é um tipo especial de tarefa de cópia de segurança que ocorre quando um erro de sistema na tarefa de cópia de segurança anterior resulta numa imagem bitmap não fiável ou numa incapacidade de ler o bitmap. O serviço que lê o mapa de bits é cbt_server num ambiente Linux e AAMService num ambiente Windows.

As cópias de segurança com pouca dispersão demoram mais tempo do que as cópias de segurança feitas em condições normais, porque têm de fazer novamente um carregamento completo para recriar um mapa de bits fiável. Em seguida, pode aplicar as alterações incrementais sem ter de substituir a imagem completa.

O que não causa cópias de segurança com pouco impacto

  • Atualizações de conetores
  • Reinícios do sistema elegantes
  • Reinícios normais de cbt_server ou AAMService, assumindo que o serviço ainda está em execução no momento da cópia de segurança
  • Comutações por falha que não sofreram os erros que causam mapas de bits não fiáveis.

Causas de mapas de bits não fiáveis

Ocorre um mapa de bits não fiável quando algo interrompe a tarefa de cópia de segurança, incluindo o seguinte:

  • Um encerramento não limpo do anfitrião
    • Um encerramento não elegante causa um efeito de ondulação baixo devido à falta de fiabilidade dos mapas de bits. Isto inclui desligar a alimentação de uma máquina física ou qualquer outro método de desligar o Windows sem passar por um encerramento normal ou um erro de ecrã azul. Isto é verdade mesmo que uma máquina num cluster detete um erro de ecrã azul que acione a comutação por falha, uma vez que o mapa de bits da máquina com falha não é fiável.
    • Se todos os servidores Windows num cluster que alojaram a base de dados desde a cópia de segurança anterior não estiverem disponíveis e a executar serviços Actifio. Extraímos mapas de bits de cada anfitrião do cluster que alojou a base de dados desde a cópia de segurança anterior para encontrar alterações e, sem todos os mapas de bits, temos de executar o low-splash para manter a integridade dos dados. Tenha em atenção que, se um anfitrião de cluster que alojou uma base de dados tiver um BSOD, o mapa de bits pode estar disponível na cópia de segurança, mas continua a não ser fiável, por isso, é de baixo impacto.
  • Uma atualização do módulo do kernel falhou
  • Uma falha ou um reinício no daemon do modo de utilizador
  • Um erro de impressão digital durante a execução de uma cópia de segurança. (O serviço de cópia de segurança e recuperação de desastres executa uma "verificação de impressões digitais" em cada tarefa de cópia de segurança para verificar se existem erros.)
  • Erro durante a proteção, se, durante o encerramento do SO, o disco de armazenamento estiver cheio e o sistema não conseguir escrever todos os dados no cofre.
  • A comutação por falha do nó do SAP HANA, que faz com que a cópia de segurança seja redirecionada para um nó diferente.
  • A cópia de segurança está a ser executada no modo degradado devido à incapacidade de carregar o módulo do kernel. Normalmente, isto ocorre quando o SO é uma versão não suportada.
  • Se cbt_server ou AAMService for parado durante a cópia de segurança, não é possível obter mapas de bits e a tarefa de cópia de segurança é executada no modo de apresentação rápida. Se o AAMService não estiver inativo durante muito tempo, o início do AAMService resulta na disponibilização de mapas de bits para uma cópia de segurança normal.
    • Se o cbt_server ou o AAMService for parado durante tempo suficiente para que o controlador coloque em fila alguns gigabytes de eventos, não é possível recriar os mapas de bits e a cópia de segurança fica no modo de apresentação de baixa qualidade. O tempo que este processo demora depende da quantidade de operações de entrada/saída de disco que ocorrem na base de dados. Normalmente, isto requer dias de indisponibilidade do AAMService.
  • O encerramento não gracioso do cbt_server ou do AAMService pode fazer com que os mapas de bits se tornem não fiáveis para quaisquer mapas de bits carregados atualmente. Os mapas de bits são carregados se o ficheiro monitorizado tiver sido escrito nos últimos 15 minutos, pelo que, geralmente, para uma base de dados ocupada, isto causaria um efeito de respingo baixo.
  • Se um volume que contenha um ficheiro monitorizado (por exemplo, um ficheiro .mdf do SQL Server) for desmontado no anfitrião e, em seguida, remontado, os mapas de bits não são fiáveis, uma vez que não existe forma de saber o que foi escrito no ficheiro enquanto estava desmontado.