Авамар: Резервні копії віртуальних машин Linux можуть мати неузгодженість метаданих LVM, якщо вони розгорнуті з шаблону

Під час відновлення спостерігаються такі симптоми:

1. Помилка роботи FLR з проблемою LVM:
   

   АБО
   
   2 ВМ

2. Завдання з відновлення образу успішно виконуються в інтерфейсі користувача Avamar, віртуальна машина (віртуальна машина) може мати видачу завантаження через проблему LVM.

   Приклад проблеми завантаження 1:
   У наведеному нижче прикладі Red Hat операційна система завантажується в аварійну оболонку dracut:
   

   (У цьому прикладі) у командній оболонці dracut наступна команда LVM відновлює стан LVM. Результат показує, що проблема полягала в тому, що один з дисків lvm (sdb) було неправильно видалено з LVM.

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

   
   Тепер відновлена віртуальна машина може завантажуватися.

   Приклад проблеми завантаження 2:
   У прикладі Debian операційна система завантажується в оболонку екстреного зайнятого боксу:
   

   (У цьому прикладі) з оболонки busy box наступне lvm команда відновити стан групи томів LVM з попередньої конфігурації:

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

    

   Примітка: vm1-vg — це назва групи томів у цьому прикладі

    

   
   Тепер відновлена віртуальна машина може завантажуватися.

Інші симптоми:

Серійні віртуальні машини (ВМ) можуть успішно перезавантажуватися. Проблема стосується лише резервних копій віртуальних машин Linux, які використовують LVM і були розгорнуті з того самого шаблону.
Віртуальні машини Windows і Linux, які НЕ використовують конфігурації LVM, НЕ мають проблем з FLR або завантаженням резервних копій.

Передумови метаданих LVM:

1. Віртуальні машини Linux, налаштовані за допомогою LVM, клонуються або розгортаються з того самого шаблону. Отримані нові віртуальні машини мають ідентичні унікальні ідентифікатори LVM (UUID).
2. Будь-які зміни, внесені до дисків LVM (наприклад, додавання віртуального диска до LVM), вимагають оновлення даних метаданих LVM. LVM відстежує ці оновлення за допомогою поля, яке називається порядковими номерами версій (vg_seqno). Це число збільшується щоразу, коли вносяться зміни.

Проблема гарячого додавання резервного копіювання:
Під час резервного копіювання Avamar, якщо виконуються такі умови:

1. Резервне копіювання вихідної та клонованої віртуальних машин здійснюється одночасно за допомогою гарячого додавання (метод транспортування за замовчуванням).
2. Обидві віртуальні машини додаються за допомогою одного і того ж проксі-сервера Avamar.
3. Ревізії LVM відрізняються залежно від віртуальних машин, які додаються гаряче.

Ядро Linux проксі-сервера Avamar помилково припускає, що диски двох віртуальних машин знаходяться в одній групі томів LVM, оновлюючи метадані LVM автоматично. Якщо це оновлення LVM відбувається, метадані LVM не відповідають резервній копії.

Проблема відновлення:
Під час створення образу віртуальна машина може відображати «Відсутні фізичні екстенти LVM» або «Невідповідності ідентифікатора транзакції» через неправильні метадані LVM, оновлені під час гарячого резервного копіювання. Ця розбіжність виникає через вищезгадане оновлення.

Інструменти LVM для відновлення, такі як vgcfgrestore, vgextend –restoremissingі vgchange -ay –activationmodepartial може знадобитися для повного завантаження або для відновлення резервної копії для виправлення стану LVM.

Цю проблему вирішено в поточних виправленнях проксі-сервера Avamar:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Старіша версія Avamar: Дивіться примітки нижче.

Ці виправлення змінюють конфігурацію параметра LVM на проксі-сервері Avamar, щоб запобігти оновленню метаданих LVM під час операцій гарячого додавання.

ДО виправлення

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

Виправлення ПІСЛЯ

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

Для будь-якого з клієнтів, яких це стосується, ми повинні примусово створити резервну копію L0 за допомогою відстеження блоків змін (CBT). Це гарантує, що правильні метадані LVM будуть записані в нових резервних копіях.

Щоб допомогти у виявленні клієнтів, інженери Avamar розробили новий сценарій. Цей скрипт сканує резервні копії Linux на наявність невідповідностей LVM і автоматично скидає cbt для наступного завдання, якщо такі будуть знайдені.

vmlvmcheck.pl

1. Цей скрипт повинен бути встановлений на сервері Avamar.
2. Скрипт має бути запущено від імені користувача root.
3. Цей скрипт сканує останню резервну копію всіх клієнтів віртуальної машини Linux і перевіряє узгодженість LVM.
4. Цей скрипт може вимагати великої тривалості (годин) при скануванні багатьох віртуальних машин. За замовчуванням, якщо кількість просканованих віртуальних машин перевищує 50, скрипт працює у фоновому режимі/режимі демона.

Логіка сценарію:
Скрипт знаходить логічні томи LVM у резервних копіях .vmdk і перевіряє такі умови:

1. Гарантує, що всі фізичні томи присутні в резервній копії
2. Перевіряє, що всі фізичні томи пов'язані з групою томів LVM
3. Всі фізичні томи для однієї групи томів мають однакові порядкові номери.

Помилкові спрацьовування:

1. Якщо деякі віртуальні диски для виявленої групи томів НЕ були включені, резервна копія цього інструменту позначає резервну копію. Першопричина не пов'язана з проблемою гарячого додавання, описаною вище. У цьому випадку переконайтеся, що Avamar створює резервні копії всіх віртуальних дисків.
2. Якщо будь-який з віртуальних дисків містить розділ LVM, який НЕ повністю ініціалізований, інструмент визначає резервне копіювання як погане. Однак у цьому сценарії операційна система НЕ матиме жодних проблем із завантаженням.

Завантажити інструкцію:

1. Завантажте vmlvmcheck.pl з веб-сайту central.dell.com . Для отримання додаткової інформації про центральний дивіться KB Avamar: Як знайти та завантажити сценарії та інструменти Avamar зі сторінки Dell Central Avamar.
   

2. Перенесіть vmlvmchck.pl в каталог '/root' на сервері Avamar за допомогою такого інструменту, як WinSCP.

   Приклад 1 (функція лише для читання) Сканує останню резервну копію всіх клієнтів віртуальних машин 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 %
   
   

   АБО Коли загальна кількість перевірених віртуальних машин перевищує 50, скрипт запускається автоматично у фоновому режимі:

   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

   Приклад 2 (функція лише для читання) Сканування останньої резервної копії одного клієнта за допомогою --vm <vm name> прапор

   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

   Приклад 3 (записувана функція) Те саме, що і в прикладах 1 і 2, але цього разу --DELETE_SNAPSHOTS додано опцію

   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

Налаштування LVM вручну для старих або невиправлених проксі-серверів Avamar

1. В якості кореневого проксі-сервера створіть резервну копію файлу lvm.conf

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

2. Відредагуйте файл /etc/lvm/lvm.conf, знайдіть наявний рядок "filter" і змініть його на наступний.

   ПЕРЕД

       filter = [ "a/.*/" ]

   ПІСЛЯ

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

3. Перевірте, чи встановлено новий параметр фільтра, виконавши цю команду

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