Avamar. Резервные копии виртуальных машин 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 операционная система загружается в оболочку аварийно занятого ящика:
   

   (В данном примере) из оболочки занятого ящика выполните следующий lvm команда restore состояние группы томов 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 не согласуются в резервной копии.

Проблема восстановления:
Во время создания образа на виртуальной машине может отображаться сообщение «Missing LVM physical extents» или «Transaction ID mismatchs» из-за неверных метаданных 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 Server.
2. Сценарий должен запускаться от имени пользователя root.
3. Этот сценарий сканирует последнюю резервную копию всех клиентов виртуальных машин Linux и проверяет согласованность LVM.
4. Для выполнения этого сценария может потребоваться много времени (несколько часов) в случае сканирования нескольких виртуальных машин. По умолчанию, если количество проверенных виртуальных машин превышает 50, сценарий выполняется в фоновом режиме/режиме управляющей программы.

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

1. Обеспечение наличия всех физических томов в резервной копии
2. Проверка того, что все физические тома связаны с группой томов LVM
3. Все физические тома в одной и той же группе томов имеют идентичные порядковые номера.

Ложные срабатывания:

1. Если некоторые из виртуальных дисков для обнаруженной группы томов НЕ были включены, выполняется резервное копирование этого инструмента. Корневая причина не связана с описанной выше проблемой «горячего» добавления. В этом случае убедитесь, что Avamar выполняет резервное копирование всех виртуальных дисков.
2. Если какой-либо из виртуальных дисков содержит раздел LVM, который НЕ полностью инициализирован, инструмент определяет резервное копирование как поврежденное. Однако в этом случае проблемы с загрузкой операционной системы ОТСУТСТВУЮТ.

Инструкции по скачиванию

1. Скачайте vmlvmcheck.pl с веб-сайта central.dell.com . Дополнительные сведения о центральном компоненте см. в статье базы знаний 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/.*/"]