Go to the profile of Alexander Bazhenov
Alexander Bazhenov
01011010 10111010

Резервное копирование виртуальных машин в VMware ESXi

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

Для хранения резервных копий ВМ можно использовать накопители, поддерживающие следующие протоколы:

  • NFS (Network File System), с тем же диапазоном IP-адресов и физически расположеннй в той же сети, что и интерфейс управления VMware (Management Network VMkernel Port),
  • iSCSI (Internet Small Computer System Interface), с тем же диапазоном ардесов и физически расположенный в той же сети, что и интерфейс (iSCSI VMkernel).

Но ghettoVCB поддерживает только монтирование и размонтирование NFS-дисков. Для iSCSI следует заранее смонтировать Disk/LUN, а параметры ENABLE_NON_PERSISTENT_NFS и UNMOUNT_NFS установить в нулевое значение (см. ниже).

В данном примере буедем копировать на NFS с IP-адресом 192.168.3.200, тогда как интерефейс управления гипервизором (Management Network VMkernel) имеет адрес 192.168.0.222 и маску подсети 255.255.0.0.

Настройка резервного копирования.

Итак, первое, что нужно сделать — это включить доступ по SSH к консоли гипервизора: открываем VMware vSphere Client, выбираем хост, открываем вкладку ‘Configuration’ и, как показано на скриншоте:

Security Profile -> Services -> Properties -> SSH -> Options -> Start

Во-вторых, убедимся, что на вашем сервере NFS включена опция ‘async’, существенно ускоряющая процесс копирования. Правда, за скорость приходится платить: есть риск потерять данные в случае крэша NFS-сервера. Если такая вероятность, все же, есть — используйте ‘sync’. В остальных случаях:

# vi /etc/exports
/nfs *(rw,all_squash,async,no_subtree_check,insecure,anonuid=500,anongid=1000)
# /etc/init.d/nfs-kernel-server reload

В третьих, скачиваем скрипт ghettoVCB с github по клику на ZIP-архив и заргужаем его на ESX/ESXi хост, используя scp, или WinSCP. Советую расположить подальше от корневой директории: на ваш datastore, в папку с виртуальными машинами — будет идеально. У меня это: /vmfs/volumes/datastore1.

Теперь логинимся по SSH в консоль гипервизора под учетной записью root, распаковываем архив и выставляем права:

# cd /vmfs/volumes/datastore1
# unzip ghettoVCB-master.zip && cd ghettoVCB-master
# chmod u+x ghettoVCB.sh
# chmod u+x ghettoVCB-restore.sh

Создать файл конфигурации необходимо непосредственно в самой консоли гипервизора, используя vi. Ни в коем случае не редактируйте конфигурационный файл в windows-приложениях (таких как: Notepad, Notepad+) с последующей заливкой на хост из-за разных комбинаций кодов перевода строк (CR+LF / LF). Так же во избежание ошибок в работе скрипта избегайте лишних пробелов в конце строк и пустых отступов.

# vi /vmfs/volumes/datastore1/ghettoVCB-master/my.conf
VM_BACKUP_VOLUME=/vmfs/volumes/backup/esxi
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=4
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=1
NFS_SERVER=192.168.3.200
NFS_MOUNT=/nfs/backups
NFS_VM_BACKUP_DIR=esxi
ENABLE_NON_PERSISTENT_NFS=1
NFS_LOCAL_NAME=backup
UNMOUNT_NFS=1
SNAPSHOT_TIMEOUT=15
EMAIL_LOG=1
EMAIL_SERVER=mail.core.local
EMAIL_SERVER_PORT=25
EMAIL_DELAY_INTERVAL=1
EMAIL_TO=admins@mail.local
EMAIL_FROM=ghettoVCB@vm01.core.local
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=

По окончанию редактирования последовательно нажмите: Esc, :, w, q, Enter.

Описание параметров следующее:

VM_BACKUP_VOLUME — путь на сервере ESXi, куда будет монтироваться NFS раздел (или где будет создана резервная копия виртуальных машин — см. параметр ENABLE_NON_PERSISTENT_NFS)

DISK_BACKUP_FORMAT — формат VMDK диска (zeroedthick, eagerzeroedthick, thin, 2gbsparse).

VM_BACKUP_ROTATION_COUNT=4 — количество хранимых бэкапов.

POWER_VM_DOWN_BEFORE_BACKUP=0 — отключать машину перед бэкапом (0=не отключать). Cкрипт может так же копировать и включенные ВМ.

ENABLE_HARD_POWER_OFF=0 — отключать жесткие диски перед бэкапом. Eсли не установлены VMware Tools, то “жесткое” отключение ВМ (hard power off).

ITER_TO_WAIT_SHUTDOWN=3 — если ENABLE_HARD_POWER_OFF=1, то количество минут, прежде, чем скрипт произведет “жесткое” отключение ВМ (hard power off).

POWER_DOWN_TIMEOUT=5 — количество минут, которые скрипт будет ждать при отключении ВМ, прежде, чем проигнорирует её состояние и приступит к резервному копированию.

SNAPSHOT_TIMEOUT=15 — количество минут, которое скрипт будет ждать при создании копии конкретной ВМ, прежде, чем проигнорирует её (в случае каких-либо сбоев в резервном копировании).

ENABLE_COMPRESSION=0 — включение компрессии (0=отключено и остается на zfs). В ESXi 3.x / 4.x / 5.x, существует ограничение максимального размера виртуальной машины для сжатия. При попытке восстановления ВМ свыше ограничений данные могут быть потеряны. Внимательно тестируйте процесс восстановления, прежде, чем перейти к производственным системам.

VM_SNAPSHOT_MEMORY=0 и VM_SNAPSHOT_QUIESCE=0 — параметры отвечающие за снимки памяти. Eсли первый параметр “1”, то будет ли переведена машина на этот период в режим ожидания. Позволяет выявить, когда была сделана копия ВМ, но никак не используется при восстановлении ВМ. Первоначально параметры добавлены с целью отладки и в большинстве случаев не нужны.

VMDK_FILES_TO_BACKUP="my1.vmdk",”my2.vmdk” — задает список VMDK с определенной VM. Если список пуст, то будут скопированы все VMDK (=all).

ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0 — определяет, будет ли создаваться бэкап ВМ со всеми снапшотами.

VM_SHUTDOWN_ORDER=vm1,vm2,vm3 — определяет в каком порядке будут выключены ВМ (если между ними есть какая-либо зависимость).

VM_STARTUP_ORDER=vm3,vm2,vm1 — определяет порядок запуска ВМ.

ENABLE_NON_PERSISTENT_NFS=1 — позволяет подключать NFS-диски (NFS share) для создания бэкапа. Если 0, то параметры UNMOUNT_NFS, NFS_SERVER, NFS_MOUNT, NFS_LOCAL_NAME и NFS_VM_BACKUP_DIR будут проигнорированы.

UNMOUNT_NFS=1 — определяет размонтировать ли NFS-диск по завершению создания бэкапов ВМ.

NFS_SERVER=192.168.3.200 — IP-адрес или имя хоста NFS-диска. Если на сервере ESXi уже есть подключенный NFS диск с такими же координатами (сервер/путь), то диск не подключится.

NFS_MOUNT — путь к NFS диску (NFS export path).

NFS_LOCAL_NAME — имя, которое будет присвоено подключенному диску (datastores ID);

NFS_VM_BACKUP_DIR — путь, где будут создаваться копии ВМ (относительно VM_BACKUP_VOLUME).

RSYNC_LINK=0 — предназначено для синхронизации бэкапов по Rsync. Подробности расписаны здесь.

EMAIL_LOG=1 — определяет, отправлять ли логи по почте.

EMAIL_DEBUG=1 — определяет, отправлять ли отладочные логи (debug logs) по почте.

EMAIL_SERVER, EMAIL_SERVER_PORT, EMAIL_TO, EMAIL_FROM — соответственно емейл сервер, порт, адрес отправки и отправителя (например, если потребуется определенная запись домена для отправителя в зависимости от конфигурации сервера электронной почты).

Продолжим настройку. Cмотрим список активных ВМ и добавляем необходимые в список:

# esxcli vm process list
# vi /vmfs/volumes/datastore1/ghettoVCB-master/my.list
CentOS
Debian
WIN7TEST

Для отправки логов на почту необходимо разрешить исходящий трафик в firewall на сервере ESXi, добавив строчки в конце xml-файла:

# chmod 644 /etc/vmware/firewall/service.xml
# chmod +t /etc/vmware/firewall/service.xml
# vi /etc/vmware/firewall/email.xml
  <service>
    <id>SMTP</id>
    <rule id=”0000">
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>25</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>

Перечитываем правила фаервола и проверяем:

# esxcli network firewall refresh
# esxcli network firewall ruleset list | grep SMTP

Для того, чтобы назначить резервное копирование по расписанию, необходимо добавить в cron строку с командой резервного копирования. Но в нашем случае строка содержит вычисление номера недели в текущем месяце (для того, чтобы не захламлять сервер). Если добавить это выражение сразу в cron, то его значение не вычислится. Поэтому сначала нужно создать отдельный shell-скрипт, вызывающий ghettoVCB с выражением для подсчета номера недели:

# vi /vmfs/volumes/datastore1/ghettoVCB-master/start.sh
#!/bin/sh
#
# sh script to runs ghettoVCB with -g <config> -f <list> and output the
# result into ghettoVCB-week<number>.log
/vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB.sh -g /vmfs/volumes/datastore1/ghettoVCB-master/my.conf -f /vmfs/volumes/datastore1/ghettoVCB-master/my.list > /var/log/ghettoVCB-week-$((($(date +\%d)-1)/7+1)).log
exit 0

Разрешаем запуск:

# chmod u+x /vmfs/volumes/datastore1/ghettoVCB-master/start.sh

Бэкапить будем каждую субботу в час ночи. Системное время задается в UTC, поэтому его нужно внести с учетом поправки на Ваш часовой пояс. В моем случае — это UTC+3, значит нужно внести время на три часа раньше, то есть в пятницу в 22:00. Но если мы добавим строчку в crontab следующим образом:

# /bin/kill $(cat /var/run/crond.pid)
# /bin/echo "0 21 * * 5 /vmfs/volumes/datastore1/ghettoVCB-master/start.sh" >> /var/spool/cron/crontabs/root
# /bin/crond

то все настройки потеряются при перезагрузке сервера ESXi. Поэтому команды на изменение настроек cron’a необходимо добавить в загрузочный скрипт:

# vi /etc/rc.local.d/local.sh
#!/bin/sh
# ...
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 21 * * 5 /vmfs/volumes/datastore1/ghettoVCB-master/start.sh" >> /var/spool/cron/crontabs/root
/bin/crond

Аналогичная ситуация и с настройками firewall сервера ESXi: для их сохранения придется создать VIB-пакет с помощью утилиты VIBauthor и установить его на сервер ESXi. К сожалению, VIBauthor распространяется только для 32-х битных (нет поддержки 64 бит) RPM-based дистрибутивов Linux. Я буду использовать CentOS 6.7 i386 Minimal, вы можете использовать дистрибутив SUSE Linux Enterprise 11 SP2, рекомендованый в документации. Для того, чтобы не ругалось при устаеновке VIBauthor на зависимости (а точней, разрядность) используем ключ “nodeps” и далее подготавим дерево директорий для сборки пакета:

# yum -y install python-lxml
# rpm -ivh --nodeps http://download3.vmware.com/software/vmw-tools/vibauthor/vmware-esx-vib-author-5.0.0-0.0.847598.i386.rpm
# mkdir -p stage/payloads/payload1/etc/vmware/firewall/

Фактически, то, что за папкой payload1 — это желаемый путь расположения пакета на сервере ESXi. Теперь создаем описание пакета:

# vi stage/descriptor.xml
<vib version=”5.0">
  <type>bootbank</type>
  <name>smtpFirewall</name>
  <version>5.0.0–6.0.1</version>
  <vendor>AlexanderBazhenov</vendor>
  <summary>Custom VIB</summary>
  <description>Adds SMTP firewall rule to ESXi host</description>
  <relationships>
    <depends>
    </depends>
    <conflicts/>
    <replaces/>
    <provides/>
    <compatibleWith/>
  </relationships>
  <software-tags>
  </software-tags>
  <system-requires>
    <maintenance-mode>false</maintenance-mode>
  </system-requires>
  <file-list>
  </file-list>
  <acceptance-level>community</acceptance-level>
  <live-install-allowed>true</live-install-allowed>
  <live-remove-allowed>true</live-remove-allowed>
  <cimom-restart>false</cimom-restart>
  <stateless-ready>true</stateless-ready>
  <overlay>false</overlay>
  <payloads>
    <payload name=”payload1" type=”vgz”></payload>
  </payloads>
</vib>

и непосредственно само правило firewall’а:

# vi stage/payloads/payload1/etc/vmware/firewall/smtpFirewall.xml

<ConfigRoot>
  <service>
    <id>SMTP</id>
    <rule id="0000">
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>25</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

Теперь можно собрать пакет:

# vibauthor -C -t stage -v smtpFirewall.vib

скопировать его с помощью SCP на сервер ESXi:

# scp smtpFirewall.vib root@192.168.0.222:/tmp/

установить и проверить, что получилось:

# esxcli software vib install -v /tmp/smtpFirewall.vib -f
# esxcli software vib list | grep smtp
# esxcli network firewall refresh
# esxcli network firewall ruleset list | grep SMTP

По желанию можно воспользоваться моим VIB-пакетом.

Для того, чтобы устанавливать подобные дополнения нужно, чтобы на сервере ESXi параметр Acceptance Level был выставлен в значение “Community Supported”. Для этого в клиенте vSphere открываем, как показано на скриншоте:

Host -> Configuration -> Security Profile -> Host Image Acceptance Level

И финальный штрих: завершаем процесс настройки созданием бэкапа настроек сервера ESXi:

# /sbin/auto-backup.sh

Файл настроек сервере ESXi хранится в /bootbank/state.tgz и предназначен для восстановления в случае внезапного завершения работы, или перезагрузки сервера ESXi (читайте здесь). Если настройки сервера не меняются, то можно скопировать этот файл вручную, в противном случае — настройки сервера ESXi (stage.tgz и папку ghettoVCB-master) будем так же бэкапить каждую неделю. Для этого добавим в конец start.sh перед строкой “exit 0” строки:

# vi /vmfs/volumes/datastore1/ghettoVCB-master/start.sh
# монтируем NFS как backup
esxcli storage nfs add -H 192.168.3.200 -s /nfs/backups -v backup
# копируем state.tgz
/bin/cp -rd /bootbank/state.tgz /vmfs/volumes/backup/esxi/state.tgz
# копируем папку ghettoVCB-master
/bin/cp -rfd /vmfs/volumes/datastore1/ghettoVCB-master /vmfs/volumes/backup/esxi
# размонтируем NFS
esxcli storage nfs remove -v backup

Создание резервных копий ВМ.

Проверить настройки и запустить тестовое создание бэкапа в ручную можно командой:

# /vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB.sh -g /vmfs/volumes/datastore1/ghettoVCB-master/my.conf -f /vmfs/volumes/datastore1/ghettoVCB-master/my.list > /var/log/ghettoVCB-testlog00.log

Для отдельной ВМ с именем ‘MyVirtualMachine’:

# /vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB.sh -g /vmfs/volumes/datastore1/ghettoVCB-master/my.conf -m MyVirtualMachine

Ключи задания параметров:

-a — создание бэкапа все ВМ хоста;
-f — укзать список ВМ;
-m — имя ВМ для бэкапа;
-c — конфигурация директории бэкапа;
-g — путь к файлу конфигурации;
-l — создание файла лога;
-w — рабочая директория скрипта;
-d — уровень детализации логов (debug level): info, debug, или dryrun (по умолчанию: info).

Бэкап виртуальной машины представляет из себя подкаталог <имя_ВМ>-<дата>_<время>, содержащий .vmx (файл конфигурации ВМ), непосредственно сами .vmdk и status.ok, содержащий в себе сообщение об успешном завершении создания резервной копии.

Восстановление ВМ из резервных копий.

Следует понимать, что если бэкап ВМ производился во включенном состоянии, то после восстановления ВМ будет абсолютно так же, как было бы после крэша — не исключена потеря данных.

Подключаемся к серверу ESXi по SSH, монтируем NFS с бэкапами и проверяем результат. Формат команды для монтирования NFS следующий:

# esxcli storage nfs add -H NFS_IP|NFS_HOSTNAME -s Share_mount_point_on_the_NFS -v NFS_Datastore_Name

Посмотреть список:

# esxcli storage nfs list

Размонтировать:

# esxcli storage nfs remove -v NFS_Datastore_Name

Для ESXi 3.x/4.x подробно расписано здесь. В моем примере NFS монтируется следующей строчкой:

# esxcli storage nfs add -H 192.168.3.200 -s /nfs/backups -v backup

Для указания путей при восстановлении ВМ нельзя использовать симлинки. Если в конфигурации использовать пути вида: /vmfs/volumes/datastore1/esxi/ … /VM_name/ , то при попытке восстановить ВМ получим ошибку:

Support for .tgz not supported - "/volumes/backup/esxi/VM_name" will not be backed up!

Фактически, такое сообщение появляется тогда, когда скрипт не находит бэкап ВМ.

Для того, чтобы задать путь без использования симлинков необходимо узнать UUID устройств. Следующая команда выводит список каждого LUN, подключенного к серверу ESXi и его сопоставление vmfs (Volume Name) к UUID:

# esxcli storage filesystem list

Таким образом вместо “backup” и “datastore1” можно использовать соответствующий UUID:

backup: 9108f6f9–353aeed8;
datastore1: 56b74f4f-85fc58fa-87fe-94de8066eda2.

Подробную информацию про идентификацию дисков и файловых систем в ESX(i) можно получить здесь.

Создаем конфигурацию:

# vi /vmfs/volumes/datastore1/ghettoVCB-master/vms_to_restore.list
# Помещаем сюда список восстанавливаемых машин в формате:
#
# "<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>;
# <NEW_VM_NAME>"
#
# DIRECTORY or .TGZ - путь, где лежит восстанавливаемая машина;
# DATASTORE_TO_RESTORE_TO - путь, куда восстановить машину (директория
#                           будет создана)
# DISK_FORMAT_TO_RESTORE - тип диска ВМ:
#                          1 = zeroedthick,
#                          2 = 2gbsparse,
#                          3 = thin,
#                          4 = eagerzeroedthick;
# NEW_VM_NAME - новое имя ВМ (не обязательно)
#
# Например:
"/vmfs/volumes/9108f6f9–353aeed8/esxi/WIN7TEST/WIN7TEST-2016–04–04_02–04–18/;/vmfs/volumes/56b74f4f-85fc58fa-87fe-94de8066eda2/;3;WIN7TEST"

и восстанавливаем ВМ:

# /vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB-restore.sh -c /vmfs/volumes/datastore1/ghettoVCB-master/vms_to_restore.list -l /var/log/vms-restore00.log

где:
-c — путь к списку восстанавливаемых машин.
-l — путь расположения логов.

Поскольку резервная копия ВМ представляет из себя набор образов .vdmk и файл-конфигурации .vmx, то можно просто скопировать данные и исправить .vmx:

displayName = WIN7TEST
extendedConfigFile = "WIN7TEST"
scsi0:0.fileName = "WIN7TEST-0.vmdk"
sched.swap.derivedName = "WIN7TEST.vswp"

Через vSphere клиент открываем, как на скриншоте ниже:

host -> Configuration -> Storage -> Browse Datastore

на файле .vmx жмем правую кнопку мыши и выбираем “Add to inventory”.

Troubleshooting.

Для того, чтобы создать резервную копию с отладочной информацией необходимо вызвать ghettoVCB с ключем: -d debug

# /vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB.sh -g /vmfs/volumes/datastore1/ghettoVCB-master/my.conf -f /vmfs/volumes/datastore1/ghettoVCB-master/my.list -d debug > /var/log/ghettoVCB-testlog00.log

Для отладки процесса восстановления:

# /vmfs/volumes/datastore1/ghettoVCB-master/ghettoVCB-restore.sh -c /vmfs/volumes/datastore1/ghettoVCB-master/vms_to_restore.list -l /var/log/vms-restore00.log -d 1

где: -d — уровень детализации при отладке (debug level) (1–2). При включении отладочной информации восстановление не произойдет.

Могут возникнуть ситуации, когда потребуется прервать выполнение ghettoVCB.sh, запущенного в ручном (интерактивном) режиме. Нажмите cntrl+C для остановки родительского процесса и далее:

# ps -c | grep ghettoVCB | grep -v grep
35598 35598 tail tail -f /tmp/ghettoVCB.work/ghettovcb.Cs1M1x
# kill -9 35598

Для остановки ghettoVCB, запущенного в неинтерактивном режиме:

# ps -c | grep ghettoVCB | grep -v grep
39577 39577 busybox ash ./ghettoVCB.sh -f list -d debug
43478 43478 tail tail -f /tmp/ghettoVCB.work/ghettovcb.ohhyZb

и завершить оба дочерних процесса по их PID:

# kill -9 39577 43478

Если виртуальная машина находилась в процессе резервного копирования, то открыт дополнительный процесс — vmkfstools:

# ps -c | grep vmkfstools | grep -v grep
39579 39579 vmkfstools           /sbin/vmkfstools -i /vmfs/volumes/56b74f4f-85fc58fa-87fe-94de8066eda2/WIN7TEST.vmdk -a lsilogic -d thin /vmfs/volumes/9108f6f9–353aeed8/esxi/WIN7TEST/WIN7TEST-2013-01-26_16-45-35/WIN7TEST.vmdk
# kill -9 39579