Avamar: Linux VM-sikkerhedskopier kan have inkonsekvens i LVM-metadata, hvis de implementeres fra en skabelon

Under gendannelse ses følgende symptomer:

1. FLR-driftsfejl med LVM-problem:
   

   ELLER
   
   2 VM ER

2. Job med gendannelse af afbildning fuldføres i Avamar UI, og der kan være opstartsproblemer med den virtuelle maskine (VM) på grund af et LVM-problem.

   Eksempel på opstartsproblem 1:
   I dette Red Hat-eksempel nedenfor starter operativsystemet op i en nød-dracut-skal:
   

   (I dette eksempel) fra dracut shell reparerer følgende LVM-kommando LVM-tilstand. Outputtet viser, at problemet var, at en af lvm-diskene (sdb) fejlagtigt blev fjernet fra LVM.

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

   
   Nu kan den gendannede virtuelle maskine starte.

   Eksempel på opstartsproblem 2:
   I Debian-eksemplet starter styresystemet op i en nødkasse med optaget:
   

   (I dette eksempel) fra optaget boksskal følgende lvm command restore LVM volume group state from previous configuration:

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

    

   Bemærk: vm1-vg er navnet på diskenhedsgruppen i dette eksempel

    

   
   Nu kan den gendannede virtuelle maskine starte.

Andre symptomer:

Produktionen Virtual Machines (VM'er) kan genstarte. Problemet påvirker kun sikkerhedskopier af Linux VM'er, der bruger LVM og blev implementeret fra den samme skabelon.
Virtuelle Windows- og Linux-maskiner, der IKKE bruger LVM-konfigurationer, udviser IKKE FLR- eller opstartsproblemer med sikkerhedskopierne.

LVM-metadatabaggrund:

1. Linux VM'er, der er konfigureret med LVM, klones eller udrulles fra den samme skabelon. De resulterende nye virtuelle maskiner har identiske LVM unikke identifikatorer (UUID'er).
2. Eventuelle ændringer foretaget på LVM-diske (for eksempel tilføjelse af en virtuel disk til LVM) kræver en opdatering af LVM-metadataoplysningerne. LVM sporer disse opdateringer ved hjælp af et felt kaldet revisionssekvensnumre (vg_seqno). Dette antal øges, hver gang der foretages en ændring.

Hot add Backup Problem:
Hvis følgende betingelser er opfyldt under Avamar-sikkerhedskopiering:

1. Både kilden og de klonede VM er sikkerhedskopieres samtidigt ved hjælp af varm tilføjelse (standardtransportmetoden).
2. Begge VM er tilføjes varmt ved hjælp af den samme Avamar-proxy.
3. LVM-revisionerne varierer mellem de VM'er, der varmt tilføjes.

Avamar-proxyens Linux-kerne antager fejlagtigt, at de to VM'ers diske er i den samme LVM-diskenhedsgruppe, og opdaterer automatisk LVM-metadataene. Hvis denne LVM-opdatering finder sted, er LVM-metadataene inkonsistente i sikkerhedskopien.

Gendan problem:
Under afbildningen kan VM'en vise "Manglende fysiske LVM-udstrækninger" eller "Uoverensstemmelser mellem transaktions-id'er" på grund af forkerte LVM-metadata, der er opdateret under hot add-sikkerhedskopieringen. Denne uoverensstemmelse stammer fra ovennævnte opdatering.

Recovery LVM-værktøjer som f.eks vgcfgrestore, vgextend –restoremissingog vgchange -ay –activationmodepartial kan være påkrævet for at tillade komplet opstart eller for at reparere sikkerhedskopien for at rette LVM-tilstanden.

Dette problem er løst i Avamar proxy-hotfixes:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Ældre Avamar-version: Se bemærkningerne nedenfor.

Disse hotfixes omkonfigurerer LVM-indstillingen på Avamar Proxy for at forhindre opdateringer af LVM-metadata under handlinger, der bruges til at tilføje varmt til.

FØR hotfix

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

EFTER hotfix

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

For enhver af de klienter, der er berørt, skal vi tvinge en Change Block Tracking (CBT) L0-sikkerhedskopi. Dette sikrer, at de korrekte LVM-metadata registreres i nye sikkerhedskopier.

For at hjælpe med klientregistrering udviklede Avamar Engineering et nyt script. Dette script scanner Linux-sikkerhedskopier for LVM-uoverensstemmelser og nulstiller automatisk cbt til det næste job, hvis der findes nogen.

vmlvmcheck.pl

1. Dette script skal være installeret på Avamar-serveren.
2. Scriptet skal køres som rodbruger.
3. Dette script scanner den seneste sikkerhedskopi af alle klienter til virtuelle Linux-maskiner og kontrollerer LVM-konsistens.
4. Dette script kan kræve lang varighed (timer), hvis du scanner mange virtuelle maskiner. Hvis antallet af scannede VM'er overstiger 50, kører scriptet som standard i baggrunds-/dæmontilstand.

Scriptlogik:
Scriptet lokaliserer logiske LVM-diskenheder i .vmdk-sikkerhedskopier og verificerer følgende betingelser:

1. Sikrer, at alle fysiske diskenheder er til stede i sikkerhedskopien
2. Validerer, at alle fysiske diskenheder er tilknyttet en LVM-diskenhedsgruppe
3. Alle fysiske diskenheder for samme diskenhedsgruppe har identiske sekvensnumre.

Falske positiver:

1. Hvis nogle af de virtuelle diske for en opdaget diskenhedsgruppe IKKE var inkluderet, sikkerhedskopieres dette værktøj, markeres sikkerhedskopiering. Den grundlæggende årsag er ikke relateret til problemet med hot-tilføjelser, der er beskrevet ovenfor. I dette tilfælde skal du sørge for, at Avamar sikkerhedskopierer alle virtuelle diske.
2. Hvis nogen af de virtuelle diske indeholder en LVM-partition, der IKKE er fuldt initialiseret, identificerer værktøjet backup som dårlig. I dette scenarie vil operativsystemet dog IKKE have noget opstartsproblem.

Download instruktioner:

1. Download vmlvmcheck.pl fra central.dell.com websted. For mere information om central se KB Avamar: Sådan finder og downloader du Avamar-scripts og -værktøjer fra Dell Central Avamar-siden.
   

2. Overfør vmlvmchck.pl til mappen '/root' på Avamar-serveren ved hjælp af et værktøj som WinSCP.

   Eksempel 1 (skrivebeskyttet funktion) Scanner den seneste sikkerhedskopi af alle Linux VM-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 samlede antal scannede vm overstiger 50, kører scriptet automatisk i baggrunden i stedet:

   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

   Eksempel 2 (skrivebeskyttet funktion) Scan den seneste sikkerhedskopi af en enkelt klient ved hjælp af --vm <vm name> Flag

   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

   Eksempel 3 (skrivbar funktion) Samme som eksempel 1 og 2, men denne gang --DELETE_SNAPSHOTS Mulighed er tilføjet

   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

Manuel LVM-indstilling for ældre eller ikke-patchede Avamar-proxyer

1. Som proxyrod skal du sikkerhedskopiere lvm.conf-filen

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

2. Rediger /etc/lvm/lvm.conf, se efter den eksisterende "filter"-linje og skift til den følgende.

   FØR

       filter = [ "a/.*/" ]

   EFTER

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

3. Kontroller, at den nye filterindstilling er angivet ved at køre denne kommando

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