Ghettovcb восстановление виртуальной машины

Бэкап без использования vCenter VMware Snapshot

На данный момент существует два типа бэкапа виртуальных машин:

Технология снимков ВМ не является как таковым Бэкапом, так как сохраняет состояние файла nvram машины (состояние операционной системы, процессы в ней на момент снимка).

Единственный вариант автоматизированного бэкапа, который можно стандартно использовать в vSphere без использования vCenter – это разработки третьих производителей, например: ghettoVCB (рассмотрена далее).

ghettoVCB установка и настройка

Ниже выложено руководство по установке скриптов, а также приведены конфигурационные файлы для бэкапа как локально, так и на удаленном сервере с использованием хранилища сетевой файловой системы (NFS).
В обоих вариантах нам необходимы программа использования SSH, например Putty (http://www.putty.org), а также сам скрипт (доступен для скачивания здесь.
Для начала, выкладываем файл ghettoVCB.tar.gz на DataStore, после чего заходим в Putty, подключаемся к серверу ESX, вводим логин и пароль узла ESX (для этого должен быть включен сервис Remote Tech Support в меню configurations – Security Profile) и проделываем следующие действия:

Откроется файл (пока еще не созданный) со списком тех машин, которые нужно забэкапить.
Для ввода и редактирования информации жмем “a”, чтобы применить настройки Esc.
Чтобы выйти с сохранениями :wq чтобы без :q!
Вводим названия машин, по одной на строке, сохраняем список Esc, :wq.
Далее создаем файл log –

# touch log.
Далее следует прописать настройке в файле ghettoVCB.conf.

#vi ghettoVCB.conf мы увидим следующее:

DISK_BACKUP_FORMAT
Определяет формат забэкапленного диска, возможны варианты: zeroedthick, eagerzeroedthick, thin, 2gbsparse;

ENABLE_HARD_POWER_OFF
Отключение дисков на время бэкапа (enabled=1 disabled=0)

ITER_TO_WAIT_SHUTDOWN
При включенном предыдущем параметре, определяет количество времени (1 единица=60 секунд), прежде чем скрипт выполнит принудительное отключение диска

ENABLE_COMPRESSION
Параметр, при включении которого забэкапленные файлы будут помещаться в архив (enabled=1 disabled=0) (это тестовый параметр для данной версии скрипта, рекомендуется не менять значение по умолчанию 0)

ADAPTER_FORMAT
Формат диска машины (возможны: buslogic lsilogic)

Все эти параметры нужны, если мы планируем создать директорию с бэкапами на удаленном сервере.
Этими параметрами мы настраиваем доступ к NFS хранилищу (его местонахождение, директория на локально сервере и т.д.)
Если создаем директорию бэкапа на том же DataStore, проигнорируем эти параметры

SNAPSHOT_TIMEOUT
Данные параметр отображает, сколько минут будет дано время на создания снапшота работающей машины, после чего скрипт будет отключен (если повременной, то только этот бэкап не будет создан, далее всё пойдет в штатном режиме).
Данный параметр необходим, если по каким либо причинам машина не сделала снимок, прежде чем переходить в режим ожидания, для того, чтобы не потерять данные машины в режиме работы.

Следующие параметры будут отсылать логи на мэйл, при учете того, что в самом скрипте изначально прописаны данные smtp, pop и другие настройки.
Данные параметры являются экспериментальными и не будут работать без дополнительных настроек.
При желании отсылки логов на свой мэйл, требуется ознакомиться с основами perl и досконально изучить данную статью:
http://www.waldrondigital.com/2010/05/11/ghettovcb-e-mail-rotate-logs-batch-file-for-vmware/

Далее приводятся два вида настройки этих параметров без особых углублений (1 – локально, 2 – через сервер NFS)

Локальный бэкап

Бекап на NFS

Чтобы проверить данный скрипт можем запустить его разово.
Для этого ознакомимся с параметрами запуска скрипта:

-a Бэкапит все машины
-f Использование списка ВМ
-c Конфигурация директории бэкапа
-g Использование файла конфигурации
-l Использование файла логов
-d Описание логов [info|debug|dryrun] (изначально: info)

Запустим, например, всё это со следующими параметрами:

В логах, при правильно настроенном файле конфигурации мы увидим примерно следующее:

Основные типы ошибок:

После всего этого необходимо настроить режим создания бэкапов по времени.
Для этого необходимо воспользоваться параметрами CronTab.
Для этого проделываем следующее:

Откроется повременной запуск скриптов.
На новой строчке впишем следующее:

Рекомендуется проверить настройки времени на узле ESX, настроить синхронизацию с ntp сервером.

Скрипт был протестирован в нашей лаборатории.
Во время тестирования были выполнены бэкапы остановленных и работающих машин на datastore и в папку NFS.
Официально скрипт не поддерживается компанией Vmware и может использоваться только на свой страх и риск.
Для продуктивных сред с критически важными приложениями мы не рекомендуем его использовать и рассмотреть вариант использования Data Recovery + vCenter server.

Data Recovery

Также существует и встроенная функция бэкапа, созданная самой компанией VMware.
Это плагин под названием VMware Data Recovery, который встраивается в vSphere Client и может выполнять различные функции.
Это достаточно удобный из бесплатных способов вид бэкапа, но данная функция в полной степени будет функционировать только с программой vCenter.

Ниже приводим таблицу, сравнивающую возможности скрипта и VMware Data Recovery:

Читайте также:  Выкатка вмятин на машине

1 – DataRecovery Plugin встраивается также, как Vapp, в которой существует своя собственная консоль, для поддержки данного плагина;
2 – данный режим позволяет создавать на датасторе лишь различия между забэкапленной ВМ и рабочей, что позволяет сократить место на бэкап в 1.5-2 раза;
3 – поддержка функции теневых томов, для избежания простоев во время создания бэкапа;

Data Recovery без использования vCenter будет работать напрямую только с одним ESX-хостом и не позволит создавать автоматизированный бэкап (по расписанию) без использования vCenter.

Источник

Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5360 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

VM Guru / Articles / Использование ghettoVCB для резервного копирования виртуальных машин VMware ESX / ESXi.

Серверное администрирование*,
Резервное копирование*
В этой статье я пошагово опишу настройку автоматического резервного копирования и пример восстановления виртуальных машин, работающих на платформе ESX(i) с помощью свободных скриптов ghettoVCB. Акцентироваться буду на версии ESXi 5.x, но эти же средства работают и на версиях 3.5-6.x, правда для ранних версий настройки несколько отличаются. Бэкап будет производиться на NFS сервер. Отчёт о работе будет направлен в почту. Во время бэкапа делается снимок (snapshot) виртуальной машины (в том числе и работающей), сохраняются VMDK диски машины и снимок удаляется.

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

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

Первым делом приготовьте NFS сервер по вкусу, куда будут производится бэкапы. В моём случае это FreeNAS (Freebsd 9.3) и ZFS dataset с включённой дедубликацией и сжатием, что существенно экономит место. Настройка на ESXi сервере производится по SSH от пользователя root. Можно и под другим пользователем с административными правами, но тогда не получится запустить скрипты для проверки из консоли. Приступим.

1. Для настройки необходим доступ на сервер по SSH, включаем через vSphere client:

2. Берём скрипты из github репозитория и помещаем содержимое на сервер. Обязательно ставим бит исполнения, иначе скрипты работать не будут:

# chmod u+x /ghettoVCB-master/ghettoVCB.sh
# chmod u+x /ghettoVCB-master/ghettoVCB-restore.sh

3. Бэкапить будем раз в неделю, с циклом 4 недели. Просроченные бэкапы будут удаляться. Прописываем соответствующий config-файл:

# cat /ghettoVCB-master/4week.conf
VM_BACKUP_VOLUME=/vmfs/volumes/backup
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
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
ENABLE_NON_PERSISTENT_NFS=1
UNMOUNT_NFS=1
# NFS сервер, куда будут лететь бэкапы
NFS_SERVER=10.1.3.101
NFS_MOUNT=/mnt/backup/vmware
NFS_LOCAL_NAME=backup
# папка на NFS сервере (для каждого ESXi своя)
NFS_VM_BACKUP_DIR=autobackup/vm01
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
WORKDIR_DEBUG=0
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=
Где ключевые параметры:

Если на сервере ESXi уже есть подключенный nfs диск с такими же координатами (сервер/путь), то диск не подключится.

Тело письма формируется во время работы скрипта, а затем отсылается утилитой nc. Это может вызвать отказ со стороны почтового сервера, с аргументом «Recipient address rejected: Improper use of SMTP command pipelining». Нужно исключить соответствующую проверку для серверов ESXi (у postfix-а это будет reject_unauth_pipelining).

4. Создаём список машин, которые необходимо бэкапить. Получить его можно с помощью команды esxcli vm process list. Каждая строчка списка — одна машина:

# cat /ghettoVCB-master/week.list
win7
win10
vCenterUpdate
Если нужно несколько планов бэкапов, с разной периодичностью и параметрами — создаём необходимое количество конфигураций.

5. Настраиваем cron на выполнение периодической задачи:

# cat /var/spool/cron/crontabs/root
#min hour day mon dow command
#……………………….

6. Перезапускаем cron:

7. Для отправки почты необходимо добавить разрешение на исходящий трафик в firewall сервера ESXi:

# cat /etc/vmware/firewall/email.xml

email

outbound

# esxcli network firewall refresh
# esxcli network firewall ruleset list | grep email
email true
# nc mail.core.local 25
220 mail.core.local SMTP Postfix
quit
221 2.0.0 Bye

Запустить тестовую проверку бэкапа машины с именем «vCenterUpdate» можно следующим образом:

Запустить в ручную для списка машин:

Каждая копия машин будет хранится в директориях, вида:

И представлять из себя диск машины в формате *.vmdk и файл конфигурации машины *.vmx.

Сохранение конфигурации сервера ESXi

Настройки ESXi, произведённые выше, будут жить до первой перезагрузки. Для сохранения конфигурации нужно сделать ещё ряд действий.

1. Добавим в загрузочный скрипт команды на изменение настроек cron-а:

2. Для сохранения настроек файрвола сделаем собственный VIB пакет и установим его на сервер. Для этого используем утилиту VIB Author. К сожалению, она только для 32-х битной архитектуры, поэтому мне пришлось воспользоваться lxc контейнером. При установке может страшно ругаться на зависимости вида:

Подготавливаем дерево директорий для сборки VIB пакета:

И создаём два файла. Первый — описание нашего пакета:

# cat stage/descriptor.xml

bootbank
mailFirewall
5.0.0-0.0.1
Lelik.13a
Custom VIB from Lelik.13a
Adds custom firewall rule for mail sender to ESXi host

Подробную инструкцию к параметрам можно посмотреть на сайте утилиты.

И второй файл — email.xml, содержимое которого приведено выше. А находится он будет по пути stage/payloads/payload1/etc/vmware/firewall/email.xml, где путь после «payload1» – желаемый путь на целевом сервере.

Собираем VIB пакет:

3. Запускаем тестовый прогон:

Второй вариант. Так как бэкап представляет собой дамп машины с конфигурационным файлом, то можно просто:

1. Cкопировать его куда-нибудь на ESXi сервер.

2. Исправить файл конфигурации машины (*.vmx), изменив поля имени и местоположения диска машины:

displayName = vCenterUpdate-restore
extendedConfigFile = «vCenterUpdate-restore.vmxf»
scsi0:0.fileName = «vCenterUpdate-restore-0.vmdk»
sched.swap.derivedName = «vCenterUpdate-ff0c3749.vswp»
Пути до файлов можно (и нужно) указывать относительно директории машины.

3. Через vSphereClient идём в хранилище:

и добавляем новую машину в список:

4. Если сервер восстановления другой, то в настройках машины меняем «Network Connection».

5. При первом запуске оно спросит, от куда нарисовалась машина, нужно ответить, что перенесли.

Если ответить, что клонировали — изменит уникальные данные, в том числе mac адрес сетевой карты.

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

Источник

Информационный портал по безопасности

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

Автор: admin от 19-08-2015, 05:39, посмотрело: 1 637

В этой статье я пошагово опишу настройку автоматического резервного копирования и пример восстановления виртуальных машин, работающих на платформе ESX(i) с помощью свободных скриптов ghettoVCB. Акцентироваться буду на версии ESXi 5.x, но эти же средства работают и на версиях 3.5-6.x, правда для ранних версий настройки несколько отличаются. Бэкап будет производиться на NFS сервер. Отчёт о работе будет направлен в почту. Во время бэкапа делается снимок (snapshot) виртуальной машины (в том числе и работающей), сохраняются VMDK диски машины и снимок удаляется.
Проект ghettoVCB отлично документирован, но в процессе внедрения появились нюансы, которые и вылились в эту инструкцию. Надеюсь, статья будет полезна начинающим администраторам.

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

Первым делом приготовьте NFS сервер по вкусу, куда будут производится бэкапы. В моём случае это FreeNAS (Freebsd 9.3) и ZFS dataset с включённой дедубликацией и сжатием, что существенно экономит место. Настройка на ESXi сервере производится по SSH от пользователя root. Можно и под другим пользователем с административными правами, но тогда не получится запустить скрипты для проверки из консоли. Приступим.

1. Для настройки необходим доступ на сервер по SSH, включаем через vSphere client:

2. Берём скрипты из github репозитория и помещаем содержимое на сервер. Обязательно ставим бит исполнения, иначе скрипты работать не будут:

5. Настраиваем cron на выполнение периодической задачи:

6. Перезапускаем cron:

Запустить тестовую проверку бэкапа машины с именем «vCenterUpdate» можно следующим образом:

Запустить в ручную для списка машин:

Каждая копия машин будет хранится в директориях, вида:

И представлять из себя диск машины в формате *.vmdk и файл конфигурации машины *.vmx.

Сохранение конфигурации сервера ESXi

Настройки ESXi, произведённые выше, будут жить до первой перезагрузки. Для сохранения конфигурации нужно сделать ещё ряд действий.

1. Добавим в загрузочный скрипт команды на изменение настроек cron-а:

2. Для сохранения настроек файрвола сделаем собственный VIB пакет и установим его на сервер. Для этого используем утилиту VIB Author. К сожалению, она только для 32-х битной архитектуры, поэтому мне пришлось воспользоваться lxc контейнером. При установке может страшно ругаться на зависимости вида:

Подготавливаем дерево директорий для сборки VIB пакета:

Таким образом можно собрать и зафиксировать и другие полезные настройки сервера.

4. И в завершение, запускаем в ручную бэкап настроек сервера ESXi:

Восстановление машины из резервной копии

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

1. Подключаем хранилище с бэкапом на целевой ESXi сервер по NFS, либо просто копируем туда данные по ssh.

3. Запускаем тестовый прогон:

Второй вариант. Так как бэкап представляет собой дамп машины с конфигурационным файлом, то можно просто:

1. Cкопировать его куда-нибудь на ESXi сервер.

2. Исправить файл конфигурации машины (*.vmx), изменив поля имени и местоположения диска машины:
Пути до файлов можно (и нужно) указывать относительно директории машины.

3. Через vSphereClient идём в хранилище:

и добавляем новую машину в список:

4. Если сервер восстановления другой, то в настройках машины меняем «Network Connection».

5. При первом запуске оно спросит, от куда нарисовалась машина, нужно ответить, что перенесли.
Если ответить, что клонировали — изменит уникальные данные, в том числе mac адрес сетевой карты.

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

Источник

Интересные факты и лайфхаки
Adblock
detector

Использование ghettoVCB для резервного копирования виртуальных машин VMware ESX / ESXi.

Использование ghettoVCB для резервного копирования виртуальных машин VMware ESX / ESXi.

Автор: Александр Прилепский
Дата: 28/02/2011

Копировать руками машину каждый раз, когда нужно внедрить какое-то оборудование, или просто для сохранения данных, это безумно неудобно. Вот для этого и была придумана технология автоматизированного бэкапа, написанная энтузиастами на скриптах perl: ghettoVCB.

Ниже выложен гайд по установке скриптов, а также приведены конфиги сохранения скриптов как локально, так и на удаленном сервере с использованием хранилища сетевой файловой системы (NFS).

В обоих вариантах нам необходимы программа для соединения с хостом VMware ESX по SSH, например Putty (http://www.chiark.greenend.org.uk/

Для начала, выкладываем файл ghettoVCB.tar.gz на Datastore, после чего заходим в Putty, коннектимся к серверу ESX и проделываем следующие действия:

# cd vmfs/volumes/
vmfs/volumes/ # сp ghettoVCB.tar.gz /
vmfs/volumes/ # cd /

# cd ghettoVCB
ghettoVCB # vi vmlist

Откроется файлик (пока еще не созданный) со списком тех машин, которые нужно забэкапить (пока еще пустой :). Для ввода и редактирования информации жмем “a”, чтобы применить настройки Esc. Чтобы выйти с сохранениями :wq чтобы без :q!

Вводим имена машин, далее вводим vi log и, ничего не изменяя в пустом файле, жмем :wq. Далее следует отконфигурить файл ghettoVCB.conf. Зайдя в неко командой vi (vi ghettoVCB.conf), мы увидим следующее:

Не стоит пугаться обилия параметров, все они легко настраиваются и имеют особую важность. Итак, по порядку: Параметр, определяющий директорию создания бэкапов. В моем случае, я указал: /vmfs/volumes/Datastore. Определяет формат забэкапленного диска, возможны варианты: zeroedthick, eagerzeroedthick, thin, 2gbsparse (см. типы дисков).

Определяет количество бэкапов на одну машину (каждый последующий будет удаляться скриптом). Если, например, скрипт (рассказывается ниже) будет бэкапить машины каждый час, то при указании числа 24, мы получим бэкапы каждый час на протяжении одного дня.

Определяет, будет ли машина выключаться перед бэкапом (enabled=1 disabled=0) (скрипт поддерживает бэкап при включенной машине).

Отключение дисков на время бэкапа (enabled=1 disabled=0).

При включенном предыдущем параметре, определяет количество времени (1 единица=60 секунд), прежде чем скрипт выполнит принудительное отключение диска.

Параметр, при включении которого забэкапленные файлы будут помещаться в архиве (enabled=1 disabled=0) (Внимание: это тестовый параметр для данной версии скрипта, мой совет его отключать, так как есть риск потери не только файлов бэкапа, но и файлов машины).

Формат диска машины (возможны: buslogic, lsilogic).

Параметры, отвечающие за снимки памяти, и если первый параметр “1”, то будет ли переведена машина на этот период в режим ожидания.

Все эти параметры нужны, если мы планируем создать директорию с бэкапами на удаленном сервере. Этими параметрами мы настраиваем доступ к NFS хранилищу (его местонахождение, директория на локально сервере и т.д.) Если создаем директорию бэкапа на том же DataStore, проигнорируем эти параметры.

Данный параметр отображает, сколько минут будет дано время на создания снапшота работающей машины, после чего скрипт будет отключен (если повременной, то только этот бэкап не будет создан, далее всё пойдет в штатном режиме). Данный параметр необходим, если по каким либо причинам машина не сделала снимок, прежде чем переходить в режим ожидания, для того, чтобы не потерять данные машины в режиме работы.

Следующие параметры будут отсылать логи на мэйл, при учете того, что в самом скрипте изначально прописаны данные smtp, pop и другие настройки.Данные параметры являются экспериментальными и не будут работать без дополнительных настроек. При желании отсылки логов на свой мэйл, требуется ознакомиться с основами perl и досконально изучить данную статью: http://www.waldrondigital.com/2010/05/11/ghettovcb-e-mail-rotate-logs-batch-file-for-vmware/

Мой совет – не заморачиваться.

Далее я привожу два вида настройки этих параметров без особых углублений (1 – локально, 2 – через сервер NFS)

Чтобы проверить данный скрипт можем запустить его разово. Для этого ознакомимся с параметрами запуска скрипта: Запустим, например, всё это со следующими параметрами: В логах, при правильно настроенном конфиге мы увидим примерно следующее:

Самое главное: это последние 3-4 строчки: ###### Final status: All VMs backed up OK! ######

Если видим такое, бэкап прошел успешно. Если видим крики об ошибках, читаем, где накосячили.

Основные типы ошибок:

После всего этого необходимо настроить режим создания бэкапов по времени. Для этого необходимо воспользоваться параметрами CronTab. Для этого проделываем следующее:

Откроется повременной запуск скриптов. На новой строчке впишем следующее:

Только первая строка (до символа % или до конца строки) поля команды выполняется командным интерпретатором. Другие строки передаются команде как стандартный входной поток. Любая строка, начинающаяся символом #, считается комментарием и игнорируется. Файл не должен содержать пустых строк.

Например, если мы хотим, чтобы бэкапы происходили, каждый день по будням в 2 часа 15 минут, наша строка должна выглядеть следующим образом:

Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.

08/04/2021: Вебинар ИТ-ГРАД: Обеспечение надежности и доступности данных для бизнеса в 2021 году
01/06/2021: Серия весенних вебинаров VMware продолжается

Вебинары VMC о виртуализации:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

Источник

Ghettovcb восстановление виртуальной машины

Администратор

Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1