Avamar: I backup delle VM Linux possono presentare incoerenza dei metadati LVM se vengono implementati da un template

Durante il ripristino si verificano i seguenti sintomi:

1. Errore di funzionamento FLR con problema LVM:
   

   OPPURE
   
   2 VM

2. I processi di ripristino dell'immagine hanno esito positivo nell'interfaccia utente Avamar, la macchina virtuale (VM) potrebbe presentare problemi di avvio a causa di un problema LVM.

   Esempio di problema di avvio 1:
   In questo esempio di Red Hat riportato di seguito, il sistema operativo si avvia in una shell dracut di emergenza:
   

   (In questo esempio) dalla shell dracut, il seguente comando LVM ripristina lo stato LVM. L'output mostra che il problema è che uno dei dischi LVM (sdb) è stato rimosso erroneamente da LVM.

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

   
   A questo punto, la macchina virtuale ripristinata può avviarsi.

   Esempio di problema di avvio 2:
   Nell'esempio Debian il sistema operativo si avvia in una shell di emergenza occupata:
   

   (In questo esempio) dalla shell della casella occupato quanto segue lvm comando restore Stato del gruppo di volumi LVM dalla configurazione precedente:

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

    

   Nota: vm1-vg è il nome del gruppo di volumi in questo esempio

    

   
   A questo punto, la macchina virtuale ripristinata può avviarsi.

Altri sintomi:

Le macchine virtuali (VM) di produzione possono riavviarsi correttamente. Il problema riguarda solo le copie di backup delle VM Linux che utilizzano LVM e sono state implementate dallo stesso modello.
Le macchine virtuali Windows e Linux che NON utilizzano configurazioni LVM NON presentano problemi FLR o di avvio con le copie di backup.

Sfondo metadati LVM:

1. Le VM Linux configurate con LVM vengono clonate o implementate dallo stesso modello. Le nuove macchine virtuali risultanti hanno identificatori univoci LVM (UUID) identici.
2. Qualsiasi modifica apportata ai dischi LVM (ad esempio, l'aggiunta di un disco virtuale a LVM) richiede un aggiornamento delle informazioni sui metadati LVM. LVM tiene traccia di questi aggiornamenti utilizzando un campo denominato numeri di sequenza delle revisioni (vg_seqno). Questo numero viene incrementato ogni volta che viene apportata una modifica.

Aggiunta a caldo Problema di backup:
Durante il backup Avamar, se vengono soddisfatte le seguenti condizioni:

1. Il backup delle VM di origine e delle VM clonate viene eseguito contemporaneamente utilizzando la funzione Hot Add (il metodo di trasporto predefinito).
2. Entrambe le VM vengono aggiunte a caldo utilizzando lo stesso proxy Avamar.
3. Le revisioni LVM differiscono a seconda delle macchine virtuali aggiunte a caldo.

Il kernel Linux del proxy Avamar presuppone erroneamente che i dischi delle due VM si trovino nello stesso gruppo di volumi LVM, aggiornando automaticamente i metadati LVM. Se si verifica questo aggiornamento LVM, i metadati LVM non sono coerenti nella copia di backup.

Problema di ripristino:
Durante l'immagine, la VM potrebbe visualizzare "Missing LVM physical extents" o "Transaction ID mismatchs" a causa di metadati LVM errati aggiornati durante il backup hot-add. Questa discrepanza deriva dall'aggiornamento di cui sopra.

Strumenti LVM di ripristino, come vgcfgrestore, vgextend –restoremissinge vgchange -ay –activationmodepartial potrebbe essere necessario per consentire l'avvio completo o per riparare la copia di backup per correggere lo stato LVM.

Questo problema è stato risolto negli hotfix per proxy Avamar:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Versione precedente di Avamar: Vedere le note riportate di seguito.

Questi hotfix riconfigurano l'impostazione LVM sul proxy Avamar per impedire gli aggiornamenti dei metadati LVM durante le operazioni di aggiunta a caldo.

PRIMA dell'hotfix

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

DOPO l'hotfix

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

Per uno qualsiasi dei client interessati, è necessario forzare un backup CBT (Change Block Tracking) L0. Ciò garantisce che i metadati LVM corretti vengano acquisiti nei nuovi backup.

Per facilitare il rilevamento dei client, Avamar Engineering ha sviluppato un nuovo script. Questo script esegue la scansione dei backup Linux alla ricerca di incoerenze LVM e reimposta automaticamente il cbt per il processo successivo, se presente.

vmlvmcheck.pl

1. Questo script deve essere installato sull'Avamar Server.
2. Lo script deve essere eseguito come utente root.
3. Questo script esegue la scansione del backup più recente di tutti i client delle macchine virtuali Linux e verifica la coerenza LVM.
4. Questo script può richiedere del tempo (ore) se si esegue la scansione di molte VM. Per impostazione predefinita, se il numero di macchine virtuali analizzate supera 50, lo script viene eseguito in modalità background/daemon.

Logica di script:
Lo script individua i volumi logici LVM nei backup .vmdk e verifica le seguenti condizioni:

1. Garantisce che tutti i volumi fisici siano presenti nel backup
2. Verifica che tutti i volumi fisici siano associati a un gruppo di volumi LVM
3. Tutti i volumi fisici per lo stesso gruppo di volumi hanno numeri di sequenza identici.

Falsi positivi:

1. Se alcuni dei dischi virtuali per un gruppo di volumi individuato NON sono stati inclusi, eseguire il backup del flag di questo strumento. La root cause non è correlata al problema di aggiunta a caldo descritto in precedenza. In questo caso, assicurarsi che Avamar esegua il backup di tutti i dischi virtuali.
2. Se uno qualsiasi dei dischi virtuali contiene una partizione LVM NON completamente inizializzata, lo strumento identifica il backup come non valido. Tuttavia, in questo scenario, il sistema operativo NON avrebbe alcun problema di avvio.

Istruzioni di download:

1. Scaricare vmlvmcheck.pl dal sito web di central.dell.com . Per ulteriori informazioni su Central, consultare KB Avamar: Come trovare e scaricare gli script e gli strumenti Avamar dalla pagina Dell Central Avamar.
   

2. Trasferire i vmlvmchck.pl nella directory "/root" sull'Avamar Server utilizzando uno strumento come WinSCP.

   Esempio 1 (funzione read-only) Esegue la scansione del backup più recente di tutti i client di macchine virtuali 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 %
   
   

   OPPURE : Quando il numero totale di macchine virtuali analizzate supera 50, lo script viene eseguito automaticamente in background:

   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

   Esempio 2 (funzione read-only) Eseguire la scansione del backup più recente di un singolo client utilizzando --vm <vm name> arancione o blu

   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

   Esempio 3 (funzione scrivibile) Come per gli esempi 1 e 2, ma questa volta --DELETE_SNAPSHOTS l'opzione viene aggiunta

   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

Impostazione manuale di LVM per proxy Avamar meno recenti o privi di patch

1. Come root backup del proxy, il file lvm.conf

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

2. Modificare il file /etc/lvm/lvm.conf, cercare la riga "filter" esistente e passare alla seguente.

   PRIMA

       filter = [ "a/.*/" ]

   DOPO

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

3. Verificare che la nuova impostazione di filtro sia impostata eseguendo questo comando:

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