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

Добавил пользователь Валентин П.
Обновлено: 10.09.2024

Есть множество способов выполнить резервное копирование отдельной информации или целых серверов. Я хочу рассказать о самом простом способе полного бэкапа сервера и переноса его на другое железо, если будет такая необходимость. Делается все это очень просто, без лишних телодвижений с помощью бесплатного Veeam Agent for Linux FREE.

Введение

Ранее я уже неоднократно рассматривал вопрос резервного копирования данных или целых серверов linux. Конкретно в этих статьях:

Забэкапить сразу весь сервер можно, например, с помощью Duplicity. Но вот восстановить его на другом железе будет не так просто. Помимо данных нужно будет, как минимум, позаботиться о разметке диска, установке загрузчика. На это необходимо затратить некоторые усилия и немного разбираться в теме initramfs и grub. Сам я не очень разбираюсь в нюансах работы этих инструментов и очень не люблю с ними возиться.

Некоторое время назад появился отличный бесплатный продукт для бэкапа всего сервера целиком. Речь идет о Veeam Agent for Linux FREE. С его помощью можно сделать полный backup сервера, положить его куда-нибудь по smb или nfs, потом загрузиться с live cd и восстановить из бэкапа на другом железе.

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

Бэкап можно сделать либо всего сервера сразу, либо отдельного диска, либо отдельных папок и файлов. При выборе бэкапа всего диска или сервера, нельзя задать исключения для отдельных папок или файлов. Это очень неудобно, но увы и ах, таков функционал. Исключения можно сделать только если вы делаете бэкап на уровне папок.
Бэкап можно положить локально на соседний раздел, если делаете резервную копию раздела, локально в папку - если делаете бэкап файлов и папок. Если бэкапите всю систему целиком, то удаленно по smb и nfs. К сожалению, по ftp или sftp программа не работает.

В качестве хранилища для архивов может выступать репозиторий Veeam Backup & Replication. Но я не рассматриваю этот вариант, так как в данном случае использую только бесплатное решение.

Мне очень хотелось настроить резервную копию всего сервера на Яндекс.Диск, но, к сожалению, у меня это не получилось из-за технических ограничений. Яндекс.Диск подключается к системе через webdav. Для того, чтобы сделать резервную копию всей системы, нужно бэкапить либо всю систему сразу, либо образ диска. Если у вас небольшой веб сервер, то скорее всего на нем только один раздел. На этом же разделе хранится кэш, который использует webdav для передачи файлов. Без кэша он работать не умеет.

Думаю вы уже поняли, в чем проблема сделать полный backup сервера с помощью Veeam Agent for Linux на Яндекс.Диск по webdav. Вы не сможете добавить в исключения папку с кэшом от webdav. В итоге, во время бэкапа с помощью veeam будет расти папка с кэшом webdav, которая, в свою очередь, будет бэкапиться. В итоге, свободное место на диске закончится, бэкап прервется.

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

Остановился вот на этом варианте - KeyDisk. После оплаты, вам дают адрес сервера, логин и пароль. Вы можете сразу же подключаться по smb к хранилищу. Можно прям в windows через два обратных слеша зайти или подмонтировать хранилище к linux серверу.

KeyDisk стоит примерно 350р. в месяц за 100 гигов. Не очень дешево, конечно, в сравнении с облачными сервисами, но все равно не дорого. Похожих предложений с доступом по smb я лично вообще не нашел в принципе. Этот объем позволит вам забэкапить небольшой веб сервер с глубиной архива в несколько недель или месяцев, в зависимости от того, сколько данных у вас на нем хранится.

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

Установка Veeam Agent for Linux

Для установки Veeam Agent for Linux необходимо подключить репозиторий veeam под нужную вам систему. Это можно сделать либо руками, либо скачать файл с репозиторием в виде rpm или deb пакета. Сделать это можно на странице с описанием продукта.

Для того, чтобы получить доступ к разделу с загрузками, придется зарегистрироваться. Выбираете тип системы и скачиваете репу.

Чуть ниже рекомендую сразу же скачать Veeam Linux Recovery Media. Он нам понадобится, когда мы будем переносить сервер на другое железо или восстанавливать из бэкапа.

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

Обновляем репозитории и устанавливаем veeam.

Все, Veeam Agent for Linux установлен и готов к работе.

Настройка полного бэкапа сервера

Сделать бэкап с помощью Veeam Agent for Linux очень просто. Вариантов настроек не так много, можете сами все проверить и посмотреть. Я для примера рассмотрю вариант с созданием полного бэкапа всей системы и перенос ее на другое железо. Создаем задачу для резервного копирования сервера на наше хранилище по smb.

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

Нажимаем C (configure) для настройки задания на backup. Задаем любое имя задания, затем указываем, что будем делать полный бэкап сервера.

В качестве приемника для архива системы, указываем Shared Folder.

Далее нужно ввести параметры доступа к хранилищу бэкапов. Я использую свои от системы KeyDisk.

В пункте Restore Points указывается глубина архива. Это число копий, которые будут храниться на сервере. Если делать бэкап каждый день и указать число 14, то будут храниться резервные копии системы за последние 14 дней. Если делать будете через день, то за 28 дней и т.д.

Можно создавать несколько заданий с различной глубиной архива. Например, каждый день с глубиной 7 копий, раз в неделю с глубиной 4, и раз в месяц с глубиной в 12. Таким образом у вас всегда будут последние 7 бэкапов системы на этой неделе. Потом по одному бэкапу в неделю за последний месяц и 12 бэкапов по месяцам в течении последнего года.

Если получите ошибку:

Установите пакет cifs. В CentOS вот так:

И так в Debian/Ubuntu:

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

Запустилась архивация. Можно следить за ее прогрессом.

После завершения архивации системы, можно проверить содержимое сетевого хранилища, зайдя на него прямо из винды.

На этом настройку полного бэкапа сервера мы завершили. Резервная копия системы лежит в надежном месте. Попробуем теперь с нее восстановиться.

Перенос или восстановление linux сервера

Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media, который мы скачали ранее.

Для восстановления системы нужно соблюсти два обязательных условия:

Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.

Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder. Заполняем параметры доступа к хранилищу архивов.

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

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

У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем. ) и жмем Restore whole disk to.

В качестве приемника выбираем пустой диск на новом сервере.

Нажимаем S ( Start restore ). Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.

Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.

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

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

Перенос виртуальной машины с KVM на Hyper-V

В моем случае я переношу сервер с KVM на Hyper-V. После загрузки системы я получаю такую картину.

Сервер начинает бесконечно висеть в подобном состоянии с такими характерными ошибками:

Начинаю разбираться в чем может быть дело. Конечно, тут решение проблемы будет зависеть от конкретной ситуации. А успешность решения от квалификации сисадмина. Я уже немного повозился с подобными переносами и примерно представляю, в чем тут может быть проблема. Частично я эту тему затрагивал, когда делал перенос виртуальных машин с XenServer на Hyper-V. Но там была другая проблема, связанная с кастомным ядром от Xen.

В нашей ситуации с переносом виртуальной машины с KVM на Hyper-V проблема в другом. У нас поменялось имя диска. Нам нужно изменить это имя в fstab и в конфиге grub. До кучи я еще собрал заново initramfs, но не уверен на 100%, что в данном случае это нужно было делать. Я сделал на всякий случай сразу все за один заход.

Итак, загружаемся с установочного диска CentOS 7 и выбираем режим Rescue a CentOS system. Подробно об этом рассказывал в упомянутой ранее статье с переносом от xen. Выбираем первый режим запуска.

Дальше работаем в консоли. Смотрим, как называется наш диск.

У меня это sda, а на прошлом сервере он назывался vda. Нам нужно внести эти изменения в 2 файла:

Диск восстановления в самом начале мог сам смонтировать системный раздел в директорию/mnt/sysimage. Если он этого не сделает по какой-то причине, то сделайте это сами:

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

Мы загрузились в окружение нашего сервера. Тут можете использовать установленный у вас на сервере текстовый редактор. С его помощью изменяете имена дисков в файлах /etc/fstab и /boot/grub2/grub.cfg. Можете просто автозаменой поменять имена.

Теперь соберем новый initramfs. Идем в директорию /boot и смотрим там последнюю версию ядра.

В данном случае просто смотрим самые высокие цифры. Соберем новый initramfs в соответствии с версией ядра.

В завершении установим измененный загрузчик на наш диск:

Перезагружаем сервер. После этих изменений, у меня благополучно все загрузилось. Перенос виртуальной машины с KVM на Hyper-V выполнен полностью. Причем, у нас не было доступа к образу системы. Хотя подобная ошибка скорее всего все равно возникла бы, даже если бы мы конвертировали и переносили готовый образ.

Заключение

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

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

Неподходящие версии ядер. После переноса нужно будет переустановить или обновить ядро.
Разные имена дисков или меток разделов. Нужно будет их привести в соответствие с новым железом.

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

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

Онлайн курс "DevOps практики и инструменты"

12.04.2018

itpro

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):

Примечание. 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 вам может быть предоставлен тестовый (trial период) 60 дней, в течении которых вы можете пользоваться всем функционалом ESXi, а команды vSphere CLI будут отрабатывать в режиме чтения и записи, что означает возможность восстановления из имеющегося бэкапа.

Apr 3, 2017 13:56 · 868 words · 5 minute read esxi backup

Возможности резервного копирования виртуальных машин на гипервизоре под управлением ESXI с бесплатной лицензией существенно ограничены — например, тут не получится использовать vCenter, а функциональность бесплатных версий Veeam Backup или VM Explorer значительно урезана.

Итак, основными возможностями бесплатной версии Xsibackup являются:

Переходим по ссылке для скачивания утилиты Xsibackup, вводим личные данные и обязательно работающий email — на него придет специальный SecretKey и скрипт для установки.

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

Примечание. На ESXI должна быть включена служба SSH.

Подключаемся к консоли ESXI по ssh и вводим команды из письма для установки Xsibackup (повторяем данную процедуру на всех гипервизорах):

Создаем каталог для хранения резервных копий:

Проверим возможность создания бекапов локально:

Тест успешен, для того чтобы сделать резервную копию всех запущенных виртуальных машин запускаем команду еще раз, но без опции --test-mode=true :

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

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

Для настройки крона сначала нужно его установить командой:

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

Виртуализация с использованием решений от 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

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

Большинство организаций используют важные для бизнеса приложения поверх баз данных или других приложений, требующих согласованности транзакций. 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 и прямой доступ к хранилищу.

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

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

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

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

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

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

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

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

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