VMWARE & VEEAM backup решение проблем, ошибок

[IgorA100]

После миграции VM "на горячую" возможны проблемы бекапа при использвании Veeam. Это связано с VMware Tools и UUID жесткого диска.
http://pyatilistnik.org/oshibka-v-esxi- ... pt-failed/

[IgorA100]

Переместить репозиторий veeam

0. Убедитесь, что задания направленные на ваш старый репозиторий остановлены.
1. Пройдите в вашу главную вкладку Home и затем в столбец слева -> Backups. В данном разделе указан список ваших цепочек резервного копирования.
2. Выберите любую цепочку, которая хранится на данный момент на вашем старом репозитории, кликните правой кнопкой и выберите вариант "Remove from configuration". Это удалит запись о цепочке из базы данных Veeam.
3. Далее, перенесите файлы из старого репозитория в новый вручную, обычными операциями Windows;
4. Проведите ре-сканирование нового репозитория, перенесенная цепочка будет добавлена в раздел Home -> Backups -> Disk (imported);
5. Теперь осталось только пере-мапить эту цепочку в ваше задание. Откройте свойство задания, перейдите на пункт Storage и выберите ваш новый репозиторий. Далее, нажмите опцию Map Backup и выберите вашу вновь импортированную цепочку. Сохраните настройки.

[IgorA100]

Как известно, на дворе уже 2022г и вышла VBR уже 11й версии, а проблема NAT так и не решена и вендор похоже не считает проблемой момент, когда сервер VBR находится за NAT во внутреннем адресном пространстве, а агент находится совсем в другой подсети (например WEB сайт).
Тут описаны некие "костыли":
https://forums.veeam.com/veeam-agent-fo ... 3e73bea312
https://www.sysadmintutorials.com/veeam ... nat-setup/

На данный момент самое правильное решение: поднять VPN туннель между сетями и тогда все станет на свои места!

[IgorA100]

Иногда при переносе виртуальной Linux машины с одного гипервизора на другой (особенно если гипервизоры совсем разные, например одна VMWare а другая VirtualBox или наоборот или ....) происходит ошибка ее загрузки и выдачей сообщений типа:

dracut-initqueue[259]: Warning: dracut-initqueue timeout
Warning: /dev/centos/root does not exist
Warning: /dev/centos/swap does not exist
Warning: /dev/mapper/centos-root does not exist

boot.PNG1.png (10.82 КБ) 7932 просмотра

Решение очень простое.
1. При загрузке системы необходимо запомнить имя последнего (свежего) ядра загрузки (оно как правило самое верхнее).

boot_menu.PNG1.png (5.95 КБ) 7932 просмотра

На данном скриншоте это 3.10.0-327.36.3.el7.x86_64
2. Выбрать загрузку самого старого ядра (как правило самое нижнее включающее в свое имя: rescue. Система должна успешно загрузиться.
3. Смотрим более точное название файла со свежим ядром (расширение файла *.img") в каталоге /boot, например там может быть имя initramfs-3.10.0-327.36.3.el7.x86_64.img
4. Выполняем команду типа:

Код: Выделить всёdracut -f /boot/initramfs-3.10.0-327.36.3.el7.x86_64.img 3.10.0-327.36.3.el7.x86_64


После чего перезагружаемся и наслаждаемся работой.

Еще как упрощенный вариант (который должен работать), так же загрузить старое rescue ядро, залогиниться под rootом и выполнить простую команду:

Код: Выделить всёdracut --regenerate-all --force

Если необходимо временно выключить файервол, то выполняем:

Код: Выделить всёsystemctl stop iptables.service

Источник: https://forums.centos.org/viewtopic.php?t=63988

[IgorA100]

Для возможности формирования ISO имиджа Veeam диска восстановления необходимо доустановить пакет genisoimage на Linux машину:

Код: Выделить всёyum install genisoimage