Резервное копирование виртуальных машин с помощью ghettoVCB

Олег

5 декабря 2023

Всем привет. Сегодня мы с вами настраиваем автоматическое резервное копирование виртуальных машин на ESXi 7 с помощью ghettoVCB. Бэкапы будем делать на отдельный VMFS том, также есть возможность делать резервные копии на NFS хранилище. Дополнительно настроим отправку уведомлений на почту.

ghettoVCB позволяет делать резервное копирование с помощью снапшотов, при этом остановка виртуальной машины не обязательна.

Пока что набор скриптом ghettoVCB — один из лучших способов организации резервного копирования для отдельно стоящего гипервизора ESXi, есть у вас нет какого-нибудь Synology, а просто имеется отдельный VMFS том или хранилище NAS. Раньше был ещё один продукт: Vmware Consolidated Backup (VCB), но его больше не существует.

https://github.com/lamw/ghettoVCB

Скрипт ghettoVCB выполняет резервное копирование виртуальных машин, размещенных на серверах ESX(i) 3.x, 4.x, 5.x, 6.x, 7.x и 8.x, используя методологию, аналогичную инструменту VMware VCB. Скрипт создает моментальные снимки работающих виртуальных машин, делает резервные копии главных VMDK, затем удаляет моментальный снимок до следующего резервного копирования. выполняется на ESXi.

Возможности ghettoVCB

Резервное копирование VM онлайн
Поддержка нескольких VMDK дисков VM
Будут скопированы только те VMDK, которые подключены к VM
Возможность выключения гостевой ОС перед резервным копированием и включение VM после окончания резервного копирования
Поддержка пробелов в списке VM (не рекомендуется)
Проверка удаления предыдущего снапшота перед началом следующего резервного копирования
VM со снапшотами по умолчанию не резервируются
Возможность указать количество хранимых резервных копий VM
Бэкап дисков VMDK в формате ZEROEDTHICK или 2GB SPARSE или THIN или EAGERZEROEDTHICK
Поддержка SCSI и IDE дисков
Резервное копирование на неподключенное NFS хранилище
Полная поддержка VMDK на нескольких хранилищах
Возможность сжатия бэкапов (экспериментально)
Возможность настройки индивидуальных политик резервного копирования VM
Возможность исключить специфические VMDK
Возможность настройки логирования в файл
Независимая информация о дисках (игнорирование VMDK)
Переменный таймаута для выключения и создания снапшота
Возможность конфигурации снапшотов с сохранением оперативной памяти или опцией паузы VM
Возможность настройки формата дискового адаптера
Дебаг и сухой прогон
Поддержка VM с virtual/physical RDM (RDM игнорируются)
Поддержка глобального файла конфигурации
Поддержка списка исключений VM
Поддержка бэкапов всех VM гипервизора без указания списка
Реализован механизм блокировки, не позволяющий запустить второй экземпляр скрипта ghettoVCB
Обновление структуры каталогов бэкапов - rsync friendly
Дополнительное логирование и финальный статус
Логирование ghettoVCB PID (proces id)
Отправка логов по email (экспериментально)
Поддержка Rsync "Link" (экспериментально)
Улучшенная детализация "dryrun" включая конфигурацию и/или проблемы с VMDK
Новая детализация дебага хранилищ перед и после бэкапа
Суммарный статус на email
Обновлённая документация ghettoVCB
ghettoVCB на github
Поддержка ESXi 5.1 NEW!
Поддержка бэкапа индивидуальной VM через консоль NEW!
Поддержка VM со снапшотами NEW!
Поддержка нескольких инстансов ghettoVCB NEW! (экспериментально)
Настройка порядка выключения/снапшота VM NEW!
Поддержка изменения названия VM при восстановлении NEW!

Установка ghettoVCB

Последнюю версию ghettoVCB VIB и Offline Bundle можно скачать здесь.

Установка VIB:

esxcli software vib install -v /vghetto-ghettoVCB.vib -f

Установка автономного пакета Bundle ZIP:

esxcli software vib install -d /vghetto-ghettoVCB-offline-bundle.zip -f

Обновление VIB:

esxcli software vib update -v /vghetto-ghettoVCB.vib -f

Обновление автономного пакета Bundle ZIP:

esxcli software vib update -d /vghetto-ghettoVCB-offline-bundle.zip -f

Удаление ghettoVCB:

esxcli software vib remove -n ghettoVCB

На самом деле можно и не устанавливать пакет, а просто скачать его. Рассмотрю разные варианты. Я буду устанавливать с помощью VIB пакета.

Как установить VIB пакет

Скачиваю его.

С помощью WinSCP закидываю VIB пакет на гипервизор в папку /tmp.

Включаю службу SSH на гипервизоре, с помощью PuTTY захожу на него и проверяю, что VIB пакет присутствует в папке tmp.

Разрешаю установку пакетов со сторонними сертификатами. Для этого перед установкой выполняю команду:

esxcli software acceptance set --level=CommunitySupported

Устанавливаю VIB пакет.

esxcli software vib install -v /tmp/vghetto-ghettoVCB.vib -f

После установки пакета скрипты ghettoVCB доступны в /opt/ghettovcb.

Можно использовать эти скрипты как шаблоны. Собственно, поэтому и не обязательно устанавливать VIB пакет, мне нужны только скрипты и конфигурационные файлы. Можно собрать собственный VIB пакет со своими вариантами скриптов и файлов конфигураций, на сайте есть инструкция. Но в моём случае это не требуется, я просто скопирую всё что мне нужно на VMFS хранилище, которое я подключил для хранения бэкапов.

Настройка ghettoVCB

Хранилище у меня называется "BCK". Создаю на нём папку ghettoVCB. Копирую в неё файл конфигурации ghettoVCB.conf.

cd /vmfs/volumes/BCK
mkdir ghettoVCB
cp /opt/ghettovcb/ghettoVCB.conf /vmfs/volumes/BCK/ghettoVCB/

Всё это можно сделать и через GUI.

Собственно, через GUI будет удобнее. Скачиваю конфигурационный файл и редактирую.

Начинаю редактировать.

VM_BACKUP_VOLUME=/vmfs/volumes/BCK — хранилище и папка для хранения бэкапов
DISK_BACKUP_FORMAT=thin — тип диска при бэкапе (zeroedthick, eagerzeroedthick, thin, 2gbsparse)
VM_BACKUP_ROTATION_COUNT=2 — сколько хранить резервных копий
POWER_VM_DOWN_BEFORE_BACKUP=0 — выключать ли VM перед резервным копированием (1 = enable, 0 = disable)
ENABLE_HARD_POWER_OFF=0 — выключать ли жёстко, работает если включена опция POWER_VM_DOWN_BEFORE_BACKUP и не установлены VMware Tools (1 = enable, 0 = disable)
ITER_TO_WAIT_SHUTDOWN=3 — сколько минут ждать перед тем как жёстко выключить, работает если включена опция ENABLE_HARD_POWER_OFF
POWER_DOWN_TIMEOUT=5 — сколько минут ждать выключения VM, перед тем как проигнорировать её и перейти к следующей VM
SNAPSHOT_TIMEOUT=15 — сколько минут ждать снапшота VM, перед тем как проигнорировать её и перейти к следующей VM (у меня медленный гипер, поставил 180 минут)
ENABLE_COMPRESSION=0 — сжимать или нет (1 = enable, 0 = disable)
ADAPTER_FORMAT=buslogic (DEPERCATED) формат типа адаптера, больше не требуется
VM_SNAPSHOT_MEMORY=1 — делать или нет снапшот оперативной памяти (1 = enable, 0 = disable)
VM_SNAPSHOT_QUIESCE=0 — делать или нет паузу виртуальной машины (1 = enable, 0 = disable)
VMDK_FILES_TO_BACKUP="myvmdk.vmdk" — бэкапить диски из списка или все
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0 — бэкапить ли VM с имеющимися снапшотами (1 = yes, 0 = no)
VM_SHUTDOWN_ORDER=vm1,vm2,vm3 — порядок выключения VM
VM_STARTUP_ORDER=vm3,vm2,vm1 — порядок включения VM
WORKDIR_DEBUG=0 — дебаг рабочей директории, не указано в документации, не работает
RSYNC_LINK=0 — поддержка создания символических ссылок (1 = yes, 0 = no), см. документацию

Настройки для подключения NFS во время резервного копирования.

ENABLE_NON_PERSISTENT_NFS=0 — подключать NFS (1 = yes, 0 = no), требует указания переменных UNMOUNT_NFS, NFS_SERVER, NFS_MOUNT, NFS_LOCAL_NAME and NFS_VM_BACKUP_DIR
UNMOUNT_NFS=0 — демонтировать NFS (1 = yes, 0 = no)
NFS_SERVER=172.51.0.192 — NFS сервер (IP/hostname)
NFS_MOUNT=/nfsshare — пути монтирования NFS
NFS_LOCAL_NAME=nfs_storage_backup — имя хранилища NFS
NFS_VM_BACKUP_DIR=mybackups — папка для хранения
NFS_VERSION=nfs — не указано в документации

Настройки почтовых уведомлений. Для отправки писем вам нужен почтовый сервер, в рамках данной статьи разворачивание почтового сервера не рассматривается.

EMAIL_ALERT=1 — не указано в документации, включил на всякий случай
EMAIL_LOG=1 — оправлять лог (1 = yes, 0 = no)
EMAIL_DEBUG=0 — оставлять отправленное письмо на сервере для дебага (1 = yes, 0 = no)
EMAIL_SERVER=192.168.1.11 — почтовый сервер
EMAIL_SERVER_PORT=25 — порт
EMAIL_DELAY_INTERVAL=1 — задержка в секундах при коммуникации с почтовым сервером, важный параметр, об этом далее
EMAIL_USER_NAME= — пользователь для аутентификации, не указано в документации (у меня почта без аутентификации, не использую)б
EMAIL_USER_PASSWORD= — пароль для аутентификации, не указано в документации (у меня почта без аутентификации, не использую)б
EMAIL_TO=hello@example.com — получатели, через запятую
EMAIL_ERRORS_TO=hello@example.com — не указано в документации
EMAIL_FROM=ghettoVCB@internet-lab.ru — адрес отправителя

Загружаю изменённый файл обратно.

Рядом с файлом конфигурации создаю файл vm.list, содержащий список VM, которые нужно бэкапить, в одной строке одно имя.

Узнать список запущенных VM можно командой:

esxcli vm process list

Или просто посмотреть в GUI.

В настройках я указал не бэкапить VM со снапшотами. Выберу для тестирования пару виртуальных машин и снесу у них снапшоты.

Первая виртуалка mpwg.

Удаляю снапшоты.

Создаю файл vm.list. Название файла не принципиально.

touch vm.list

vi vm.list

Тестировать бэкап буду на двух виртуальных машинах. Сохраняю файл.

:wq

Можно всё это сделать через GUI.

Пробую запустить бэкап.

/opt/ghettovcb/bin/ghettoVCB.sh -f /vmfs/volumes/BCK/ghettoVCB/vm.list -g /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.conf

/opt/ghettovcb/bin/ghettoVCB.sh — скрипт, который появился при установке VIB пакета
-f — путь к списку VM
-g — путь к файлу конфигурации

Побежали строчки лога. И вижу:

info: ###### Final status: All VMs backed up OK! ######

Обращаю внимание на ошибку:

ERROR: Please enable firewall rule for email traffic on port 25

Резервное копирование выполнилось, но почта не отправилась из-за настроек Firewall.

В хранилище BCK появился бэкап виртуальной машины. Я не буду рассматривать скрипт для восстановления, поскольку в текущем виде бэкап легко и быстро восстанавливается прямо из GUI методом регистрации VM.

Бэкап заработал, а почта ещё нет.

Скопирую скрипт для резервного копирования рядом с файлом конфигурации, чтобы потом его модифицировать.

cp /opt/ghettovsb/ghettoVCB.sh /vmfs/volumes/BCK/ghettoVCB/

Бэкап теперь будет запускаться иначе:

/vmfs/volumes/BCK/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/BCK/ghettoVCB/vm.list -g /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.conf

Автоматизация резервного копирования

Создам расписание и автоматизирую резервное копирование.

Редактирую файл /etc/rc.local.d/local.sh.

vi /etc/rc.local.d/local.sh

Добавляю код:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "5 3 * * FRI  /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/BCK/ghettoVCB/vm.list -g /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.conf" >> /var/spool/cron/crontabs/root
/bin/echo "" >> /var/spool/cron/crontabs/root
crond

Если нужно при этом собирать логи, то код можно модифицировать:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "5 3 * * FRI  /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/BCK/ghettoVCB/vm.list -g /vmfs/volumes/BCK/ghettoVCB/ghettoVCB.conf > /vmfs/volumes/BCK/ghettoVCB-backup-week-$((($(date +\%d)-1)/4+1)).log" >> /var/spool/cron/crontabs/root
/bin/echo "" >> /var/spool/cron/crontabs/root
crond

Поскольку я делаю расписание, то периодичность срабатывания скрипта указывается по правилам cron.

Каждая задача (скрипт) описывается одной строкой в файле crontab. Сначала указывается расписание, потом ссылка на скрипт. Шаблон задания выглядит так:

* * * * * /path/to/job.sh

Что можно понимать как:

[минуты] [часы] [день месяца] [месяц] [день недели] [абсолютный путь к файлу]

Более наглядно (можно скопировать):

# * * * * * /path/to/job.sh
# | | | | |
# | | | | +——— день недели (0-6), 0 — воскресенье
# | | | +————— месяц (1-12)
# | | +——————— день месяца (1-31)
# | +————————— часы (0-23)
# +——————————— минуты (0-59)

* — звёздочка обозначает все значения
, — разделитель значений
- — диапазон значений
/ — чередование значений

Cron — планировщик заданий в Linux

У меня расписание:

5 3 * * FRI

Скрипт будет срабатывать каждую пятницу в 03:05 по UTC.

Код в файле /etc/rc.local.d/local.sh будет после каждой перезагрузки сервера будет дописывать расписание резервного копирования в файл /var/spool/cron/crontabs/root. Перезагружаю и проверяю.

Расписание создалось после перезагрузки ESXi.

Настройка Firewall

В гипервизоре ESXi имеется встроенный Firewall. В нём предустановлен ряд правил, удовлетворяющих разработанному функционалу. Однако, имеющиеся правила не всегда покрывают все необходимые порты, иногда требуется дополнительный функционал. Открываю на выход 25 порт. Создам собственный VIB пакет для внесения изменений в Firewall.

Для удобства всё описание вынесено в отдельную статью:

ESXi 7.0 Firewall — добавляем правило для исходящей почты

В статье подробно описана процедура создания и установки VIB пакета, можно скачать готовый. Собственно, пакет я назвал fw-mail. Скачать его можно в Сборке для VMware. Пакет добавляет правило firewall, которое позволяет отправлять уведомления на внешний почтовый сервер.

Копирую ZIP пакет на хост в папку /tmp.

Запускаю службу SSH на хосте, подключаюсь. Проверяю содержимое папки tmp.

ZIP файл присутствует. Разрешаю установку программ и драйверов со сторонними сертификатами. Для этого перед установкой выполняю команду:

esxcli software acceptance set --level=CommunitySupported

Устанавливаю пакет:

esxcli software vib install -d /tmp/fw-mail-1.0-1-offline_bundle.zip

Пакет установлен. В списке установленных VIB пакетов имеется наш новый пакет.

esxcli software vib list | grep mail

Наш XML файл появился в папке /etc/vmware/firewall.

Теперь правило firewall никуда не должно пропасть после перезагрузки хоста. Проверяю — перезагружаю службу firewall.

esxcli network firewall refresh
esxcli network firewall ruleset list | grep Mail

Networking → Firewall rules. Появилось новое правило:

Mail

Включаю его.

Actions → Enable.

Доступ для отправки почты появился. Проверить можно с помощью nc.

nc -vz 192.168.1.11 25

Порт открыт.

Исправление отправки писем для ghettoVCB

Казалось бы, всё должно работать, но нет. Я столкнулся с ситуацией, когда скрипт ghettoVCB.sh должен отправить письмо, но не отправляет.

Пришлось дебажить, после внесения небольших изменений в код получил список ответов от почтового сервера при отправке письма:

220 mail.moipartner.ru ESMTP
250 Hello.
250 OK
250 OK
354 OK, send.

Получается, скрипт соединяется с сервером, общается без проблем, потом после получения ответа "354 OK, send." ничего не происходит. Такой ощущение, что связь рвётся. Лезу в код, нахожу функцию sendDelay() и смотрю.

sendDelay() {
    c=0
    while read L; do
    	[ $c -lt 4 ] && sleep ${EMAIL_DELAY_INTERVAL}
    	c=$((c+1))
    	echo $L
    done
}

Получается странная картина, первые пять команд отрабатывают с задержкой в EMAIL_DELAY_INTERVAL секунд (у меня в конфигурационной файле EMAIL_DELAY_INTERVAL=1). А остальные команды проходят без задержки. Естественно, они в какой-то момент отваливаются, почтовый сервер просто не успевает.

Переписываю функцию.

sendDelay() {
    while read L; do
        sleep ${EMAIL_DELAY_INTERVAL}
        echo $L
    done
}

Теперь задержка в 1 секунду будет на каждой строке. С учётом того, что в письме будет лог отправки, то письмо будет улетать около минуты. А то и больше, если лог большой.

Загружаю скрипт на сервер.

Пуляю бэкап. Ситуация меняется:

220 mail.moipartner.ru ESMTP
250 Hello.
250 OK
250 OK
354 OK, send.
250 Queued (50.456 seconds)
221 goodbye

Теперь вижу "250 Queued", это означает, что почтовый сервер принял письмо к отправке. Кстати, письмо отправлялось 50 секунд, но я это переживу. Заглядываю в свой почтовый ящик:

Письмо пришло!

Заключение

Сегодня мы познакомились с замечательной утилитой ghettoVCB, которая выполняет резервное копирование виртуальных машин, размещенных на серверах ESX(i) 3.x, 4.x, 5.x, 6.x, 7.x и 8.x. Бэкап был настроен на примере отдельно стоящего ESXi 7, для бэкапа было подключено отдельное хранилище VMFS.

Бэкап на NFS мы не рассматривали по причине отсутствия NFS.

Мы установили утилиту, хотя делать это не обязательно. Настроили её, указали список виртуальных машин и проверили работы резервного копирования. Настроили расписание резервного копирования и проверили, что оно сохраняется после перезагрузки хоста.

Помимо этого мы написали собственный VIB пакет для создания отдельного правила Firewall, разрешающего отправку писем по порту TCP 25. Модифицировали скрипт отправки письма, удалив лишний код. Починили отправку письма и проверили, что письмо отправляется без проблем.