Avamar: Linux-VM-Backups weisen möglicherweise LVM-Metadateninkonsistenzen auf, wenn sie aus einer Vorlage bereitgestellt werden

Während der Wiederherstellung treten die folgenden Symptome auf:

1. FLR-Vorgangsfehler mit LVM-Problem:
   

   ODER
   
   2 VMs

2. Jobs zur Image-Wiederherstellung sind in der Avamar-Benutzeroberfläche erfolgreich. Die virtuelle Maschine (VM) hat möglicherweise aufgrund eines LVM-Problems ein Startproblem.

   Beispiel für Startproblem 1:
   Im folgenden Red Hat-Beispiel startet das Betriebssystem in eine Notfall-dracut-Shell:
   

   (In diesem Beispiel) wird über die dracut-Shell der LVM-Status mit dem folgenden LVM-Befehl repariert. Die Ausgabe zeigt, dass das Problem darin bestand, dass eine der LVM-Festplatten (sdb) fälschlicherweise aus LVM entfernt wurde.

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

   
   Jetzt kann die wiederhergestellte virtuelle Maschine gestartet werden.

   Beispiel für Startproblem 2:
   Im Debian-Beispiel bootet das Betriebssystem in eine Notfall-Busy-Box-Shell:
   

   (In diesem Beispiel) aus der Shell des ausgelasteten Kastens wird Folgendes angezeigt lvm Befehlswiederherstellung des LVM-Volume-Gruppenstatus aus der vorherigen Konfiguration:

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

    

   Hinweis: vm1-vg ist der Name der Volume-Gruppe in diesem Beispiel

    

   
   Jetzt kann die wiederhergestellte virtuelle Maschine gestartet werden.

Weitere Symptome:

Die Produktions-VMs (virtuelle Maschinen) können erfolgreich neu gestartet werden. Das Problem betrifft nur Sicherungskopien von Linux-VMs, die LVM verwenden und mit derselben Vorlage bereitgestellt wurden.
Virtuelle Windows- und Linux-Maschinen, die KEINE LVM-Konfigurationen verwenden, zeigen KEINE FLR- oder Startprobleme mit den Sicherungskopien.

LVM-Metadatenhintergrund:

1. Linux-VMs, die mit LVM konfiguriert sind, werden von derselben Vorlage geklont oder bereitgestellt. Die daraus resultierenden neuen virtuellen Maschinen verfügen über identische eindeutige LVM-Kennungen (UUIDs).
2. Alle Änderungen an LVM-Festplatten (z. B. das Hinzufügen eines virtuellen Laufwerks zu LVM) erfordern eine Aktualisierung der LVM-Metadateninformationen. LVM verfolgt diese Aktualisierungen mithilfe eines Felds namens Revision Sequence Numbers (vg_seqno). Diese Zahl wird erhöht, wenn eine Änderung vorgenommen wird.

Problem mit Hot-Add-Backups:
Wenn während des Avamar Backups die folgenden Bedingungen erfüllt sind:

1. Sowohl die Quell-VMs als auch die geklonten VMs werden gleichzeitig mithilfe von Hot Add (Standardtransportmethode) gesichert.
2. Beide VMs werden mit demselben Avamar-Proxy als Ersatz hinzugefügt.
3. Die LVM-Versionen unterscheiden sich zwischen den VMs, die während des Betriebs hinzugefügt werden.

Der Linux-Kernel des Avamar-Proxys geht fälschlicherweise davon aus, dass sich die Festplatten der beiden VMs in derselben LVM-Volume-Gruppe befinden, und aktualisiert die LVM-Metadaten automatisch. Wenn diese LVM-Aktualisierung durchgeführt wird, sind die LVM-Metadaten in der Sicherungskopie inkonsistent.

Problem bei der Wiederherstellung:
Während des Image zeigt die VM möglicherweise "Fehlende physische LVM-Extents" oder "Transaktions-ID-Nichtübereinstimmungen" aufgrund falscher LVM-Metadaten an, die während des Hot-Add-Backups aktualisiert wurden. Diese Diskrepanz ergibt sich aus dem oben genannten Update.

Recovery-LVM-Tools wie z. B. vgcfgrestore, vgextend –restoremissingund vgchange -ay –activationmodepartial kann erforderlich sein, um einen vollständigen Start zu ermöglichen oder um die Sicherungskopie zu reparieren, um den LVM-Status zu korrigieren.

Dieses Problem wurde in Avamar proxy hotfixes:
Avamar 19.4 333146 behoben.
Avamar 19.3 333148.
Avamar 19.2 333149.
Ältere Avamar-Version: Siehe Hinweise unten.

Mit diesen Hotfixes wird die LVM-Einstellung auf dem Avamar-Proxy neu konfiguriert, um LVM-Metadatenaktualisierungen während Hot-Add-Vorgängen zu verhindern.

VOR Hotfix

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

NACH Hotfix

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

Für jeden der betroffenen Clients müssen wir ein Change Block Tracking (CBT)-L0-Backup erzwingen. Dadurch wird sichergestellt, dass die richtigen LVM-Metadaten in neuen Backups erfasst werden.

Um die Clienterkennung zu unterstützen, hat Avamar Engineering ein neues Skript entwickelt. Dieses Skript scannt Linux-Backups auf LVM-Inkonsistenzen und setzt CBT automatisch für den nächsten Job zurück, falls welche gefunden werden.

vmlvmcheck.pl

1. Dieses Skript muss auf dem Avamar-Server installiert sein.
2. Das Skript muss als Root-Nutzer ausgeführt werden.
3. Dieses Skript scannt das neueste Backup aller Clients der virtuellen Linux-Maschine und überprüft die LVM-Konsistenz.
4. Dieses Skript kann eine lange Dauer (Stunden) erfordern, wenn viele virtuelle Maschinen gescannt werden. Wenn die Anzahl der gescannten VMs 50 überschreitet, wird das Skript standardmäßig im Hintergrund-/Daemon-Modus ausgeführt.

Skriptlogik:
Das Skript sucht nach logischen LVM-Volumes in .vmdk-Backups und überprüft die folgenden Bedingungen:

1. Stellt sicher, dass alle physischen Volumes im Backup vorhanden sind
2. Überprüfung, ob alle physischen Volumes einer LVM-Volume-Gruppe zugeordnet sind
3. Alle physischen Volumes derselben Volume-Gruppe haben identische Sequenznummern.

Falsch positive Ergebnisse:

1. Wenn einige der virtuellen Laufwerke für eine erkannte Volume-Gruppe NICHT enthalten waren, wird ein Backup mit diesem Tool-Flag backup ausgeführt. Die Ursache hängt nicht mit dem oben beschriebenen Hot-Add-Problem zusammen. Stellen Sie in diesem Fall sicher, dass Avamar alle virtuellen Laufwerke sichert.
2. Wenn eines der virtuellen Laufwerke eine LVM-Partition enthält, die NICHT vollständig initialisiert ist, identifiziert das Tool das Backup als fehlerhaft. In diesem Szenario hätte das Betriebssystem jedoch KEINE Startprobleme.

Anleitung zum Herunterladen:

1. Laden Sie vmlvmcheck.pl von der central.dell.com Website herunter. Weitere Informationen zu Central finden Sie unter KB Avamar: Anleitung zum Suchen und Herunterladen von Avamar-Skripten und -Tools über die Seite Dell Central Avamar.
   

2. Übertragen Sie vmlvmchck.pl mithilfe eines Tools wie WinSCP in das Verzeichnis "/root" auf dem Avamar -Server.

   Beispiel 1 (schreibgeschützte Funktion) Scannt das neueste Backup aller Linux-VM-Clients.

   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 %
   
   

   ODER Wenn die Gesamtzahl der gescannten VMs 50 überschreitet, wird das Skript stattdessen automatisch im Hintergrund ausgeführt:

   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

   Beispiel 2 (schreibgeschützte Funktion) Scannen Sie das letzte Backup eines einzelnen Clients mithilfe von --vm <vm name> Markierung

   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

   Beispiel 3 (beschreibbare Funktion) Wie in den Beispielen 1 und 2, aber dieses Mal --DELETE_SNAPSHOTS Option wurde hinzugefügt

   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

Manuelle LVM-Einstellung für ältere oder nicht gepatchte Avamar-Proxys

1. Sichern Sie als Proxy-Root-Backup die Datei lvm.conf

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

2. Bearbeiten Sie die Datei /etc/lvm/lvm.conf, suchen Sie nach der vorhandenen Zeile "filter" und ändern Sie die folgende Zeile.

   VORHER:

       filter = [ "a/.*/" ]

   NACHHER

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

3. Überprüfen Sie, ob die neue Filtereinstellung festgelegt ist, indem Sie diesen Befehl ausführen

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