Avamar: Os backups de VM Linux podem ter inconsistência de metadados LVM se forem implantados a partir de um modelo

Durante a restauração os seguintes sintomas são vistos:

1. Falha de operação FLR com problema de LVM:
   

   OU 2 VM
   
   

2. Os trabalhos restaurados de imagem são bem-sucedidos na IU do Avamar, a máquina virtual (VM) pode ter problemas de arranque devido a um problema de LVM.

   Exemplo de problema de inicialização 1:
   Neste exemplo da Red Hat abaixo, o sistema operacional inicializa em um shell dracut de emergência:
   

   (Neste exemplo) do shell dracut, o comando LVM a seguir repara o estado do LVM. A saída mostra que o problema era que um dos discos lvm (sdb) foi removido incorretamente do LVM.

   dracut:/# lvm pvscan --config 'global{locking_type=1}'

   
   Agora a máquina virtual recuperada pode inicializar.

   Exemplo de problema de inicialização 2:
   No exemplo Debian, o sistema operacional inicializa em um shell de caixa ocupado de emergência:
   

   (Neste exemplo) do shell de caixa ocupado, o seguinte: lvm comando restaurar o estado do grupo de volumes LVM da configuração anterior:

   (initramfs)  lvm vgcfgrestore vm1-vg   --config 'global{locking_type=1}'

    

   Nota: vm1-vg é o nome do grupo de volumes neste exemplo

    

   
   Agora a máquina virtual recuperada pode inicializar.

Outros sintomas:

As máquinas virtuais (VMs) de produção podem reiniciar com êxito. O problema afeta apenas cópias de backup de VMs Linux que usam LVM e foram implantadas a partir do mesmo modelo.
As máquinas virtuais Windows e Linux que NÃO usam configurações LVM NÃO apresentam o FLR ou problemas de inicialização com as cópias de backup.

Fundo de metadados LVM:

1. As VMs Linux configuradas com LVM são clonadas ou implantadas a partir do mesmo modelo. As novas máquinas virtuais resultantes têm identificadores únicos LVM (UUIDs) idênticos.
2. Quaisquer alterações feitas em discos LVM (por exemplo, adicionar um disco virtual ao LVM) exigem uma atualização das informações de metadados LVM. O LVM rastreia essas atualizações usando um campo chamado números de sequência de revisão (vg_seqno). Este número é incrementado sempre que é feita uma alteração.

Problema de backup de adição a quente:
Durante o backup do Avamar, se forem satisfeitas as seguintes condições:

1. O backup das VMs de origem e clonadas é feito simultaneamente usando o hot add (o método de transporte padrão).
2. Ambas as VMs são adicionadas a quente usando o mesmo proxy Avamar.
3. As revisões LVM diferem entre as VMs que estão sendo adicionadas a quente.

O kernel Linux do proxy Avamar assume incorretamente que os discos das duas VMs estão no mesmo grupo de volumes LVM, atualizando os metadados LVM automaticamente. Se essa atualização LVM ocorrer, os metadados LVM serão inconsistentes na cópia de backup.

Problema de restauro:
Durante a imagem, a VM pode exibir "Extensões físicas LVM ausentes" ou "Incompatibilidades de ID de transação" devido a metadados LVM incorretos atualizados durante o backup de adição a quente. Esta discrepância decorre da atualização acima mencionada.

Ferramentas LVM de recuperação, como vgcfgrestore, vgextend –restoremissinge vgchange -ay –activationmodepartial pode ser necessário para permitir o arranque completo ou para reparar a cópia de segurança para corrigir o estado do LVM.

Este problema é resolvido nas correcções de proxy Avamar:
Avamar 19.4 333146.
Avamar 19,3 333148.
Avamar 19.2 333149.
Versão mais antiga do Avamar: Veja as notas abaixo.

Esses hotfixes reconfiguram a configuração LVM no proxy Avamar para evitar atualizações de metadados LVM durante operações de adição dinâmica.

ANTES do hotfix

194proxy:~ # lvm config | grep filter
        filter="a/.*/"

APÓS o hotfix

194proxy:~ # lvm config | grep filter
        filter=["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]

Para qualquer um dos clientes afetados, devemos forçar um backup CBT (Change Block Tracking) L0. Isso garante que os metadados LVM corretos sejam capturados em novos backups.

Para ajudar na detecção de clientes, a equipe de engenharia do Avamar desenvolveu um novo script. Este script verifica os backups do Linux em busca de inconsistências LVM e redefine automaticamente o cbt para o próximo trabalho, se algum for encontrado.

vmlvmcheck.pl

1. Este script deve ser instalado no servidor Avamar.
2. O script deve ser executado como o usuário raiz.
3. Este script verifica o backup mais recente de todos os clientes de máquinas virtuais Linux e verifica a consistência do LVM.
4. Esse script poderá demorar bastante tempo (horas), se estiver examinando muitas máquinas virtuais. Por padrão, se o número de VM verificadas exceder 50, o script será executado em segundo plano/modo daemon.

Lógica de Script:
O script localiza volumes lógicos LVM em backups .vmdk e verifica as seguintes condições:

1. Garante que todos os volumes físicos estão presentes no backup
2. Valida que todos os volumes físicos estão associados a um grupo de volumes LVM
3. Todos os volumes físicos para um mesmo grupo de volumes têm números de sequência idênticos.

Falsos positivos:

1. Se alguns dos discos virtuais de um grupo de volumes descoberto NÃO foram incluídos, ele faz backup desta ferramenta sinalizando backup. A causa raiz não está relacionada ao problema de adição a quente descrito acima. Neste caso, certifique-se de que o Avamar está a fazer uma cópia de segurança de todos os discos virtuais.
2. Se algum dos discos virtuais contiver uma partição LVM que NÃO esteja totalmente inicializada, a ferramenta identificará o backup como ruim. No entanto, neste cenário, o sistema operativo NÃO teria qualquer problema de arranque.

Transferir instruções:

1. Transfira vmlvmcheck.pl a partir do Web site da central.dell.com . Para obter mais informações sobre a central, consulte KB Avamar: Como encontrar e transferir scripts e ferramentas Avamar a partir da página Dell Central Avamar.
   

2. Transfira vmlvmchck.pl para o diretório '/root' no servidor Avamar utilizando uma ferramenta como o WinSCP.

   Exemplo 1 (função somente leitura) Verifica o backup mais recente de todos os clientes VM Linux.

   root@ave194:~/vmlvmcheck/#: perl vmlvmcheck.pl
   11:37:13 2021-10-06 : vmlvmcheck.pl version 19.04 @ave194
   11:37:14 14 VMs populated. Processing backups for these...
   <list of vms>  
   
   “===== 3 Vm(s) with potential LVM inconsistency  in backup ===
   vm1,vm2,vm3
   11:40:08 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---  (after 2 minutes, 55 seconds)
           11      Activities examined
           11      Backups to DD
           30      Files Examined
           12.500  Run Sec per VM
           2.917   Run Time Minutes
           14      VMs Enabled
           14      VMs Total
           3       VMs With Inconsistent backups
           21.43 %         VMs With Inconsistent backups %
   
   

   OU Quando a contagem total de VMs digitalizadas excede 50, o script é executado automaticamente em segundo plano:

   root@ave194:/home/admin/#: perl vmlvmcheck.pl 
   10:55:34 2021-11-17 : vmlvmcheck.pl version 19.15 @ave194
   10:55:35 55 VMs populated. Processing backups for these...
   Output is now going to /usr/local/avamar/var/log/vmvlmcheck.log .
   PID# 3563 is now running vmlvmcheck as a background process.
   To terminate daemon process, enter:
        kill  3563
   Please run:  tail -f /usr/local/avamar/var/log/vmvlmcheck.log

   Exemplo 2 (função somente leitura) Analise o backup mais recente de um único cliente usando --vm <vm name> laranja ou azul

   root@ave194:/home/admin/#: perl vmlvmcheck.pl --vm cloud2116-clone1
   18:13:57 2021-10-05 : vmlvmcheck.pl version 19.04 @ave194
   18:13:57 1 VMs populated. Processing backups for these...
   INFO:============ cloud2116-clone1  /vc6-avamar.gslabs.lab.emc.com/ContainerClients: 1 Backups
   WARNING: pvs Did not see a LVM on /dev/loop1
   ERROR: Expected LVM member appears damaged:VMFiles/2/virtdisk-flat.vmdk.
   INFO: No partitions found in VMFiles/2/virtdisk-flat.vmdk.
   VM cskpcloud2116-clone1 has 1 LVMs inside 2 vmdks.
   ERROR: Bad backup: labelnum=2
   2 Snapshots to be deleted ...Option DELETE_SNAPSHOTS=0.
   18:14:09 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---
           1       Activities examined
           1       Backups to DD
           2       Files Examined
           12.000  Run Sec per VM
           0.200   Run Time Minutes
           1       VMs Enabled
           1       VMs Total

   Exemplo 3 (função gravável) O mesmo que os Exemplos 1 e 2, mas desta vez o --DELETE_SNAPSHOTS opção é adicionada

   root@ave194:~/vmlvmcheck/#: perl vmlvmcheck.pl --vm cloud2116-clone1  --DELETE_SNAPSHOTS
   14:13:35 2021-10-06 : vmlvmcheck.pl version 19.04 @ave194
   14:13:36 1 VMs populated. Processing backups for these...
   INFO:============ cloud2116-clone1  /vc6-avamar.gslabs.lab.emc.com/ContainerClients: 1 Backups
   WARNING: pvs Did not see a LVM on /dev/loop1
   ERROR: Expected LVM member appears damaged:VMFiles/2/virtdisk-flat.vmdk.
   INFO: No partitions found in VMFiles/2/virtdisk-flat.vmdk.
   VM cskpcloud2116-clone1 has 1 LVMs inside 2 vmdks.
   ERROR: Bad backup: labelnum=2
   2 Snapshots to be deleted ...Option DELETE_SNAPSHOTS=1.
   14:13:49 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---
           1       Activities examined
           1       Backups to DD
           2       Files Examined
           14.000  Run Sec per VM
           0.233   Run Time Minutes
           1       VMs Enabled
           1       VMs Total

Definição LVM manual para proxies Avamar mais antigos ou não corrigidos

1. Como backup de raiz do proxy, o arquivo lvm.conf

   194proxyga:~ # cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf-`date +%s

2. Edite o /etc/lvm/lvm.conf, procure a linha "filtro" existente e mude para o seguinte.

   ANTES:

       filter = [ "a/.*/" ]

   DEPOIS

       filter = ["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]

3. Verifique se a nova configuração do filtro está definida executando este comando

   194proxy:~ # lvm config | grep filter
           filter=["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]