Avamar: Los respaldos de VM Linux pueden tener incoherencia en los metadatos de LVM si se implementan desde una plantilla

Durante la restauración, se observan los siguientes síntomas:

1. Falla de operación de FLR con el problema de LVM:
   

   O
   
   2 VM

2. Los trabajos restaurados a imagen se realizaron correctamente en la interfaz de usuario de Avamar; es posible que la máquina virtual (VM) tenga un problema de arranque debido a un problema de LVM.

   Ejemplo de problema de arranque 1:
   En el siguiente ejemplo de Red Hat, el sistema operativo se inicia en un shell dracut de emergencia:
   

   (En este ejemplo) desde el shell dracut, el siguiente comando de LVM repara el estado de LVM. El resultado muestra que el problema fue que uno de los discos lvm (sdb) se eliminó incorrectamente de LVM.

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

   
   Ahora se puede iniciar la máquina virtual recuperada.

   Ejemplo de problema de arranque 2:
   En el ejemplo de Debian, el sistema operativo arranca en un shell de caja ocupada de emergencia:
   

   (En este ejemplo) desde el shell de caja ocupada, lo siguiente lvm comando de restauración del estado del grupo de volúmenes LVM de la configuración anterior:

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

    

   Nota: vm1-vg es el nombre del grupo de volúmenes en este ejemplo

    

   
   Ahora se puede iniciar la máquina virtual recuperada.

Otros síntomas:

Las máquinas virtuales (VM) de producción se pueden reiniciar correctamente. El problema solo afecta a las copias de respaldo de VM Linux que utilizan LVM y que se implementaron desde la misma plantilla.
Las máquinas virtuales Windows y Linux que NO utilizan configuraciones de LVM NO presentan problemas de FLR ni de arranque con las copias de respaldo.

Antecedentes de metadatos de LVM:

1. Las VM Linux configuradas con LVM se clonan o se implementan desde la misma plantilla. Las nuevas máquinas virtuales resultantes tienen identificadores únicos de LVM (UUID) idénticos.
2. Cualquier cambio realizado en los discos LVM (por ejemplo, agregar un disco virtual a LVM) requiere una actualización de la información de metadatos de LVM. LVM realiza un seguimiento de estas actualizaciones mediante un campo llamado números de secuencia de revisión (vg_seqno). Este número aumenta cada vez que se realiza un cambio.

Problema de respaldo de adición en caliente:
Durante el respaldo de Avamar, si se cumplen las siguientes condiciones:

1. Las VM de origen y las clonadas se respaldan simultáneamente mediante la adición en caliente (el método de transporte predeterminado).
2. Ambas VM se agregan en caliente mediante el mismo proxy de Avamar.
3. Las revisiones de LVM difieren entre las VM que se agregan en caliente.

El kernel de Linux del proxy de Avamar supone incorrectamente que los discos de las dos VM están en el mismo grupo de volúmenes LVM y actualiza los metadatos de LVM automáticamente. Si se produce esta actualización de LVM, los metadatos de LVM son incoherentes en la copia de respaldo.

Problema de restauración:
Durante la imagen, es posible que la VM muestre "Faltan extensiones físicas de LVM" o "Discrepancias de ID de transacción" debido a metadatos de LVM incorrectos actualizados durante el respaldo de adición en caliente. Esta discrepancia surge de la actualización antes mencionada.

Herramientas LVM de recuperación, como vgcfgrestore, vgextend –restoremissingY vgchange -ay –activationmodepartial Es posible que sea necesario para permitir un arranque completo o reparar la copia de respaldo a fin de corregir el estado de LVM.

Este problema se resuelve en las revisiones de proxy de Avamar:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Versión anterior de Avamar: Consulte las notas a continuación.

Estas revisiones reconfiguran la configuración de LVM en el proxy de Avamar para evitar las actualizaciones de metadatos de LVM durante las operaciones de adición en caliente.

ANTES del hotfix

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

DESPUÉS del hotfix

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

Para cualquiera de los clientes afectados, debemos forzar un respaldo L0 de seguimiento de bloques modificados (CBT). Esto garantiza que se capturen los metadatos de LVM correctos en los respaldos nuevos.

Para ayudar en la detección de clientes, el equipo de ingeniería de Avamar desarrolló un nuevo script. Este script analiza los respaldos de Linux en busca de incoherencias de LVM y restablece automáticamente cbt para el siguiente trabajo si se encuentra alguna.

vmlvmcheck.pl

1. Este script debe estar instalado en el servidor Avamar.
2. El script se debe ejecutar como usuario raíz.
3. Este script analiza el respaldo más reciente de todos los clientes de máquinas virtuales Linux y comprueba la coherencia de LVM.
4. Este script puede requerir mucho tiempo (horas) si se analizan muchas máquinas virtuales. De manera predeterminada, si la cantidad de máquinas virtuales escaneadas supera los 50, el script se ejecuta en segundo plano/modo demonio.

Lógica del script:
El script localiza los volúmenes lógicos de LVM en respaldos .vmdk y verifica las siguientes condiciones:

1. Garantiza que todos los volúmenes físicos estén presentes en el respaldo
2. Valida que todos los volúmenes físicos estén asociados con un grupo de volúmenes LVM
3. Todos los volúmenes físicos para el mismo grupo de volúmenes tienen números de secuencia idénticos.

Falsos positivos:

1. Si algunos de los discos virtuales para un grupo de volúmenes detectado NO se incluyeron, respaldará esta herramienta marcará el respaldo. La causa raíz no está relacionada con el problema de adición en caliente descrito anteriormente. En este caso, asegúrese de que Avamar respalde todos los discos virtuales.
2. Si alguno de los discos virtuales contiene una partición LVM que NO está completamente inicializada, la herramienta identifica el respaldo como defectuoso. Sin embargo, en este escenario, el sistema operativo NO tendría ningún problema de arranque.

Instrucciones de descarga:

1. Descargue vmlvmcheck.pl desde el sitio web de central.dell.com . Para obtener más información sobre Central, consulte KB Avamar: Cómo encontrar y descargar scripts y herramientas de Avamar desde la página de Dell Central Avamar.
   

2. Transfiera vmlvmchck.pl al directorio "/root" en el servidor Avamar mediante una herramienta como WinSCP.

   Ejemplo 1 (función de solo lectura) Analiza el respaldo más reciente de todos los clientes de 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 %
   
   

   O bien , cuando el recuento total de VM escaneadas supera 50, el script se ejecuta automáticamente en segundo plano en su lugar:

   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

   Ejemplo 2 (función de solo lectura) Analice el respaldo más reciente de un solo cliente mediante --vm <vm name> o 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

   Ejemplo 3 (función grabable) Igual que los ejemplos 1 y 2, pero esta vez el --DELETE_SNAPSHOTS Se agregó la opción

   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

Configuración manual de LVM para proxies de Avamar más antiguos o sin parches

1. Como raíz del proxy respalde el archivo lvm.conf

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

2. Edite /etc/lvm/lvm.conf, busque la línea de "filtro" existente y cambie a lo siguiente.

   ANTES:

       filter = [ "a/.*/" ]

   DESPUÉS

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

3. Verifique que la nueva configuración de filtro esté establecida mediante la ejecución de este comando

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