Как сделать бэкап виртуальных машин в vmware esxi

Обновлено: 04.07.2024

Многие предприятия, а также домашние пользователи все чаще и чаще используют виртуальные машины для выполнения различного рода задач и повышения эффективности своей деятельности. Если раньше виртуальные машины применялись, в основном, энтузиастами, то теперь качество настольных и серверных платформ виртуализации позволило использовать их профессионалам в крупных масштабах. Возможность запуска нескольких виртуальных систем на одном физическом компьютере имеет множество достоинств, среди которых: экономия на аппаратном обеспечении, упрощение обслуживания и снижение затрат на электроэнергию в крупных датацентрах. Кроме того, важным достоинством виртуальных машин является их простая переносимость на другую физическую платформу и простая процедура их резервного копирования. Но также как и обычные операционные системы, виртуальные среды требуют высокого внимания к созданию резервных копий критически важных данных. При работе виртуальных машин в производственной среде предприятия многие компании планируют целые стратегии по архивации и восстановлению виртуальной инфраструктуры после сбоев, которые получили название Disaster Recovery.

Многие поставщики коммерческих платформ виртуализации предлагают корпоративным пользователям встроенные средства архивации виртуальных машин, такие как VMware Consolidated Backup (VCB) для платформы ESX Server. Однако в секторе SMB (Small and Medium Business), где число используемых виртуальных машин невелико, практически отсутствуют предоставляемые производителем платформ средства резервного копирования. Вследствие этого, небольшим компаниям приходится привлекать системных администраторов для написания различных скриптов, а также использования стандартных утилит операционных систем, обеспечивающих архивацию и восстановление файлов и папок с жизненно важными данными.

Общие сведения о резервном копировании данных

Обычная (полная) архивация (full backup)
При этом типе архивации создается полная копия всех сохраняемых данных. Процесс создания такой резервной копии достаточно продолжителен, однако требует не так много времени на восстановление, поскольку не требуется выполнять несколько задач восстановления. Полная архивация сбрасывает маркеры архивации файлов и папок, которые используются для определения того, какие файлы следует копировать. Эти маркеры применяются для проверки состояний файлов при добавочной и разностной архивации.
Добавочная архивация (incremental backup)
Этот вид архивации подразумевает копирование файлов и папок, которые изменились со времени создания последней резервной копии. Поэтому, если последовательно выполнить две добавочных архивации и не изменять файл между ними, в образ восстановления он добавлен не будет.
Разностная архивация (differential backup)
Такая архивация включает в себя все изменения, произошедшие в файлах и папках, со времени последней полной архивации. Соответственно, при двух последовательных разностных архивациях файл, который не изменился между ними, но изменился со времени последней полной архивации будет помещен в архив оба раза.

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

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

Поскольку, в основном, виртуальная машина представляет собой папку с файлами, то можно применять встроенные средства резервного копирования хостовой операционной системы, в случае если используется платформа виртуализации поверх хостовой системы такая как, например Microsoft Virtual Server или VMware Server. В Microsoft Windows для этих целей можно применять утилиту ntbackup. При использовании bare-metal платформ (класса «голое железо»), таких как ESX Server или Virtual Iron, необходимо воспользоваться средствами производителя системы виртуализации или продуктами сторонних разработчиков.

Кроме того, резервное копирование виртуальных машин может осуществляться путем создания образов гостевых систем с помощью программного обеспечения, такого как Acronis True Image. Стоит отметить также, что бывают ситуации, когда необходимо осуществить архивацию не всей виртуальной машины, а некоторых данных в гостевой системе. В этом случае, при написании пакетных сценариев архивации можно использовать утилиты для монтирования виртуальных дисков в хостовую систему. Для платформ VMware такой утилитой является приложение VMware Disk Mount.

Архивация и восстановление виртуальных машин на платформе VMware ESX Server

создание архивных копий виртуальных машин с различным типом архивации посредством специального прокси-сервера VCB Proxy Host, который снимает нагрузку по созданию резервных копий с production-сервера компании, где запущены виртуальные машины
не требует установки дополнительных агентов на ESX-серверы
предоставляет широкие возможности по интеграции с продуктами сторонних производителей средств резервного копирования, поддержка различных пакетов уже встроена в VCB
поддерживает архивацию на уровне файлов для гостевых систем Windows (можно создавать архивные копии отдельных файлов и папок внутри гостевой системы), а также архивацию на уровне образов виртуальных машин для любых гостевых ОС

Создание резервных копий виртуальных машин с помощью VCB происходит путем создания мгновенных снимков виртуальных машин без остановки их работы. VCB поддерживает также сети хранения SAN. Если виртуальные машины расположены на устройстве хранения SAN, процедура резервного копирования выглядит следующим образом:

Процедура копирования виртуальных машин с помощью VCB

Созданные в процессе работы снимки состояний виртуальных машин с помощью агента, расположенного на прокси-сервере VCB сохраняются на резервном носителе, откуда затем могут быть восстановлены в случае сбоя запущенной гостевой системы или порчи оборудования. В этом случае, бэкап-агент имеет прямой доступ к логическим единицам LUN (Logical Unit Number) в устройствах SAN. Для сетей SAN средства VCB поддерживают протокол Fibre Channel, а также ленточные носители для сохранения архивных копий. VCB тесно использует возможности VMware Tools, запущенных внутри гостевой системы, для создания резервных копий данных гостевой ОС.

Symantec Backup Exec 10.0
Symantec Backup Exec 10d
Veritas Netbackup 5.0
Veritas Netbackup 5.0 MP4
Veritas Netbackup 5.1
Veritas Netbackup 5.1 MP2
Veritas Netbackup 5.1 MP3
Veritas Netbackup 6.0
Tivoli Storage Manager v 5.2.1
Tivoli Storage Manager v 5.2.3
Tivoli Storage Manager v 5.3
EMC Networker v 7.0
EMC Networker v 7.1.x
EMC Networker v 7.2
EMC Networker v 7.3
CA BrightStor ARCServe r11
CA BrightStor ARCServe r11.1
CA BrightStor ARCServe r11.5
Commvault Galaxy v 5.9
Commvault Galaxy v 6.1

Программное обеспечение для создания резервных копий запускает сценарий подготовки к архивации, который выполняет следующие задачи:
- убеждается в том, что внутри гостевой системы не происходят операции чтения-записи в сохраняемые папки и файлы (только для гостевых ОС Windows)
- переключает виртуальную машину в режим «снапшота», создает снимок состояния виртуальной машины и делает его доступным для приложения, использующего VCB
- монтирует снимок виртуальной машины с SAN на прокси-сервер
Производится создание резервной копии снимка виртуальной машины на уровне образа, либо на уровне файлов и папок гостевой системы (полное, разностное или инкрементальное копирование).
ПО для архивации вызывает post-backup сценарий, который завершает резервное копирование (демонтирует снимки виртуальных машин с прокси-сервера и выводит виртуальную машину из режима снимка).

Подводя итоги можно сказать, что VMware Consolidated Backup представляет собой мощное средство для создания резервных копий виртуальных машин и дает возможность применять стандартное ПО резервного копирования, используемое в организации для создания архивных копий данных.

Резервное копирование с помощью Vizioncore esxRanger

Продукт esxRanger компании Vizioncore, контролируемой сейчас компанией Quest Software, на данный момент является одним из самых популярных решений для создания архивных копий виртуальных машин на платформе ESX Server. esxRanger не требует установки никаких дополнительных агентов на серверы ESX и создает архивные копии виртуальных машин с одного сервера либо группы серверов за счет интеграции с продуктом Virtual Center. Процесс создания резервных копий происходит на одном Windows-сервере, откуда архивные образы виртуальных систем могут быть сохранены на различных устройствах хранения в производственной среде организации.

Подключившись к VMware Virtual Center, при наличии соответствующих разрешений, можно выбрать отдельные виртуальные машины серверов датацентра для резервного копирования. Копируемые образы автоматически сжимаются при архивировании и распаковываются при восстановлении, что позволяет экономить время системным администраторам.

esxRanger интегрируется с VMware Consolidated Backup при использовании в сетях хранения данных SAN и позволяет создавать полные или дифференциальные копии виртуальных машин, а также отдельных файлов и папок в гостевых ОС Windows. Кроме того, в процессе резервного копирования esxRanger собирает различную информацию о метриках архивации (таких как время, затраченное на архивацию и восстановление), хранит ее в базе данных и позволяет использовать ее для построения трендов стратегии Disaster Recovery. В дополнение к этому, esxRanger имеет механизм политик, которые позволяют строить стратегию архивации данных на основе шаблонов и интегрировать его с другими компонентами ИТ-инфраструктуры организации, максимально снизив загрузку системных администраторов.

Создается точка сохранения виртуальной машины и сохраняется в базе данных.
При помощи VMware API происходит «разлочка» файлов виртуальных дисков на чтение (по умолчанию они заблокированы) и создание .REDO файлов, которые будут хранить изменения виртуальных дисков с момента точки сохранения.
Файлы виртуальных дисков сжимаются.
Происходит резервное копирование сжатых файлов и применение .REDO файлов к VMDK файлам виртуальных машин.
После того, как изменения будут применены, VMDK файлы возвращаются в исходное заблокированное состояние.
Системный администратор добавляет комментарии к архивным копиям виртуальных машин, содержащие указания на случай сбоя виртуальных машин.

В целом, esxRanger является удобным, надежным и простым в использовании средством создания архивных копий виртуальных машин в Virtual Infrastructure 3, которое обладает возможностями интеграции с VMware Consolidated Backup, что позволяет использовать его в сетях хранения данных SAN компаний любого масштаба.

Создание резервных копий виртуальных машин на платформе Microsoft Virtual Server

использование стандартных средств резервного копирования образов операционных систем, которые могут быть созданы агентами, работающими внутри гостевых систем, например, Symantec Backup Exec.
написание специализированные скриптов, которые сохраняют состояние виртуальной машины, копируют ее данные на резервный носитель и запускают виртуальную машину снова
применение служб теневого копирования тома (Volume Shadow Service, VSS), поддержка которых в Virtual Server появилась совсем недавно и пока не поддерживается производителями систем резервного копирования данных

Для того чтобы произвести архивацию запущенных виртуальных машин на платформе Virtual Server можно использовать ее COM-интерфейс, написав сценарий, к примеру, с помощью Visual Basic Scripting (vbs). При создании резервной копии виртуальной машины необходимо сначала перевести ее в сохраненное состояние (Saved State), затем скопировать ее файлы в заданное место и, после этого, снова запустить ее. Ниже приведен пример скрипта на vbs, который делает эти необходимые действия для копирования одной виртуальной машины. Его можно запускать по расписанию с помощью стандартного планировщика задач Windows. ' backupvm.vbs ' автор: John Savill ' использование : backupvm.vbs Option Explicit On Error Resume Next Dim objFSO, objVirtualServer, objVM, objSaveTask, objVHD 'Соединение с объектом файловая система set objFSO=CreateObject("Scripting.FileSystemObject") 'Соединение с Virtual Server set objVirtualServer = CreateObject("VirtualServer.Application") 'Поиск виртуальной машины set objVM = objVirtualServer.FindVirtualMachine(WScript.Arguments(0)) 'Сохранение состояния виртуальной машины set objSaveTask = objVM.Save 'Пауза для выполнения операции сохранения while not objSaveTask.isComplete WScript.Sleep 1000 wend 'Копирование виртуальных дисков и UNDO-дисков for each objVHD in objVM.HardDiskConnections If objFSO.FileExists(objVHD.HardDisk.file) Then 'Wscript.Echo objVHD.HardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.HardDisk.file, WScript.Arguments(1) End If If objFSO.FileExists(objVHD.undoHardDisk.file) Then 'Wscript.Echo objVHD.undoHardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.undoHardDisk.file, WScript.Arguments(1) End If Next 'Копирование vsv и vmc файлов objFSO.CopyFile objVM.File, WScript.Arguments(1) objFSO.CopyFile objVM.SavedStateFilePath, WScript.Arguments(1) 'Запуск виртуальной машины objVM.Startup

Этот скрипт необходимо использовать следующим образом:

C: emp>cscript backupvm.vbs

Нужно отметить, что компания Microsoft официально не поддерживает такой процесс создания резервных копий, поскольку целостность виртуальной машины, скопированной в сохраненном состоянии, может быть нарушена из-за того, что часть ее памяти не сохраняется в этом случае в файлах vsv и vhd.

Использование службы Volume Shadow Service

Поддержка служб VSS появилась в недавно вышедшем релизе Virtual Server 2005 R2 SP1. Использование служб теневого копирования в Virtual Server предполагает создание резервных копий запущенных виртуальных машин за счет создания образов, что должно существенно упростить и ускорить процедуру резервного копирования и восстановления. Однако недостаточно, чтобы программное обеспечение для резервного копирования поддерживало VSS, необходимо также, чтобы оно поддерживало еще и новый Virtual Server VSS Writer Service (VS Writer), обнаружить поддержку которого, на данный момент, не удалось ни у одной из систем архивации. В соответствии с информацией Microsoft, средства резервного копирования могут использовать VS Writer для архивации и восстановления виртуальных машин следующим образом: они нотифицируют Virtual Server о том, что процесс архивации начался, Virtual Server отвечает на это созданием снимка виртуальной машины, после чего начинается процесс копирования. На данный момент утилита NTBackup также не поддерживает этот механизм.

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

Компания XenSource, занимающаяся поддержкой Open-Source проекта Xen, а также распространением коммерческой платформы виртуализации XenEnterprise, предлагает не так много вариантов архивации виртуальных машин на платформе Xen. Один из них приведен ниже с использованием устройств хранения данных в файловой системе NFS (Network File System).

Хост XenServer (в примере процедуры бэкапа его IP 192.168.1.10)
Компьютер, используемый в качестве сервера хранения архивных копий (в примере его IP 192.168.1.1)
Виртуальная машина XenVM (в примере ее IP 192.168.1.12)

Установите NFS сервер путем добавления в файл /etc/exports следующей строчки:
/ *(rw,sync,no_root_squash)
На хосте XenServer пропишите в файл /etc/xen/xmexample1 следующее:
kernel /boot/xenkernel
name = "ExampleDomain"

Заключение

Составление и реализация плана резервному копированию и восстановлению после сбоев (Disaster Recover Plan) наиболее важных серверов и рабочих станций организации является необходимой составляющей ее деятельности. Виртуальные машины, даже больше чем физические, требуют высокого внимания к архивации данных, поскольку обычно несколько виртуальных систем консолидировано на одном физическом хосте. Ведущие производители платформ виртуализации стремятся к тому, чтобы предоставить мощные и удобные средства резервного копирования, однако на данный момент это удалось только компании VMware. Стратегию резервного копирования можно проводить двумя способами: один из самых простых путей, делать это в рамках стандартной стратегии по архивации данных в ИТ-инфраструктуре компании, за счет установки в гостевых системах агентов резервного копирования и создания образов. Другой, более удобный и быстрый путь — использование встроенных средств платформ, таких как VMware Consolidated Backup или написание скриптов системными администраторами. В любом случае, никогда нельзя забывать, что отказ оборудования или иные форс-мажорные обстоятельства не должны существенно влиять на критически важную деятельность компании.

В этой заметке будет рассмотрено, как создать резервную копию виртуальных машин с помощью скрипта 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’ и, как показано на скриншоте:

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

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

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

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

По окончанию редактирования последовательно нажмите: 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”, то будет ли переведена машина на этот период в режим ожидания. Первоначально параметр добавлен с целью отладки, а сама опция никак не используется при восстановлении ВМ: любая виртуальная машина, будь то включенная (online), или выключенная (offline), при восстановлении из бэкапа окажется в сосотянии offline.

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мотрим список активных ВМ и добавляем необходимые в список:

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

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

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

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

из start.sh можно убрать. Разрешаем запуск:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Troubleshooting.

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

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

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

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

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

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

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

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

Есть два основных способа резервного копирования, это традиционное резервное копирование с помощью агента усыновленного в виртуальной машине и безагентное резервное копирование , когда резервное копирование выполняется на уровне взаимодействия VCenter или ESXi с системой резервного копирования. Желательно, как можно меньше использовать агенты для резервного копирования гостевых ОС. Системы резервного копирования должны переходить непосредственно на уровень виртуализации. При использовании этого метода гостевая ОС не знает о процессе резервного копирования и не тратит ресурсы хоста. Это также намного эффективнее, поскольку сервер резервного копирования может монтировать виртуальный диск виртуальных машин непосредственно из хранилища данных хоста. Для этого VMware разработала специальные API-интерфейсы для приложений резервного копирования VMware vStorage API for Data Protection (VADP), которые позволяют приложениям резервного копирования напрямую взаимодействовать с хостами и устройствами хранения.

VADP предлагает более эффективный доступ к файлам виртуального диска. Архитектура виртуализации предоставляет множество уникальных способов резервного копирования виртуальных машин по сравнению с традиционными физическими средами. Поэтому, прежде чем приступить к созданию плана резервного копирования и аварийного восстановления , необходимо тщательно изучить те возможности, которые предоставляет виртуализация.

СОВЕТЫ ПО РЕЗЕРВНОМУ КОПИРОВАНИЮ ВИРТУАЛЬНЫХ МАШИН VMWARE

По возможности, не создавать резервные копии виртуальных машин на уровне гостевой ОС
Еженедельно делать полное резервное копирование
Использовать стандартные API-интерфейсы vStorage
Не экономить на ресурсах резервного копирования. Резервное копирование может значительно замедлиться, если у сервера резервного копирования нет достаточных ресурсов
Помнить, что Snapshots (моментальные снимки) не являются резервными копиями
Не забывать делать резервную копию настроек хостов и vCenter Server
Выполнять резервное копирование vCenter Server отдельно от резервного копирования виртуальных машин
При групповом бэкапе ВМ, объединять ВМ в группы по одинаковым параметрам (файловый / сервер приложений / баз данных)
Выполнять Off-host backups для снижения нагрузки на ESX сервер.

CИСТЕМЫ РЕЗЕРВНОГО КОПИРОВАНИЯ VMWARE

Резервное копирование VMware

Начиная с версии 6.7, VMware прекратила поддержку VMware vSphere Data Protection, оставив задачу по резервному копированию на специализированных производителей систем резервного копирования.

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

ТЕХНОЛОГИИ и ФУНКЦИИ РЕЗЕРВНОГО КОПИРОВАНИЯ VMWARE

Changed Block Tracking

Changed Block Tracking (CBT) – это эффективная технология резервного копирования. После создания полной резервной копии виртуальной машины Changed Block Tracking позволяет системам использовать встроенную в VMware технологию копирования «измененных блоков» и хранить карту измененных блоков в самом VMDK. Изменение блоков в виртуальной машине с низкой активностью может быть незначительными, что позволяет проводить резервное копирование за очень короткое время и без высокой нагрузки на оборудование (в отличии от полного бэкапа).

Резервное копирование приложений и баз данных

Большинство организаций используют важные для бизнеса приложения поверх баз данных или других приложений, требующих согласованности транзакций. Microsoft SQL Server и Microsoft Exchange Server являются двумя примерами приложений, которые требуют согласованности транзакций. Резервные копии VMware, которые используют резервные копии с учетом приложений, взаимодействуют с VSS Microsoft, чтобы сбросить все данные в памяти или ожидающие операции дискового ввода-вывода на диск, чтобы резервные копии включали все транзакции в ходе резервного копирования. В противном случае резервное копирование может быть непоследовательным, когда дело доходит до базы данных приложения, и требуются дополнительные шаги, такие как воспроизведение журналов, с целью привести базу данных в согласованное состояние.

Транспортные режимы передачи данных

Применение для резервного копирования и передачи файла VMDK на хост следующие транспортные режимы:

Hotadd backup - позволяет использовать виртуальную машину в качестве прокси-сервера для передачи данных
SAN – позволяет передавать VMDK по SAN напрямую на сервер резервного копирования не нагружая ESX / ESXi хост.

Off-host backup

Off-host backup позволяет перенести процесс резервного копирования моментальных снимков одного или нескольких томов с хоста на сервер резервного копирования. Для обеспечения согласованного Off-host backup необходима встроенная поддержка поставщика аппаратных снимков Microsoft VSS и прямой доступ к хранилищу.

Репликация резервной копии

Возможность репликации резервных копий очень важная и полезная функция в случаи, если у вас произошел полный отказ основного ЦОДа и вы потеряли производственные данные, а также резервные копии. Однако, если у вас есть копия данных резервного копирования в другом ЦОДе или в облаке, это обеспечивает отказоустойчивость данных резервного копирования и виртуальных машин соответственно.

Репликация виртуальных машин

Настройка репликации виртуальных машин позволяет обеспечить более высокую отказоустойчивость в случаях сбоя основного оборудования. Виртуальные машины-реплики - это точные копии виртуальной машины, созданные в отдельной среде VMware vSphere, расположенной на другом оборудовании. В идеале, это географически удаленное от производственной площадки местоположение. Наличие реплики виртуальной машины VMware позволяет просто и быстро «переключаться» с основного ЦОДа на резервный только лишь, запустив реплики виртуальных машин и переместив сетевой трафик или записи DNS в новое сетевое местоположение.

Шифрование резервных копий

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

Проверка резервной копии

Резервная копия актуальна только в том случае, если ее можно восстановить. Очень часто происходит, что администраторы обнаруживают, что их резервные копии были повреждены или не содержали данных, которые, как они предполагали, были скопированы. Проверка резервных копий виртуальных машин является важной рекомендацией по резервному копированию VMware. Возможность автоматизировать проверку резервных копий виртуальных машин - это надежный способ быть уверенным, что это сделано. Использование «screenshot verification» позволяет организациям иметь автоматизированное решение для проверки критически важных для бизнеса резервных копий.

В современных, быстро развивающихся ИТ-технологиях организации должны автоматизировать процессы и процедуры резервного копирования, чтобы идти в ногу с растущими потребностями. Защита данных, безусловно, является одной из повседневных задач, которая выигрывает от автоматизации. Многие производители систем резервного копирования предоставляю API-интерфейсы, позволяющие взаимодействовать с уже существующими в организации инструментами оркестровки (управления) виртуальной среде. Кроме того, цепочка заданий позволяет настроить рабочие процессы в определенном порядке и времени.

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

В этой статье вы узнаете, как создавать резервные копии и научитесь восстанавливать конфигурацию VMware ESXi 6.5 при помощи командной строки ESXi.

Резервное копирование конфигурации хоста ESXi

Поскольку в своих примерах мы будем использовать командную строку ESXi, необходимо будет подключиться к хосту при помощи SSH консоли. Если вы не знаете, как включить SSH, то вам следует перейти по ссылке и ознакомиться с информацией: Как включить SSH в VMware ESXi 6.x

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

Результат работы команды представлен на рисунке ниже:

Резервная копия настроек хоста ESXi будет сохранена в каталоге /scratch/downloads .

Как всем известно, хранить резервную копию на том же самом устройстве является неверным решением, поэтому следует перенести созданный архив в другое место. Сделать это можно при помощи веб-браузера, введя URL-адрес который вернула вам команда vim-cmd. Вам только нужно будет заменить * на IP-адрес вашего хоста ESXi.

В качестве альтернативы вы можете использовать для переноса архива утилиту WinSCP или другую SSH утилиту. Чтобы узнать, как именно это сделать вам следует пройти по ссылке: Как скопировать файл из VMware ESXi 6.5 в Windows или наоборот

Восстановление конфигурации ESXi

Чтобы восстановить конфигурацию ESXi из резервной копии, вам потребуется установить ту же версию и билд ESXi, которая была установлена на старом оборудовании (Как узнать версию ESXi с помощью Web Client). После установки вам следует настроить на хосте сеть, все это необходимо для того, чтобы вы смогли подключиться к устройству при помощи протокола SSH.

После подключения вам необходимо перенести архив с резервной копией /tmp/configBundle.tgz на хост, используя утилиту для передачи данных (подойдет WinSCP).

После того, как вы это сделаете, останется только выполнить следующие команды:

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

После перезагрузки хоста, загрузиться сохраненная ранее конфигурация. Останется только вывести хост из режима обслуживания.

В этой статье мы освоили способ резервного копирования и восстановления конфигурации хоста VMware ESXi 6.5 с помощью командной строки ESXi. Следует еще раз отметить, что для восстановления резервной копии версия хоста должна в точности соответствовать версии сделанной ранее резервной копии. Необходимо помнить, что при каждом обновлении хоста требуется обновлять резервную копию.

12.04.2018

VMWare

комментария 3

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

Самый удобный и простой способ бекапа настроек хостов ESXi– воспользоваться функционалом Host Profiles, однако этот функционал доступен только для Enterprise Plus и нами подробно рассматриваться не будет. Мы остановимся на управлением резервным копированием с помощью команд CLI.

Резервное копирование/восстановление ESXi с помощью PowerCLI

На наш взгляд, самый простой способ создания резервной копии хостовой системы VMware ESXi и восстановления из нее – воспользоваться специальными командлетами PowerCLI:

Get-VMHostFirmware – позволяет создать резервную копию конфигурации ESXi
Set-VMHostFirmware – позволяет восстановить конфиг гипервизора из бэкапа

Примечание. Естественно, что на машине администратора должен быть установлен Powershell и расширение vSphere PowerCLI.

Откройте консоль PowerCLI, или запустите ее из PowerShell, выполнив команду:
Подключитесь к нашему серверу ESXi (или vCenter):

Примечание. Каталог C:\BackupESXi должен быть создан заранее. Примечание. 1. Необходимо учитывать, что восстановление конфигурации ESXi из бэкапа должно производиться на точно такую же версию ESXi, в противном случае результат не гарантирован.2. Если в указанном каталоге хранятся бэкапы нескольких северов, скрипт сам выберет нужный файл бэкапа по имени.
Совет. Если командой Connect-VIServer вы установите сессию с сервером VMware vCenter, то следующей командой можно создать резервные копии всех серверов ESXi, подключенных в данный vCenter:

Бэкап/восстановление ESXi с помощью vSphere CLI

Для резервного копирования/восстановления конфигурации ESXi можно воспользоваться возможностями vCLI, например, с помощью клиента vCLI для Windows или Linux, или же через vMA Appliance.

Для управления резервными копиями в vCLI существует специальная команда: vicfg-cfgbackup

Примечание. Команда vicfg-cfgbackup доступна только на сервера ESXi, использовать ее при подключении к серверу vCenter Server не удастся.

После выполнения команды файл esx05-backup можно скачать на свой компьютер, например, по WinSCP.

Процедура восстановления ESXi в случае падения сервера следующая:

Установите на сервер ту же самую версию ESXi, бэкап которой был создан. Выполните первоначальную настройку сервера (имя, ip адрес management сети и т.п.)
Скопируйте на север имеющийся файл с бэкапом.

Примечание. Все запущенные виртуальные машины должны быть выключены. Совет. В том случае, если версии ESXi на хосте и в бэкапе отличаются, можно попробовать принудительно перезаписать конфигурацию, воспользовавшись ключом -f (force)

Резервное копирование в бесплатной версии ESXi

Указанные выше способы резервного копирования будут работать только в коммерческих (платных) версия ESXi. В том случае, если вы используете бесплатную версию гипервизора VMware (vSphere Hypervisor), имейте в виду в ней есть ограничения, урезающего возможности CLI. Дело в том, что vSphere API в vSphere Free Hypervisor, работает в режиме чтения (read-only). Это означает, что хотя вы и сможете создать «бэкап» текущей конфигурации бесплатного ESXi, но восстановить этот бэкап на бесплатную версию ESXi-сервера, не получится.

Сей неприятный факт обходится довольно просто: при свежей установке ESXi вам может быть предоставлен тестовый (trial период) 60 дней, в течении которых вы можете пользоваться всем функционалом ESXi, а команды vSphere CLI будут отрабатывать в режиме чтения и записи, что означает возможность восстановления из имеющегося бэкапа.

Читайте также: