Avamar: Säkerhetskopieringar av virtuella Linux-datorer kan ha inkonsekvens i LVM-metadata om de distribueras från en mall

Under återställningen visas följande symptom:

1. FLR-åtgärdsfel med LVM-problem:
   

   ELLER
   
   2 VM

2. Återställningsjobb för avbildning lyckas i Avamar-användargränssnittet, den virtuella maskinen (VM) kan ha startproblem på grund av ett LVM-problem.

   Exempel på startproblem 1:
   I det här Red Hat-exemplet nedan startar operativsystemet i ett dracut-nödskal:
   

   (I det här exemplet) från dracut-gränssnittet reparerar följande LVM-kommando LVM-tillståndet. Utdata visar att problemet var att en av lvm-diskarna (sdb) felaktigt togs bort från LVM.

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

   
   Nu kan den återställda virtuella maskinen starta.

   Exempel på startproblem 2:
   I Debian-exemplet startar operativsystemet i ett nödskal för upptaget:
   

   (I det här exemplet) från Upptagen-rutans gränssnitt följande lvm kommando för återställning av LVM-volymgruppstillstånd från tidigare konfiguration:

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

    

   Obs! vm1-vg är volymgruppens namn i det här exemplet

    

   
   Nu kan den återställda virtuella maskinen starta.

Andra symtom:

De virtuella produktionsdatorerna (VM) kan startas om. Problemet påverkar bara säkerhetskopior av virtuella Linux-datorer som använder LVM och distribuerades från samma mall.
Virtuella Windows- och Linux-datorer som INTE använder LVM-konfigurationer uppvisar INTE FLR- eller startproblem med säkerhetskopiorna.

Bakgrund för LVM-metadata:

1. Virtuella Linux-datorer som konfigurerats med LVM klonas eller distribueras från samma mall. De resulterande nya virtuella datorerna har identiska unika LVM-identifierare (UUID:er).
2. Alla ändringar som görs på LVM-diskar (till exempel att lägga till en virtuell disk i LVM) kräver en uppdatering av LVM-metadatainformationen. LVM spårar dessa uppdateringar med hjälp av ett fält som kallas revisionssekvensnummer (vg_seqno). Det här antalet ökas när en ändring görs.

Problem med säkerhetskopiering under frekvent tillägg:
Under Avamar-säkerhetskopieringen, om följande villkor är uppfyllda:

1. Både källan och de klonade virtuella datorerna säkerhetskopieras samtidigt med hjälp av frekvent tillägg (standardtransportmetoden).
2. Båda de virtuella datorerna läggs till snabbt med samma Avamar-proxy.
3. LVM-revisionerna skiljer sig åt mellan de virtuella datorer som läggs till under drift.

Avamar-proxyns Linux-kernel förutsätter felaktigt att de två virtuella datorernas diskar finns i samma LVM-volymgrupp och uppdaterar LVM-metadata automatiskt. Om den här LVM-uppdateringen sker är LVM-metadata inkonsekventa i säkerhetskopian.

Återställningsproblem:
Under bilden kan den virtuella datorn visa "Saknade LVM-fysiska omfattningar" eller "Transaktions-ID-matchningsfel" på grund av felaktiga LVM-metadata som uppdaterats under säkerhetskopieringen av frekvent tillägg. Denna avvikelse beror på den tidigare nämnda uppdateringen.

LVM-verktyg för återställning, t.ex. vgcfgrestore, vgextend –restoremissingoch vgchange -ay –activationmodepartial kan krävas för att tillåta fullständig uppstart eller för att reparera säkerhetskopian för att korrigera LVM-tillståndet.

Det här problemet åtgärdas i Avamar-proxysnabbkorrigeringar:
Avamar 19.4 333146.
Avamar 19,3 333148.
Avamar 19.2 333149.
Äldre Avamar-version: Se anteckningar nedan.

Dessa snabbkorrigeringar konfigurerar om LVM-inställningen på Avamar-proxyn för att förhindra LVM-metadatauppdateringar under snabba tilläggsåtgärder.

FÖRE snabbkorrigering

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

EFTER snabbkorrigering

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

För alla klienter som påverkas måste vi tvinga fram en CBT L0-säkerhetskopiering (Change Block Tracking). Detta säkerställer att rätt LVM-metadata samlas in i nya säkerhetskopior.

För att göra det lättare att identifiera klienter har Avamar-teknikerna utvecklat ett nytt skript. Det här skriptet söker igenom Linux-säkerhetskopior efter LVM-inkonsekvenser och återställer automatiskt cbt för nästa jobb om några hittas.

vmlvmcheck.pl

1. Skriptet måste installeras på Avamar-servern.
2. Skriptet måste köras som rotanvändare.
3. Det här skriptet söker igenom den senaste säkerhetskopian av alla klienter för virtuella Linux-datorer och kontrollerar LVM-konsekvens.
4. Det här skriptet kan kräva lång varaktighet (timmar) om du genomsöker många virtuella datorer. Om antalet genomsökta virtuella datorer överskrider 50 körs skriptet som standard i bakgrunds-/daemonläge.

Skriptlogik:
Skriptet hittar logiska LVM-volymer i .vmdk-säkerhetskopior och verifierar följande villkor:

1. Säkerställer att alla fysiska volymer finns i säkerhetskopian
2. Verifierar att alla fysiska volymer är associerade med en LVM-volymgrupp
3. Alla fysiska volymer för samma volymgrupp har identiska sekvensnummer.

Falska positiva resultat:

1. Om några av de virtuella diskarna för en identifierad volymgrupp INTE inkluderades säkerhetskopierades den här verktygsflaggans säkerhetskopiering. Rotorsaken är inte relaterad till problemet med frekvent tillägg som beskrivs ovan. I det här fallet kontrollerar du att Avamar säkerhetskopierar alla virtuella diskar.
2. Om någon av de virtuella diskarna innehåller en LVM-partition som INTE är helt initierad identifierar verktyget säkerhetskopieringen som dålig. Men i det här scenariot skulle operativsystemet INTE ha några startproblem.

Instruktioner för nerladdning:

1. Ladda ner vmlvmcheck.pl från central.dell.com webbplats. Mer information om central finns i KB Avamar: Hitta och ladda ner Avamar-skript och -verktyg från Dell Central Avamar-sidan.
   

2. Överför vmlvmchck.pl till katalogen "/root" på Avamar-servern med ett verktyg som WinSCP.

   Exempel 1 (skrivskyddad funktion) Genomsöker den senaste säkerhetskopian av alla virtuella Linux-klienter.

   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 %
   
   

   ELLER När det totala antalet genomsökta virtuella datorer överskrider 50 körs skriptet automatiskt i bakgrunden i stället:

   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

   Exempel 2 (skrivskyddad funktion) Genomsök den senaste säkerhetskopian av en enskild klient med --vm <vm name> Flagga

   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

   Exempel 3 (skrivbar funktion) Samma som exempel 1 och 2, men den här gången --DELETE_SNAPSHOTS Alternativet läggs till

   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

Manuell LVM-inställning för äldre eller opatchade Avamar-proxyservrar

1. Som proxyrot ska du säkerhetskopiera filen lvm.conf

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

2. Redigera /etc/lvm/lvm.conf, leta efter den befintliga "filter"-raden och ändra till följande.

   INNAN

       filter = [ "a/.*/" ]

   EFTER

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

3. Kontrollera att den nya filterinställningen har angetts genom att köra det här kommandot

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