Как копировать виртуальные машины esxi с vim. Сравнение решений для backup виртуальных машин от Veeam, Acronis и Symantec. Восстановление VMware из интерфейса Bweb Management Suite

Рассмотрим и сравним два способа резервного копирования виртуальных машин VMware.

Исходные данные

Тестовый стенд представляет собой два гипервизора ESXi на сервере Fujitsu Primergy BX2560 M2 подключённые по SAN (два порта по 8 Gbit/s) и LAN (два порта по 10 Gbit/s). Версия ESXi и VSCA 6.5. Для ESXi диски презентованы системой хранения данных Fujitsu ETERNUS DX8700 S2. В качестве системы хранения бэкапа используем EMC Data Domain 6300, подключенный по SAN (четыре порта по 8 Gbit/s). Для выполнения backup, в целях экономии времени, воспользуемся готовым инструментом Backup Exec, сервер управления системы установлен на физическом сервере HP ProLiant BL460c Gen8 и так же имеет подключение к сети по SAN и LAN двумя портами.

Для тестирования создано три виртуальных машины: VM1 (146Gb), VM2 (157GB) и VM3 (284Gb). Процедура тестирования будет выглядеть следующим образом: выполним три раза FULL Backup каждой системы, после этого вычислим среднюю скорость резервного копирования(Gb/min) для каждого способа.

Система Backup Exec имеет четыре способа получения доступа к данным виртуальной машины, для физического сервера это SAN, LAN (NBD), NBDSSL и четвертый, если сервер Backup Exec установлен на виртуальной машине, HotAdd. Протестируем вариант, когда Backup Exec установлен на отдельном физическом сервере, сравним плюсы и минусы выполнения бэкапа по SAN и LAN.

Настройка Backup Exec достаточно проста и состоит из следующих шагов:

Выбрать существующее или создать новое задание на выполнение бэкапа виртуальных машин
Открыть свойства этого задания
Перейти на вкладку Virtual Machines > подраздел VMware
Отметить нужный нам способ подключения (допустимо активировать сразу все четыре способа и выставить их очередность использования)

СПОСОБ ПЕРВЫЙ: РЕЗЕРВНОЕ КОПИРОВАНИЕ ВИРТУАЛЬНЫХ МАШИН ПО SAN

Для того, чтобы Backup Server мог выполнить бэкап виртуальных машинESXi по SAN, ему необходимо в первую очередь презентовать те же LUN (-ы), которые были презентованы ESXi. В этом случае Backup Server, используя vStorage API, запрашивает информацию у vCenter, в каком LUN находится VMDK виртуальной машины, делает моментальный снимок (snapshot) диска и забирает его по SAN.

В результате этого эксперимента средняя.

СПОСОБ ВТОРОЙ: РЕЗЕРВНОЕ КОПИРОВАНИЕ ВИРТУАЛЬНЫХ МАШИН ПО LAN (NBD)

В этом режиме Backup Server запрашивает у vCenter сведенья о том на каком ESXi находится нужная нам виртуальна машина, делается моментальный снимок и выполняет его передачу по локальной сети с ESXi сервера на Backup Server.

В результате второго эксперимента средняя.

ВЫВОДЫ, ПЛЮСЫ И МИНУСЫ

Если строить с нуля современную инфраструктуру используя сетевое оборудование с пропускной способностью 10 Gbit/s, то применение бэкапа в режиме подключения к данным по локальной сети (NBD) скорее всего, по затратам и времени окажется более эффективно. В случае, когда сеть между ESXi и Backup Host составляет 1 Gbit/s, а необходимое оборудование для подключения по SAN уже есть, то первый способ будет более эффективный и быстрый.

Основной плюс выполнения бэкапа по SAN заключаются в том, что передача данных не загружает локальную сеть и выполняется на достаточно высокой скорости, но в случае 10 Gbit/s сети это уже не является столь явным преимуществом, поскольку даже при сравнительно больших объемах информации окно резервного копирования занимает не значительное время.

Основной плюс выполнения бэкапа по LAN, это возможность использования более дешевого оборудования в качестве системы хранения данных. И как показал тест, построение современной сети на 10 Gbit/s оборудовании обеспечит более быстрый бэкап, чем 8 Gbit/s SAN.

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

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

Используемая в статье информация взята из официальных источников.

Небольшой тест:
Локальная сеть - гигабит.
На локальное хранилище (аппаратный RAID 10 из 4 дисков 10К) - «time dd if=/dev/zero of=/vmfs/volumes/datastore/temp bs=1M count=1K» 8 секунд.
На «linux» хранилище (программный RAID 0 из 3 дисков 7,5К) - «time dd if=/dev/zero of=/vmfs/volumes/linbackup/temp bs=1M count=1K» 12 секунд.
На «windows» хранилище (аппаратный RAID 5 из 10 дисков 10К) - «time dd if=/dev/zero of=/vmfs/volumes/winbackup/temp bs=1M count=1K» 1 минута 44 секунды (сам в шоке).

Результаты говорят сами за себя. Да, на win-хранилище RAID 5, но врядли он один виноват в таком результате.

С СХД разобрались, теперь надо автоматизировать резервное копирование. Лучшим бесплатным средством является скрипт ghettoVCB , чтобы им воспользоваться, надо получить доступ к хосту ESXi по SSH. Как оказалось есть очень простой способ включения и выключения доступа прямо из vShere Client: Configuration > Software > Security Profile > Properties… > Remote Tech Support (SSH) > Options… > Start или Stop. По этим скриншотам думаю будет нагляднее:

Скачиваем последнюю версию скрипта. Можно пойти «тру» путём сделать как написано на страничке скрипта в секции «Setup:», но я поступил проще - распаковал архив у себя на компьютере, вместо редактирования конфигурационного файла - отредактировал сам скрипт, скопировал его на локальное хранилище (через «Browse Datastore»).

Вот основные параметры:

VM_BACKUP_VOLUME - путь к папке бэкапов, в моём случае /vmfs/volumes/linbackup
DISK_BACKUP_FORMAT - формат диска, thin для бэкапов подходит лучше всего
VM_BACKUP_ROTATION_COUNT - количество хранимых бэкапов (для каждой виртуальной машины), у меня 2
ADAPTER_FORMAT - тип адаптера, у меня lsilogic

Остальные параметры можно и не править, но если интересно - на страничке скрипта все параметры подробно описаны, правда на английском, почти все параметры расписаны по русски.

Итак, скрипт скопирован на локальное хранилище, подключаемся по ssh, переносим скрипт куда нибудь ближе к корню, например в /ghettovcb/ghettovcb.sh, если вам не нужно бэкапить все виртуальные машины - необходимо создать файл со списком бэкапируемых виртуалок:
cd /ghettovcb
vi vmlist
жмём «a» вписываем имена виртуалок, каждое на новой строке, нажимаем «esc» и чтобы сохранить изменения ":wq" или чтоб выйти без сохранения ":q"

Переносы строк должны быть "\n", при переносах "\r\n" скрипт будет выдавать ошибку, поэтому не стоит создавать список в блокноте, с последующим копированием на хранилище, если вы ни разу не пользовались Notepad+ или EmEditor и не знаете что такое "\n" и "\r\n" - лучше создавайте список в vi.

Пробуем запустить скрипт:

./ghettovcb.sh -f ./vmlist -l ./log.txt

./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt
Скрипт отрабатывает, выдавая много информации, если в конце вывода видим "###### Final status: All VMs backed up OK! ######" значит всё хорошо, иначе - читаем log.txt и разбираемся что сделали не так.
Теперь надо создать расписание для бэкапов.
cd /var/spool/cron/crontabs
chmod u+w root
vi root
жмём «a», пишем расписание, только учтите - время указывается в UTC, т.е. для Москвы это локальное время минус три часа
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
или если вы создали файл конфигурации
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -g /ghettovcb/ghettovcb.conf -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
жмём «esc» и сохраняемся ":wq"
в заключении
chmod u-w root

Теперь ежедневно в 20:00 по UTC (в 23:00 по Москве) будет запускаться скрипт, логи о его выполнении будут сохранятся на хранилище в папке logs, отдельный лог на каждый день.

По логам у меня на бэкап уходит примерно 4 часа, посчитал скорость - примерно 4ГБ в минуту, т.е. примерно 70МБ в секунду, весьма не плохо. Хранилища в 2,7ТБ хватает на хранение двух копий каждой виртуалки, этого вполне достаточно, плюс остаётся свободное место, а оно нужно, т.к. сначала делается третья резервная копия и только после её создания удаляется самая старая копия.
Ну и ещё один камень в огород «windows» хранилища - пробовал делать бэкапы скриптом на него, storage просто отваливался, ну и собственно скрипт завершался с ошибкой. Понимаю, что всё дело в неверной настройки записи по NFS, но настройки были по умолчанию и разбираться в «тюнинге» не очень то и хотелось.

Эксперимент прошёл удачно, можно закупать сервер с хорошими дисками, планируется RAID 10 на 5ТБ, этого должно с запасом хватить и на будущие виртуалки.

Теги: vmware, vsphere, esxi, backup, резервное копирование

Существует отличный бесплатный скрипт для резервного копирования виртуальных машин на VMWare ESXi сервере, причем он работает на free версии ESXi 4 и 5 версий без установки всяких дополнительных приблуд типа VMA и т.п. Проблема только в том, что инструкция там не совсем точная, поэтому я долго возился с этим скриптом, чтобы он все-таки заработал именно в автоматическом режиме…

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

Сначала качаем скрипт по ссылке выше и заливаем на сервер, заливать нужно прямо в архиве! Проще всего это сделать через vSphere Client. У меня на сервере два диска — на одном работают машины, а на другом лежат всякие iso-образы и сами бэкапы. Называются диски соответственно datastore1 и datastore2. Все бэкапы, скрипт и конфиги лежат в папке backup. Еще обратите внимание, что названия файлов и папок регистрозависимые, поэтому если папка называется backup , а вы пишите в скрипте Backup , то работать не будет!

Заливаем архив со скриптом сюда /vmfs/volumes/datastore2
Дальше в SSH cd /vmfs/volumes/datastore2 — переходим в директорию со скриптом
Распаковываем скрипт из архива tar -zxvf имя_файла_архива.tar.gz
Через vSphere переименуйте распакованную папку в нечто попроще, например просто backup
Теперь зайдем в эту папку — cd backup
Создадим внутри нее папку для хранения индивидуальных конфигов mkdir BackupConfig
Теперь в BackupConfig закинем нужные индивидуальные конфиги для машин, если они не нужны и все машины надо бэкапить с одинаковыми настройками, можно оставить ее пустой
Поправить через редактор vi переменные в конфигурационном файле, главное это пути бэкапа, т.е. первую строку меняем на такую: VM_BACKUP_VOLUME=/vmfs/volumes/datastore2/backup , ну а далее сами смотрите что вам еще нужно — vi ghettoVCB.conf
Создать скрипт StartBackup.sh (2 строки) — vi StartBackup.sh
2ю строку, где вызов самого скрипта, можете переделать под себя
cd /vmfs/volumes/datastore2/backup
./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log
Выполнить chmod +x ghettoVCB.sh
Выполнить chmod +x StartBackup.sh

1 этап завершен! Теперь если запустить StartBackup.sh , то начнется бэкап. На время отладки можете поменять 2ю строку на что-то типа вот этого ./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log -d dryrun — это позволит запустить скрипт и отследить ход выполнения без самого копирования дисков. Чтобы резервное копирование проводилось более эффективно и быстро, рекомендую в настройках выставить тип диска thin .

Конфигурирование Cron (для автоматического запуска скрипта)

Дать разрешение на запись в файл chmod +w
Добавляем через vi строку в /var/spool/cron/crontabs/root
15 0 */3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 00:15 ночи каждые три дня. У меня часовой пояс +4 Москва, т.е. на самом деле скрипт запускается в 4:15 утра, это будет видно по дате изменения лога через vSphere. Само собой время и периодичность можете выбрать другие.
Теперь нужно выполнить две команды, чтобы перезапустить cron
kill $(cat /var/run/crond.pid)
crond
Добавить с помощью vi 3 строки в самый конец файла /etc/rc.local
Это нужно, потому что после перезагрузки сервера содержимое файла из 2го пункта с запуском нашего скрипта будет восстановлено до предыдущего состояния, поэтому в rc.local указываем, что после перезагрузки нужно выполнить следующие команды — остановка cron, добавление строки для автоматического запуска скрипта и запуск cron.
/bin/kill $(cat /var/run/crond.pid)
/bin/echo «15 0 */3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh» >> /var/spool/cron/crontabs/root
crond
Теперь выполним выполнить команду /sbin/auto-backup.sh , чтобы удостовериться, что все наши изменения сохранились.

Небольшое пояснение — почему нужно создавать скрипт StartBackup.sh , а не просто взять и его содержимое поместить в /var/spool/cron/crontabs/root ? Существует какое-то ограничение на размер этого файла и часть строк в нем просто не будет работать, хотя можете попробовать сделать и так, сначала у меня работало, но потом, видимо, вышли какие-то патчи и перестало. Более того, это просто удобнее — если потребуется изменить расписание резервного копирования, то вы просто правите файл StartBackup.sh и не нужно танцев с бубном вокруг cron с его перезапуском и внесением тех же изменений в /etc/rc.local .

PS: Время идет, все меняется, сам скрипт меняется, ESXi5 уже вышел, так что где-то, что-то может уже и не работать 🙂

Приложение: Синтаксис cron

Команда cron выглядит вот так:

1 2 3 4 5 /vmfs/volumes/datastore2/backup/StartBackup.sh

Где,
1: Минуты (0-59)
2: Часы (0-23)
3: Дни (0-31)
4: Месяцы (0-12 )
5: День недели (0-7 )

Несколько примеров:

Запуск в 5 минут первого ночи, каждый день
5 0 * * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 2:15 каждый первый день месяца
15 14 1 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 22:00 каждый рабочий день
0 22 * * 1-5 /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 23 минуты после полуночи и далее каждые два часа (2:23, 4:23… и т.д.), каждый третий день
23 0-23/2 * * */3 /vmfs/volumes/datastore2/backup/StartBackup.sh

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

Veeam BackUp & Replication 5

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

Data Recovery с поддержкой VCenter Server

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

Данное решение работает как с VCenterServer, так и без него, но будет отсутствовать возможность настройки бэкапа по времени. Мы рассмотрим все основные возможности чуть ниже, когда будем сравнивать все продукты.

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

Также с недавнего времени выпускает средства для бэкапа в виртуальных средах. Кроме того, Symantec - единственное из всех решений бэкапа использует технологию V2P (конвертирование виртуальной среды на физические серверы). Правда, Vcenter обладает такой технологией, но уже не в рамках технологии резервного копирования

Но на этом возможности Акронис не ограничиваются. Компания Acronisвключила в пакет Acronis Backup& Recovery 10 AdvancedServer VirtualEdition еще одну функцию, это консолидация серверов для перевода систем с физических на виртуальные платформы, причем со встроенным планировщиком заданий. В итоге имеем, что данная программа выполняет 2 основных функции:

Экстренное восстановление систем

Консолидация серверов

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

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

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

Создание раздела Acronis Secure Zone на том же сервере ВМ, что позволяет восстановить машину за короткий срок, причем этот раздел будет защищен режимом дедупликации на другом сервере

Если резервное копирование - это одна из наших основных целей независимо от цены нам, несомненно, стоит выбирать между решениями компаний Veeam, Acronisили Symantec. Оба эти продукта являются лидерами резервного копирования и хранения данных, а также обладают рядом индивидуальных преимуществ.

В выборе между этими технологиями необходимо провести черту по нескольким разграничениям:

Тип лицензирования

Характеристики

Объем и периодичность бэкапа

При разном типе лицензирования стоит решить, какой подходит больше всего нам. Если у нас мощные серверы с большим количеством сокетов под процессоры, стоит склоняться в пользу Acronisи Symantec. Если у нас много слабых серверов с небольшим количеством сокетов, лучшим вариантом будет Veeam.

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

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

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

Бесплатный backup (резервное копирование) виртуальных машин на базе VMware ESXi

Для VMware ESXi вопрос резервного копирования виртуальных машин стоит особо остро. Дополнительное бесплатное ПО неудобно в использовании из-за ограниченного функционала. Поэтому наш backup будет основан на бесплатном скрипте — ghettoVCB . Это самый лучший вариант существующих скриптов, хотя у него такое забавное название и всего проекта в целом — www.virtuallyghetto.com, автор William Lam . Его алгоритм — создание снапшота и клонирование VM.

Для настройки полноценной схемы резервного копирования нам потребуется:

NFS сервер для хранения файлов;
подключение по SSH к ESXi;
скрипт ghettoVCB.sh добавляется на сервер ESXi (в корень или папку будущего бекапа). Это делается через SFTP любым удобным для вас способом, например, FileZilla;
даем права на выполнение скопированного скрипта;

Теперь более подробно остановимся на каждом из пунктов. Для повышения быстродействия и отказоустойчивости файлового сервера/сервера резервного копирования лучше использовать RAID10. Предпочтительны в данном случае являются ОС Linux (Debian, Ubuntu, «удобная вам») и файловая система XFS , т.к. в такой конфигурации скорость записи (основной приоритет для быстрого бекапа) будет выше.

Уже имеется у нас, но также можно все выполнить и в vSphere client : Configuration > Software > Security Profile > Properties… > Remote Tech Support (SSH) > Options… > Start или Stop.

Переходим к конфигурации скрипта ghettoVCB.sh , основные параметры, которые нам понадобятся:

VM_BACKUP_VOLUME - путь к папке бэкапов, в моём случае /vmfs/volumes/datastore1/backup
DISK_BACKUP_FORMAT - формат диска, thin для бэкапов подходит лучше всего
VM_BACKUP_ROTATION_COUNT - количество хранимых бэкапов (для каждой виртуальной машины), у меня 3
ADAPTER_FORMAT - тип адаптера, в моем случае — lsilogic

Остальные параметры отвечают за копирование файлов по сети и e-mail уведомления. Подробнее параметры конфигурации описаны на сайте разработчика.!

Если необходимо копировать не все виртуальные машины, то создается файл со списком VM, включенных в бекап. Создаем такой файл в vi:

переходим в папку со скриптом — cd /ghettovcb или backup
vi vmlist
нажимаем «a» вписываем имена VM (каждое имя на новой строке)
нажимаем «esc» и чтобы сохранить изменения — «:wq» (без сохранения «:q»)

Запускаем скрипт:

./ghettovcb.sh -а -l ./log.txt — запуск копирования всех машин, запись логфайла в той же директории
./ghettovcb.sh -f ./vmlist -l ./log.txt — запуск копирования машин, указанных в файле vmlist, логи сохраняются в той же директории
./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt — аналогочно, только с использованием.conf файла

О корректном выполнении скрипта будет сигнализировать строка с надписью: «###### Final status: All VMs backed up OK! ######». Если такого нет — проверяйте логи, синтаксис команд и путей к файлам.

Для того, чтобы добавить строку на запуск по расписанию (в cron), необходимо выполнить правку файла «/etc/rc.local.d/local.sh» , выполнив следующее:

перейти в каталог /etc/rc.local.d/local.sh
chmod u+w local.sh
открыть файл редактором — vi local.sh
включить редактирование клавищей «i» или «insert»
дописать перед строкой exit0 следующее:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo 0 20 * * * /vmfs/volumes/datastore/script/ghettoVCB.sh -a -l /vmfs/volumes/backup/log/log.txt >> /var/spool/cron/crontabs/root
/bin/crond

при этом указываем расписание (время указывается в UTC, т.е. для MSK -3 часа), т.е. «00 20 * * * «
нажимаем «esc» и сохраняемся — «Shift+:» и «wq»
в конце выполняем chmod u-w local.sh

Таким образом, в 23:00 по МСК будет выполняться резервное копирование файлов виртуальных машин. В нашем случае будет оставаться 3 копии.

Настройка backup для ESXi через ghettoVCB.sh завершена.