Avamar: Back-ups van Linux-VM's kunnen inconsistente LVM-metadata bevatten als ze worden geïmplementeerd vanaf een sjabloon

Tijdens Restore worden de volgende symptomen waargenomen:

1. FLR-bewerkingsfout met LVM-probleem:
   

   OF
   
   2 VM

2. Herstelde taken voor images zijn succesvol in de Avamar UI, de virtuele machine (VM) heeft mogelijk opstartproblemen als gevolg van een LVM-probleem.

   Voorbeeld van opstartprobleem 1:
   In dit Red Hat-voorbeeld hieronder start het besturingssysteem op in een noodgeval:
   

   (In dit voorbeeld) vanuit de dracut-shell wordt de LVM-status hersteld met de volgende LVM-opdracht. De output laat zien dat het probleem was dat een van de lvm-schijven (sdb) ten onrechte uit LVM was verwijderd.

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

   
   Nu kan de herstelde virtuele machine opstarten.

   Voorbeeld van opstartprobleem 2:
   In het voorbeeld van Debian start het besturingssysteem op in een bezet-mailbox voor noodgevallen:
   

   (In dit voorbeeld) vanuit de shell van het bezette vak het volgende: lvm opdracht om status van LVM-volumegroep uit vorige configuratie te herstellen:

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

    

   Opmerking: vm1-vg is de naam van de volumegroep in dit voorbeeld

    

   
   Nu kan de herstelde virtuele machine opstarten.

Overige symptomen:

De productie virtuele machines (VM's) kan opnieuw opstarten. Het probleem is alleen van invloed op back-upkopieën van Linux-VM's die LVM gebruiken en zijn geïmplementeerd vanaf dezelfde sjabloon.
Virtuele Windows- en Linux-machines die GEEN LVM-configuraties gebruiken, vertonen GEEN FLR of opstartproblemen met de back-upkopieën.

Achtergrond LVM-metadata:

1. Linux-VM's die zijn geconfigureerd met LVM worden gekloond of geïmplementeerd op basis van dezelfde sjabloon. De resulterende nieuwe virtuele machines hebben identieke LVM Unique Identifiers (UUID's).
2. Voor alle wijzigingen die worden aangebracht in LVM-schijven (bijvoorbeeld het toevoegen van een virtuele schijf aan LVM) is een update van de LVM-metadata-informatie noodzakelijk. LVM houdt deze updates bij met behulp van een veld met de naam revisievolgnummers (vg_seqno). Dit aantal wordt verhoogd wanneer een wijziging wordt aangebracht.

Hot add back-upprobleem:
Als tijdens Avamar-back-up aan de volgende voorwaarden wordt voldaan:

1. Er wordt tegelijkertijd een back-up gemaakt van zowel de bron- als de gekloonde VM's met behulp van hot add (de standaard transportmethode).
2. Beide VM's worden hot toegevoegd met dezelfde Avamar proxy.
3. De LVM-revisies verschillen tussen de VM's die hot added worden.

De Linux-kernel van de Avamar proxy gaat er ten onrechte van uit dat de schijven van de twee VM's zich in dezelfde LVM-volumegroep bevinden, waardoor de LVM-metadata automatisch worden bijgewerkt. Als deze LVM-update plaatsvindt, zijn de LVM-metadata inconsistent in de back-up.

Herstelprobleem:
Tijdens de image kan de VM "Missing LVM physical extents" of "Transaction ID mismatches" weergeven als gevolg van onjuiste LVM-metadata die zijn bijgewerkt tijdens de hot add back-up. Deze discrepantie komt voort uit de eerder genoemde update.

Recovery LVM-tools zoals vgcfgrestore, vgextend –restoremissingen vgchange -ay –activationmodepartial kan nodig zijn om volledig opstarten mogelijk te maken of om de back-upkopie te repareren om de LVM-status te corrigeren.

Dit probleem is opgelost in Avamar proxy-hotfixes:
Avamar 19.4 333146.
Avamar 19,3 333148.
Avamar 19,2 333149.
Older Avamar version: Zie opmerkingen hieronder.

Met deze hotfixes wordt de LVM-instelling op de Avamar Proxy opnieuw geconfigureerd om te voorkomen dat LVM-metagegevens worden bijgewerkt tijdens hot add-bewerkingen.

VOOR hotfix

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

NA hotfix

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

Voor alle clients die worden getroffen, moeten we een Change Block Tracking (CBT) L0-back-up forceren. Dit zorgt ervoor dat de juiste LVM-metadata wordt vastgelegd in nieuwe back-ups.

Om te helpen bij het detecteren van clients heeft Avamar Engineering een nieuw script ontwikkeld. Dit script scant Linux-back-ups op LVM-inconsistenties en stelt cbt automatisch opnieuw in voor de volgende taak als die worden gevonden.

vmlvmcheck.pl

1. Dit script moet op de Avamar-server worden geïnstalleerd.
2. Het script moet worden uitgevoerd als de hoofdgebruiker.
3. Dit script scant de meest recente back-up van alle virtuele Linux-machineclients en controleert de LVM-consistentie.
4. Dit script kan een lange duur (uren) vereisen als het veel virtuele machines scant. Als het aantal gescande VM's meer dan 50 is, wordt het script standaard uitgevoerd in de achtergrond-/daemonmodus.

Script Logica:
Het script lokaliseert logische LVM-volumes in .vmdk-back-ups en controleert de volgende omstandigheden:

1. Zorgt ervoor dat alle fysieke volumes aanwezig zijn in de back-up
2. Valideert of alle fysieke volumes zijn gekoppeld aan een LVM-volumegroep
3. Alle fysieke volumes voor dezelfde volumegroep hebben identieke volgnummers.

Fout-positieven:

1. Als enkele van de virtuele schijven voor een gedetecteerde volumegroep NIET zijn opgenomen, wordt een back-up van deze tool als back-up gemarkeerd. De hoofdoorzaak heeft niets te maken met het hierboven beschreven hot add-probleem. Controleer in dit geval of Avamar een back-up maakt van alle virtuele schijven.
2. Als een van de virtuele schijven een LVM-partitie bevat die NIET volledig is geïnitialiseerd, identificeert het hulpprogramma de back-up als slecht. In dit scenario zou het besturingssysteem echter GEEN opstartprobleem hebben.

Downloadinstructies:

1. Download vmlvmcheck.pl van de central.dell.com website. Zie KB Avamar voor meer informatie over Central: Avamar scripts en tools vinden en downloaden op de Dell Central Avamar pagina.
   

2. Breng vmlvmchck.pl over naar de map '/root' op de Avamar-server met behulp van een tool zoals WinSCP.

   Voorbeeld 1 (alleen-lezen functie) Scant de meest recente back-up van alle Linux VM-clients.

   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 %
   
   

   OF Wanneer het totale aantal gescande vm's meer dan 50 is, wordt het script automatisch op de achtergrond uitgevoerd:

   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

   Voorbeeld 2 (alleen-lezen functie) Scan de meest recente back-up van één client met behulp van --vm <vm name> Vlag

   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

   Voorbeeld 3 (beschrijfbare functie) Zelfde als voorbeeld 1 en 2, maar deze keer de --DELETE_SNAPSHOTS Optie is toegevoegd

   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

Handmatige LVM-instelling voor oudere of niet-gepatchte Avamar-proxy's

1. Als proxy-rootback-up van het lvm.conf-bestand

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

2. Bewerk de /etc/lvm/lvm.conf, zoek naar de bestaande "filter"-regel en verander naar het volgende.

   VOORDAT

       filter = [ "a/.*/" ]

   NA

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

3. Controleer of de nieuwe filterinstelling is ingesteld door deze opdracht uit te voeren

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