Avamar : Les sauvegardes de machines virtuelles Linux peuvent présenter une incohérence des métadonnées LVM si elles sont déployées à partir d’un modèle

Lors de la restauration, les symptômes suivants sont observés :

1. Échec de l’opération FLR avec problème LVM :
   

   OU
   
   2 VM

2. Les tâches de restauration d’image réussissent dans l’interface utilisateur d’Avamar. La machine virtuelle (VM) peut avoir un démarrage en raison d’un problème de LVM.

   Exemple de problème de démarrage 1 :
   Dans l’exemple Red Hat ci-dessous, le système d’exploitation démarre dans un shell de dracut d’urgence :
   

   (Dans cet exemple) à partir du shell dracut, la commande LVM suivante répare l’état de LVM. La sortie montre que le problème était que l’un des disques LVM (sdb) a été supprimé de manière incorrecte de LVM.

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

   
   La machine virtuelle restaurée peut maintenant démarrer.

   Exemple de problème de démarrage 2 :
   Dans l’exemple Debian, le système d’exploitation démarre dans un shell de boîte d’occupation d’urgence :
   

   (Dans cet exemple) à partir du shell busy box shell, les éléments suivants lvm Command restore LVM volume group state from previous configuration :

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

    

   Remarque : vm1-vg est le nom du groupe de volumes dans cet exemple

    

   
   La machine virtuelle restaurée peut maintenant démarrer.

Autres symptômes :

Les machines virtuelles (VM) de production peuvent redémarrer avec succès. Le problème affecte uniquement les copies de sauvegarde des machines virtuelles Linux qui utilisent LVM et ont été déployées à partir du même modèle.
Les machines virtuelles Windows et Linux qui n’utilisent PAS les configurations LVM ne présentent PAS de problèmes de FLR ou de démarrage avec les copies de sauvegarde.

Contexte des métadonnées LVM :

1. Les machines virtuelles Linux configurées avec LVM sont clonées ou déployées à partir du même modèle. Les nouvelles machines virtuelles qui en résultent ont des identifiants uniques LVM (UUID) identiques.
2. Toute modification apportée aux disques LVM (par exemple, l’ajout d’un disque virtuel à LVM) nécessite une mise à jour des informations de métadonnées LVM. LVM assure le suivi de ces mises à jour à l’aide d’un champ appelé numéros de séquence de révision (vg_seqno). Ce nombre est incrémenté chaque fois qu’une modification est apportée.

Problème de sauvegarde d’ajout à chaud :
Lors d’une sauvegarde Avamar, si les conditions suivantes sont remplies :

1. Les machines virtuelles source et clonées sont sauvegardées simultanément à l’aide de l’ajout à chaud (méthode de transport par défaut).
2. Les deux machines virtuelles sont ajoutées à chaud à l’aide du même proxy Avamar.
3. Les révisions LVM diffèrent selon les machines virtuelles ajoutées à chaud.

Le noyau Linux du proxy Avamar suppose à tort que les deux disques des machines virtuelles se trouvent dans le même groupe de volumes LVM et met automatiquement à jour les métadonnées LVM. Si cette mise à jour du LVM se produit, les métadonnées du LVM sont incohérentes dans la copie de sauvegarde.

Problème de restauration :
Au cours de la création de l’image, la machine virtuelle peut afficher « Missing LVM physical extents » ou « Transaction ID mismatches » en raison de métadonnées LVM incorrectes mises à jour pendant la sauvegarde de l’ajout à chaud. Cette divergence découle de la mise à jour susmentionnée.

Les outils de restauration LVM tels que vgcfgrestore, vgextend –restoremissinget vgchange -ay –activationmodepartial peut être nécessaire pour permettre un démarrage complet ou pour réparer la copie de sauvegarde afin de corriger l’état du LVM.

Ce problème est résolu dans les correctifs proxy Avamar :
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Ancienne version d’Avamar : Voir les remarques ci-dessous.

Ces correctifs reconfigurent le paramètre LVM sur le proxy Avamar pour empêcher les mises à jour des métadonnées de LVM lors des opérations d’ajout à chaud.

AVANT le correctif

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

APRÈS le correctif

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

Pour tous les clients concernés, nous devons forcer une sauvegarde CBT (Change Block Tracking) L0. Cela garantit que les métadonnées LVM correctes sont capturées dans les nouvelles sauvegardes.

Pour faciliter la détection des clients, les ingénieurs Avamar ont développé un nouveau script. Ce script analyse les sauvegardes Linux à la recherche d’incohérences LVM et réinitialise automatiquement CBT pour la tâche suivante, le cas échéant.

vmlvmcheck.pl

1. Ce script doit être installé sur l’instance d’Avamar Server.
2. Le script doit être exécuté en tant qu’utilisateur root.
3. Ce script analyse la dernière sauvegarde de tous les clients de machine virtuelle Linux et vérifie la cohérence LVM.
4. Ce script peut être très long (plusieurs heures) si vous analysez de nombreuses machines virtuelles. Par défaut, si le nombre de machines virtuelles analysées dépasse 50, le script s’exécute en arrière-plan/processus.

Logique de script :
Le script localise les volumes logiques LVM dans les sauvegardes .vmdk et vérifie les conditions suivantes :

1. S’assure que tous les volumes physiques sont présents dans la sauvegarde
2. Elle vérifie que tous les volumes physiques sont associés à un groupe de volumes LVM
3. Tous les volumes physiques d’un même groupe de volumes ont des numéros de séquence identiques.

Faux positifs :

1. Si certains des disques virtuels d’un groupe de volumes détecté n’ont PAS été inclus, il sauvegarde cet outil signale la sauvegarde. La cause première n’est pas liée au problème d’ajout à chaud décrit ci-dessus. Dans ce cas, assurez-vous qu’Avamar sauvegarde tous les disques virtuels.
2. Si l’un des disques virtuels contient une partition LVM qui n’est PAS entièrement initialisée, l’outil identifie la sauvegarde comme étant incorrecte. Toutefois, dans ce scénario, le système d’exploitation n’aurait AUCUN problème de démarrage.

Instructions de téléchargement :

1. Téléchargez vmlvmcheck.pl à partir du site Web de central.dell.com . Pour plus d’informations sur la version centrale, consultez l’article de la base de connaissances Avamar : Comment trouver et télécharger les scripts et outils Avamar à partir de la page Dell Central Avamar.
   

2. Transférez vmlvmchck.pl dans le répertoire « /root » d’Avamar Server à l’aide d’un outil tel que WinSCP.

   Exemple 1 (fonction en lecture seule) Analyse la dernière sauvegarde de tous les clients de machines virtuelles 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 %
   
   

   OU lorsque le nombre total de machines virtuelles analysées dépasse 50, le script s’exécute automatiquement en arrière-plan à la place :

   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

   Exemple 2 (fonction en lecture seule) Analyser la dernière sauvegarde d’un seul client à l’aide de --vm <vm name> orange ou bleue

   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

   Exemple 3 (fonction inscriptible) Identique aux exemples 1 et 2, mais cette fois-ci --DELETE_SNAPSHOTS L’option est ajoutée

   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

Paramètre LVM manuel pour les proxys Avamar anciens ou non corrigés

1. En tant que proxy root, sauvegardez le fichier lvm.conf

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

2. Modifiez le fichier /etc/lvm/lvm.conf, recherchez la ligne « filter » existante et remplacez-la par la suivante.

   AVANT

       filter = [ "a/.*/" ]

   APRÈS

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

3. Vérifiez que le nouveau paramètre de filtre est défini en exécutant cette commande

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