Avamar: VM-sikkerhetskopier av Linux kan ha inkonsekvens i LVM-metadata hvis de distribueres fra en mal

Under gjenopprettingen oppstår følgende symptomer:

1. Feil ved FLR-drift med LVM-problem:
   

   ELLER
   
   2 VM

2. Imagegjenopprettede jobber lykkes i Avamar UI, den virtuelle maskinen (VM) kan ha oppstartsutstedelse på grunn av et LVM-problem.

   Eksempel på oppstartsproblem 1:
   I dette Red Hat-eksemplet nedenfor starter operativsystemet opp i et dracut-nødskall:
   

   (I dette eksemplet) fra dracut shell reparerer følgende LVM-kommando LVM-tilstand. Resultatet viser at problemet var at en av lvm-diskene (sdb) ble feilaktig fjernet fra LVM.

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

   
   Nå kan den gjenopprettede virtuelle maskinen starte opp.

   Eksempel på oppstartsproblem 2:
   I Debian-eksempelet starter operativsystemet opp i et nødskall:
   

   (I dette eksemplet) fra opptatt boksskall følgende: lvm Kommandogjenopprett LVM-volumgruppetilstand fra forrige konfigurasjon:

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

    

   Merk: vm1-vg er volumgruppenavnet i dette eksemplet

    

   
   Nå kan den gjenopprettede virtuelle maskinen starte opp.

Andre symptomer:

Virtuelle maskiner for produksjon (VM-er) kan starte på nytt. Problemet påvirker bare sikkerhetskopier av virtuelle Linux-maskiner som bruker LVM og ble distribuert fra samme mal.
Virtuelle Windows- og Linux-maskiner som IKKE bruker LVM-konfigurasjoner, viser IKKE FLR- eller oppstartsproblemer med sikkerhetskopiene.

Bakgrunn for LVM-metadata:

1. Virtuelle Linux-maskiner konfigurert med LVM klones eller distribueres fra samme mal. De resulterende nye virtuelle maskinene har identiske LVM Unique Identifiers (UUIDs).
2. Eventuelle endringer som gjøres på LVM-disker (for eksempel å legge til en virtuell disk i LVM) nødvendiggjør en oppdatering av LVM-metadatainformasjonen. LVM sporer disse oppdateringene ved hjelp av et felt kalt revisjonssekvensnumre (vg_seqno). Dette tallet økes hver gang en endring gjøres.

Hot legge til backup problem:
Hvis følgende betingelser er oppfylt under Avamar-sikkerhetskopieringen:

1. Både kilden og de klonede virtuelle maskinene sikkerhetskopieres samtidig ved hjelp av hot add (standard transportmetode).
2. Begge virtuelle maskinene legges til under drift ved hjelp av samme Avamar-proxy.
3. LVM-revisjonene varierer mellom de virtuelle maskinene som er hot-lagt til.

Avamar-proxyens Linux-kjerne antar feilaktig at de to VM-diskene er i samme LVM-volumgruppe, og oppdaterer LVM-metadataene automatisk. Hvis denne LVM-oppdateringen oppstår, er LVM-metadataene inkonsekvente i sikkerhetskopien.

Gjenopprettingsproblem:
Under imaget kan VM-en vise «Manglende fysiske LVM-utstrekninger» eller «Transaksjons-ID-avvik» på grunn av feil LVM-metadata oppdatert under hotadd-sikkerhetskopien. Denne uoverensstemmelsen oppstår fra den nevnte oppdateringen.

Verktøy for gjenoppretting av LVM, slik som vgcfgrestore, vgextend –restoremissingog vgchange -ay –activationmodepartial kan være nødvendig for å tillate fullstendig oppstart eller for å reparere sikkerhetskopien for å korrigere LVM-tilstanden.

Dette problemet er løst i Avamar-proxy-hurtigreparasjoner:
Avamar 19.4 333146.
Avamar 19,3 333148.
Avamar 19,2 333149.
Eldre Avamar-versjon: Se merknader nedenfor.

Disse hurtigreparasjonene konfigurerer LVM-innstillingen på nytt i Avamar-proxy for å forhindre LVM-metadataoppdateringer under hotadd-operasjoner.

FØR hurtigreparasjon

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

ETTER hurtigreparasjon

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

For alle klienter som er berørt, må vi tvinge en Change Block Tracking (CBT) L0-sikkerhetskopi. Dette sikrer at riktige LVM-metadata fanges opp i nye sikkerhetskopier.

For å gjøre det enklere å oppdage klienter utviklet Avamar-teknikerne et nytt skript. Dette skriptet skanner Linux-sikkerhetskopier for LVM-inkonsekvenser og tilbakestiller automatisk cbt for neste jobb hvis noen blir funnet.

vmlvmcheck.pl

1. Dette skriptet må være installert på Avamar-serveren.
2. Skriptet må kjøres som rotbruker.
3. Dette skriptet skanner den siste sikkerhetskopien av alle Linux Virtual maskinklienter og kontrollerer LVM-konsistens.
4. Dette skriptet kan kreve lang varighet (timer) hvis du skanner mange virtuelle maskiner. Hvis antallet skannede virtuelle maskiner overskrider 50, kjører skriptet som standard i bakgrunns-/demonmodus.

Script Logic:
Skriptet finner logiske LVM-volumer i .vmdk-sikkerhetskopier og bekrefter følgende betingelser:

1. Sørger for at alle fysiske volumer er til stede i sikkerhetskopieringen
2. Validerer at alle fysiske volumer er knyttet til en LVM-volumgruppe
3. Alle fysiske volumer for samme volumgruppe har identiske sekvensnumre.

Falske positiver:

1. Hvis noen av de virtuelle diskene for en oppdaget volumgruppe IKKE var inkludert, sikkerhetskopieres denne sikkerhetskopien for verktøyflagget. Grunnårsaken er ikke relatert til hot add-problemet beskrevet ovenfor. I dette tilfellet må du sørge for at Avamar sikkerhetskopierer alle virtuelle disker.
2. Hvis noen av de virtuelle diskene inneholder en LVM-partisjon som IKKE er fullstendig initialisert, identifiserer verktøyet sikkerhetskopiering som skadet. Men i dette scenariet operativsystemet ville IKKE ha noen oppstartsproblem.

Last ned instruksjoner:

1. Last ned vmlvmcheck.pl fra central.dell.com-nettstedet . Hvis du vil ha mer informasjon om sentralt, kan du se KB Avamar: Finne og laste ned Avamar-skript og -verktøy fra Dell Central Avamar-siden.
   

2. Overfør vmlvmchck.pl til /root-katalogen på Avamar-serveren ved hjelp av et verktøy som WinSCP.

   Eksempel 1 (skrivebeskyttet funksjon) Skanner den nyeste sikkerhetskopien av 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 totale antallet skannede virtuelle maskiner overskrider 50, kjøres skriptet automatisk i bakgrunnen 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 funksjon) Skann den siste sikkerhetskopien av en enkelt klient ved hjelp av --vm <vm name> Flagg

   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 funksjon) Samme som eksempler 1 og 2, men denne gangen --DELETE_SNAPSHOTS Alternativet er lagt til

   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-innstilling for eldre eller ikke-oppdaterte Avamar-proxyer

1. Som proxy root backup lvm.conf filen

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

2. Rediger /etc/lvm/lvm.conf, se etter den eksisterende "filter"-linjen og bytt til følgende.

   FØR

       filter = [ "a/.*/" ]

   ETTER

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

3. Kontroller at den nye filterinnstillingen er angitt ved å kjøre denne kommandoen

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