Avamar: Falha no backup NDMP com sinal fatal 11, falha de segmentação relacionada ao uso da memória de volume

Indicações de falha de backup

Os seguintes sintomas são observados quando um backup NDMP do Avamar identifica uma falha de segmentação (sinal 11):

• O trabalho de backup é abortado com uma mensagem de erro fatal semelhante a:

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

• As entradas de log mostram conjuntos de dados excepcionalmente grandes sendo processados, por exemplo:

avtar Info <8688>: Status 2017-10-13 19:32:37, 3,050,352 files, 2,419,299 directories, 5,119 GB (3,050,352 files, 1.913 GB, 41.42% new) 15049MB 60% CPU (1 open files)

• É relatado alto consumo de memória, geralmente excedendo 15 GB de RAM/SWAP para um único fluxo de backup.
• Vários fluxos NDMP estão ativos (até 8 por client), cada um possivelmente usando 2 GB ou mais de memória.
• Vários backups grandes podem ser executados simultaneamente, aumentando a carga geral do sistema.
• O volume afetado contém milhões de arquivos e diretórios (por exemplo, arquivos 3 M em diretórios de 2,4 M que cobrem 5,1 TB de dados).
• Mesmo quando apenas uma pequena quantidade de dados foi alterada (como, por exemplo, 1,9 GB), o processo de backup tenta enviar todos os arquivos do NAS para processamento.

Fatores subjacentes que desencadearam o sinal fatal 11.

O sinal 11 (falha de segmentação) é gerado quando um processo acessa a memória que não está alocada a ele. As seguintes condições causaram diretamente esse evento durante o backup NDMP do Avamar:

• Vários backups grandes do NDMP estavam em execução simultaneamente.
• Um backup processou 3.050.352 arquivos e 2.419.299 diretórios, totalizando 5,1 TB de dados, enquanto apenas 1,9 GB desses dados foram alterados.
• Cada fluxo NDMP pode consumir ≥ 2 GB de memória. O cliente tinha permissão para até 8 fluxos, e vários clientes estavam ativos simultaneamente, levando a uma alta demanda agregada de memória.
• O processo de backup usava aproximadamente 15 GB de RAM/SWAP antes da falha.
• O Avamar limita o número de fluxos por client, mas NÃO impõe um limite global ao número total de fluxos. Isso permite que o uso combinado da memória exceda os recursos disponíveis.

Essas condições de uso intenso de memória fizeram com que o processo avtar identificasse uma falha de segmentação, registrada no log como:

2017-10-13 19:42:00 avtar FATAL <5889>: Fatal signal 11 in pid 31103

Corrigindo falhas de backup NDMP do Avamar causadas pelo Signal 11 (falha de segmentação)

Etapa 1: avaliar a carga de backup atual.

Use o console do Avamar Administrator ou a CLI para identificar volumes que geram grandes backups NDMP.

Liste os trabalhos NDMP ativos e seu uso de recursos:

$ avtar -listjobs -type ndmp

 Etapa 2 - Reduzir os backups simultâneos de volume.

• Limite o número de volumes submetidos a backup simultaneamente para evitar o consumo excessivo de RAM/SWAP.
• No Avamar Administrator, edite o agendamento de backup e desmarque as janelas sobrepostas.

Etapa 3 - Dividir grandes volumes em subvolumes menores

• Identifique volumes com mais de 3 milhões de arquivos ou mais de 5 TB de dados (como no exemplo).
• Crie subvolumes lógicos um nível abaixo na árvore de diretórios.
• Configure cada subvolume como um client NDMP separado no Avamar.
  •  Exemplo: Criar um client NDMP para um subdiretório

$ avtar -addclient -name subvol1 -path /data/level2/subvol1

 Etapa 4 — Ajuste as configurações de fluxo do NDMP.

• Aumente o número máximo de fluxos NDMP por client se o NAS for compatível com ele.
• Na configuração NDMP NAS, aumente o limite de fluxo do padrão de 4 para 8 sempre que possível.

Etapa 5 - Limitar arquivos por fluxo

• Ao criar políticas de backup, defina um limite inferior de "arquivos por fluxo" para manter o espaço ocupado pela memória de cada fluxo em menos de 2 GB.
• Use as políticas → do Avamar Administrator → Advanced Settings para ajustar esse valor.

Etapa 6: monitorar o uso da memória durante os backups

• Observe o consumo de RAM e swap no Avamar Server enquanto o backup é executado.
• Certifique-se de que o uso permaneça bem abaixo do total de memória disponível (por exemplo, menos de 12 GB para um trabalho de 15 GB).
  • Monitoramento de memória em tempo real

$ top -b -n 1 | grep avtar

 Etapa 7 - Validar a correção

• Execute novamente o backup com falha anterior.
• Confirme se o log não contém mais o Fatal signal 11 .
• Verifique se o backup foi concluído com sucesso e se o tamanho dos dados relatados corresponde às expectativas.
  •  Verifique se há erros no log de backup mais recente

$ tail -n 50 /var/log/avtar/backup.log