NetWorker: Otimizando operações de recuperação de espaço para o Data Domain

• Savesets do NetWorker marcados como expirados, mas não removidos
• As mensagens de recuperação de espaço são exibidas nos registros mais de uma vez por dia
• Impactos na velocidade e carga do Data Domain
• Impactos gerais no desempenho do servidor

• Os volumes qualificados para recuperação de espaço são lidos durante a ação de expiração (transferência, clonagem ou recuperação)
• A recuperação de espaço é executada por padrão após cada operação de preparo em um determinado volume
• A recuperação de espaço verifica cada arquivo em uma estrutura de diretório de volume ao executar a recuperação de espaço
• As operações e a capacidade de resposta do servidor podem ficar lentas durante a fase de recuperação de espaço

A fase de recuperação de espaço do NetWorker é executada uma vez por dia como uma das fases finais da ação Expiração no fluxo de trabalho de backup do servidor. O objetivo é excluir objetos de arquivo de saveset em um volume após a avaliação, a expiração e a exclusão de registros de saveset pelo servidor após o cálculo daqueles que são seguros remover de acordo com sua configuração.

Há vários fatores que podem ter impactos adversos na capacidade de resposta do servidor do Data Domain ou do NetWorker. Habilite qualquer um dos itens abaixo que pareçam atender aos requisitos da zona de dados em questão. Antes de considerar o teste com os arquivos-chave de depuração abaixo: Desative a ação de expiração de backup > diário do Server Protection > Server para desabilitar todos os cálculos de espaço de recuperação e banco de dados de mídia por um ou mais dias para confirmar se os problemas de desempenho encontrados estão relacionados às atividades de recuperação e/ou expiração de espaço.

Se a desativação da expiração confirmar o problema relacionado à manutenção diária, os recursos a seguir poderão ser desativados para solução de problemas criando um arquivo vazio de mesmo nome (sem uma extensão) no servidor ou nó do NetWorker no subdiretório de depuração do diretório nsr principal. Nenhum desses arquivos de indicador exige uma reinicialização e entrará em vigor com os trabalhos de recuperação de espaço iniciados enquanto estiverem presentes.

Local do Linux: /nsr/debug
Localização do Windows: C:\Program Files\EMC NetWorker\nsr\debug (ou caminho de instalação NSR correspondente)
 

Os nomes dos arquivos e suas funções são detalhados abaixo:

skip_recover_space_for_stage

• Nós de armazenamento. Esse indicador faz com que o NetWorker ignore a fase recover space de uma operação de staging (clonagem seguida de exclusão da origem). Se seu ambiente usa a transferência, particularmente a transferência a partir dos mesmos volumes de origem repetidamente, isso é recomendado, pois nega a possibilidade de gerar várias operações de espaço de recuperação para os mesmos volumes. Quando esse indicador está em vigor, a operação de recuperação de espaço é totalmente adiada, permitindo que o sistema exclua os arquivos quando a ação diária Expiration é executada ou o comando nsrimé executado manualmente. 

recover_space_anytime

• Somente servidor. Isso permite que o espaço de recuperação expire e remova savesets em volumes que estão lendo ativamente, o que, por padrão, é adiado. Isso significa que, para volumes que têm trabalhos de clone de longa execução, a expiração e a recuperação de espaço podem ser adiadas repetidamente quando a ação de expiração, nsrim ou um trabalho de preparo (consulte anterior) é executado. Isso, por sua vez, pode levar a grandes pendências de recuperação de espaço, esgotamento gradual do espaço livre e um trabalho de recuperação de espaço maior quando ele puder ser executado. 

skip_disk_usage

• Nós de armazenamento. Como parte da recuperação de espaço e da verificação do sistema de arquivos do volume de disco, por padrão, os arquivos individuais são verificados e contados recursivamente para produzir uma agregação precisa de dados para o volume. Embora alguns possam considerar essa precisão essencial, adiar essa etapa depende dos registros de banco de dados de mídia do NetWorker para os totais de bytes e arquivo, que geralmente podem ser esperados como precisos o suficiente para a maioria dos usos. Em um Data Domain muito carregado, especialmente em um em que muitas operações de espaço de recuperação são executadas repetidamente para volumes, isso pode ser considerado uma despesa desnecessária e desativada com segurança.

skip_consistency_check_in_recover_space

• Nós de armazenamento. Durante a recuperação de espaço para um volume, o file system do volume é verificado arquivo por arquivo para garantir a consistência entre o banco de dados de mídia; Isso também pode introduzir latência. A adição desse keyfile a cada nó impedirá que o nó exclua arquivos de saveset onde não existe um registro correspondente no banco de dados de mídia ou marque registros de banco de dados de mídia onde nenhum arquivo é encontrado como "suspeito". Observe que isso impedirá as operações normais de limpeza e deve ser usado para ajudar a qualificar a latência relacionada às operações de recuperação de espaço, e não deve ser desativado a longo prazo. 

Logs mais detalhados foram introduzidos por padrão, fazendo com que todos os caminhos do saveset sejam registrados nos logs de data_audit no servidor do NetWorker. Quando já há trabalhos de recuperação de espaço grande e carga pesada, esse é um fator que pode levar à falta de resposta, principalmente dos nós de armazenamento que retornam as informações remotamente para o NetWorker. Para desabilitar isso, aumente o limite de registro para esses registros no servidor do NetWorker:

# nsradmin
# nsradmin> show name; auditlog severity
# print type: nsr auditlog

Restrinja essa alteração para afetar apenas a auditoria de dados, se desejado, refinando a consulta para a instância específica incluindo seu nome. Ignore esta etapa para reaplicar a configuração a cada um:

# print type: nsr auditlog; name: servername_data_audit.raw

Altere o limite para um ou ambos para "Error" a fim de interromper o registro das exclusões individuais — as exclusões ainda serão registradas no daemon.raw do servidor.

# update auditlog severity: Error