Avamar: Kopie zapasowe maszyny wirtualnej z systemem Linux mogą mieć niespójność metadanych LVM, jeśli są wdrażane z szablonu

Podczas przywracania widoczne są następujące objawy:

1. Niepowodzenie operacji FLR z problemem LVM:
   

   LUB 2 VM
   
   

2. Zadania przywracania obrazu powiodły się w interfejsie użytkownika Avamar, maszyna wirtualna (VM) może mieć problem z rozruchem z powodu problemu z LVM.

   Przykładowy problem z rozruchem 1:
   W poniższym przykładzie systemu operacyjnego system operacyjny uruchamia się w awaryjnej powłoce dracut:
   

   (W tym przykładzie) z powłoki dracut następujące polecenie LVM naprawia stan LVM. Dane wyjściowe pokazują, że problem polegał na tym, że jeden z dysków lvm (sdb) został nieprawidłowo usunięty z LVM.

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

   
   Teraz odzyskana maszyna wirtualna może się uruchomić.

   Przykładowy problem z rozruchem 2:
   W przykładzie z Debiana system operacyjny uruchamia się w powłoce awaryjnego zajętości:
   

   (W tym przykładzie) z poziomu zajętej powłoki pudełkowej lvm polecenie przywracania stanu grupy woluminów LVM z poprzedniej konfiguracji:

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

    

   Uwaga: vm1-vg to nazwa grupy woluminów w tym przykładzie

    

   
   Teraz odzyskana maszyna wirtualna może się uruchomić.

Inne objawy:

Produkcyjne maszyny wirtualne (VM) mogą zostać ponownie uruchomione. Problem dotyczy tylko kopii zapasowych maszyn wirtualnych z systemem Linux, które używają LVM i zostały wdrożone z tego samego szablonu.
Maszyny wirtualne z systemami Windows i Linux, które NIE korzystają z konfiguracji LVM, NIE wykazują FLR ani problemów z rozruchem kopii zapasowych.

Tło metadanych LVM:

1. Maszyny wirtualne z systemem Linux skonfigurowane przy użyciu LVM są klonowane lub wdrażane na podstawie tego samego szablonu. Powstałe nowe maszyny wirtualne mają identyczne unikatowe identyfikatory LVM (UUID).
2. Wszelkie zmiany wprowadzone na dyskach LVM (na przykład dodanie dysku wirtualnego do LVM) wymagają aktualizacji informacji o metadanych LVM. LVM śledzi te aktualizacje za pomocą pola o nazwie numery sekwencji wersji (vg_seqno). Ta liczba jest zwiększana za każdym razem, gdy zostanie wprowadzona zmiana.

Problem z kopią zapasową dodawania na gorąco:
Podczas tworzenia kopii zapasowej Avamar, jeśli spełnione są następujące warunki:

1. Kopie zapasowe zarówno źródłowych, jak i sklonowanych maszyn wirtualnych są tworzone jednocześnie przy użyciu dodawania na gorąco (domyślna metoda transportu).
2. Obie maszyny wirtualne są dodawane na gorąco przy użyciu tego samego serwera proxy Avamar.
3. Wersje LVM różnią się w zależności od dodawanej na gorąco maszyny wirtualnej.

Jądro systemu Linux serwera proxy Avamar nieprawidłowo zakłada, że dyski obu maszyn wirtualnych znajdują się w tej samej grupie woluminów LVM, automatycznie aktualizując metadane LVM. Jeśli ta aktualizacja LVM nastąpi, metadane LVM są niespójne w kopii zapasowej.

Problem z przywracaniem:
Podczas tworzenia obrazu maszyna wirtualna może wyświetlać komunikat "Brak fizycznych zakresów LVM" lub "Niezgodność identyfikatora transakcji" z powodu nieprawidłowych metadanych LVM zaktualizowanych podczas dodawania kopii zapasowej na gorąco. Ta rozbieżność wynika z wyżej wymienionej aktualizacji.

Narzędzia LVM odzyskiwania, takie jak vgcfgrestore, vgextend –restoremissingi vgchange -ay –activationmodepartial może być wymagane, aby umożliwić pełne uruchomienie lub naprawić kopię zapasową w celu poprawienia stanu LVM.

Ten problem został rozwiązany w poprawkach proxy Avamar:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Starsza wersja Avamar: Patrz uwagi poniżej.

Te poprawki ponownie konfigurują ustawienie LVM na serwerze proxy Avamar, aby zapobiec aktualizacjom metadanych LVM podczas operacji dodawania na gorąco.

PRZED poprawką

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

PO poprawce

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

Dla każdego klienta, którego dotyczy problem, musimy wymusić kopię zapasową L0 Change Block Tracking (CBT). Gwarantuje to, że prawidłowe metadane LVM zostaną przechwycone w nowych kopiach zapasowych.

Aby ułatwić wykrywanie klientów, inżynierowie firmy Avamar opracowali nowy skrypt. Ten skrypt skanuje kopie zapasowe systemu Linux w poszukiwaniu niespójności LVM i automatycznie resetuje cbt dla następnego zadania, jeśli takie zostanie znalezione.

vmlvmcheck.pl

1. Ten skrypt musi być zainstalowany na serwerze Avamar.
2. Skrypt musi być uruchomiony jako użytkownik root.
3. Ten skrypt skanuje najnowszą kopię zapasową wszystkich klientów maszyn wirtualnych z systemem Linux i sprawdza spójność LVM.
4. Ten skrypt może wymagać długiego czasu (godzin) w przypadku skanowania wielu maszyn wirtualnych. Domyślnie, jeśli liczba przeskanowanych maszyn wirtualnych przekracza 50, skrypt jest uruchamiany w tle/trybie demona.

Logika skryptu:
Skrypt lokalizuje woluminy logiczne LVM w kopiach zapasowych .vmdk i weryfikuje następujące warunki:

1. Sprawdzenie, czy wszystkie woluminy fizyczne są obecne w kopii zapasowej
2. Sprawdza, czy wszystkie woluminy fizyczne są powiązane z grupą woluminów LVM
3. Wszystkie woluminy fizyczne w tej samej grupie woluminów mają identyczne numery sekwencyjne.

Wyniki fałszywie pozytywne:

1. Jeśli niektóre dyski wirtualne dla wykrytej grupy woluminów NIE zostały uwzględnione, należy utworzyć kopię zapasową tej flagi narzędzia. Główna przyczyna nie jest związana z opisanym powyżej problemem z dodawaniem na gorąco. W takim przypadku należy upewnić się, że Avamar tworzy kopię zapasową wszystkich dysków wirtualnych.
2. Jeśli którykolwiek z dysków wirtualnych zawiera partycję LVM, która NIE jest w pełni zainicjowana, narzędzie zidentyfikuje kopię zapasową jako nieprawidłową. Jednak w tym scenariuszu system operacyjny NIE będzie miał żadnego problemu z rozruchem.

Instrukcje pobierania:

1. Pobierz vmlvmcheck.pl z witryny central.dell.com . Aby uzyskać więcej informacji na temat centrali, zobacz artykuł bazy wiedzy Avamar: Wyszukiwanie i pobieranie skryptów i narzędzi Avamar ze strony Dell Central Avamar.
   

2. Przenieś vmlvmchck.pl do katalogu "/root" na serwerze Avamar za pomocą narzędzia takiego jak WinSCP.

   Przykład 1 (funkcja tylko do odczytu) Skanuje najnowszą kopię zapasową wszystkich klientów maszyn wirtualnych z systemem 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 %
   
   

   LUB Gdy łączna liczba zeskanowanych maszyn wirtualnych przekroczy 50, skrypt zostanie uruchomiony automatycznie w tle:

   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

   Przykład 2 (funkcja tylko do odczytu) Przeskanuj najnowszą kopię zapasową pojedynczego urządzenia klienckiego za pomocą --vm <vm name> flaga

   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

   Przykład 3 (funkcja zapisywalna) Tak samo jak w przykładach 1 i 2, ale tym razem --DELETE_SNAPSHOTS dodano opcję

   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

Ręczne ustawianie LVM dla starszych lub niepoprawionych proxy Avamar

1. Jako kopia zapasowa katalogu głównego serwera proxy pliku lvm.conf

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

2. Edytuj plik /etc/lvm/lvm.conf, poszukaj istniejącej linii "filter" i zmień ją na poniższą.

   PRZED

       filter = [ "a/.*/" ]

   PO

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

3. Sprawdź, czy nowe ustawienie filtra zostało ustawione, uruchamiając to polecenie

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