Где хранятся виртуальные машины esxi
Всем привет, сегодня мне хочется с вами поделиться, таким опытом, как настройка местоположения хранения снапшотов у виртуальных машин в VMware vSphere. Для чего это может быть нужно мы рассмотрим ниже, но могу вам со сто процентной уверенностью сказать, что данная информация окажется для вас полезной и вы в своей практике сможете ее применить с выгодой для себя. Все имеющиеся вопросы, не описанные в данной статье, прошу писат ь в комментариях, либо на электронную почту, я постараюсь максимально быстро на них ответить, в меру своей занятости.
И так ранее я рассказал, что такое snapshot и рассказал все его тонкости создания, советую почитать. По сегодняшнему вопросу, где вы можете применять настройку другой локации снимков виртуальной машины, приведу пример.
Предположим у вас есть датастор на котором работают 10 виртуальных машин VMware ESXI 5.5. Как мы знаем snapshot хранятся вместе с виртуалками в той же папке и когда делается или удаляется снапшот при резервном копировании например, то на датастор идет повышенная нагрузка, при чем ощутимая, в результате чего у вас если не хватает iops (операций ввода/вывода) все может привести к тормозам остальных виртуальных машин, что нам не нужно.
Разгрузить данный датастор от снапшотов нам поможет перенастройка их домашней директории в которую они по умолчанию кладутся.
Где хранятся снапшоты
Если вы ничего не меняли, то ваши snapshot vm машин хранятся на том же датасторе и в той же папке, где и работает виртуалка, вот пример. Если вы захотите сменить директорию, то у вас два варианта
Меняем директорию workingDir в vmx-файле
Открываем датастор где лежит ваша виртуальная машина > Browse Datastore
Щелкаем правым кликом по файлу конфигурации *.vmx и выбираем download.
Сохраняем в удобное для вас место
И в конце файла дописываем вот такие строки
Можете посмотреть ниже пример пути до моего датастора.
Теперь открываем datastore и папку с виртуальной машиной и жмем Upload File. Загружаем наш новый файл конфига.
Теперь создадим снапшот с именем test snapshot
При таком раскладе у нас перенесется и файл свопа, а нам может быть это не нужно.
Для того, чтобы вернуть его на место введите еще ниже.
еще может потребоваться удалить параметр snapshot.redoNotWithParent = «true»
Меняем директорию workingDir в VMware vSphere
Открываем свойства виртуальной машины переходим на вкладку Options и видим текущий working Location
Выбираем General > Configuration Parameters
чтобы задать или сменить директорию для swap файла создайте поле sched.swap.dir и задайте путь до датастора
и добавьте еще поле snapshot.redoNotWithParent со значением true
Далее vmware советует создать поле workingDir со значением (полный путь до нужной папки)
У меня это не проканало, не знаю почему, пришлось так же лезть в vmx файл и править там, если кто знает в чем дело надеюсь вы подскажете.
Резервное копирование виртуальных машин ESXi с помощью скриптов ghettoVCB
В этой статье я пошагово опишу настройку автоматического резервного копирования и пример восстановления виртуальных машин, работающих на платформе 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 пакета:
И создаём два файла. Первый — описание нашего пакета:
Подробную инструкцию к параметрам можно посмотреть на сайте утилиты.
Собираем VIB пакет:
При нужде, можете воспользоваться моим пакетом (на свой страх и риск).
Таким образом можно собрать и зафиксировать и другие полезные настройки сервера.
4. И в завершение, запускаем в ручную бэкап настроек сервера ESXi:
Восстановление машины из резервной копии
Сразу нужно учитывать, что машина, резервирование которой производилось на горячую, после восстановления будет как после краша — возможна потеря данных внутри машины.
1. Подключаем хранилище с бэкапом на целевой ESXi сервер по NFS, либо просто копируем туда данные по ssh.
3. Запускаем тестовый прогон:
Второй вариант. Так как бэкап представляет собой дамп машины с конфигурационным файлом, то можно просто:
1. Cкопировать его куда-нибудь на ESXi сервер.
2. Исправить файл конфигурации машины (*.vmx), изменив поля имени и местоположения диска машины:
Пути до файлов можно (и нужно) указывать относительно директории машины.
3. Через vSphereClient идём в хранилище:
и добавляем новую машину в список:
4. Если сервер восстановления другой, то в настройках машины меняем «Network Connection».
5. При первом запуске оно спросит, от куда нарисовалась машина, нужно ответить, что перенесли.
Если ответить, что клонировали — изменит уникальные данные, в том числе mac адрес сетевой карты.
Вот в целом и всё. Скрипты ghettoVCB поддерживают ещё другие интересные параметры и варианты копирования, так что полезно почитать документацию. Метод далёк от идеального, но если хочется дёшево и сердито, то вполне работоспособен.
Резервное копирование виртуальных машин в VMware ESXi
Apr 4, 2016 · 11 min read
В этой заметке будет рассмотрено, как создать резервную копию виртуальных машин с помощью скрипта ghettoVCB. Скрипт предназначен для создания бэкапов виртуальных машин в ESX(i) 3.x, 4.x, 5.x и 6.x. Данный способ резервного копирования в отличии от других программных продуктов является абсолютно бесплатным.
Для хранения резервных копий ВМ можно использовать накопители, поддерживающие следующие протоколы:
Но 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:
установить и проверить, что получилось:
По желанию можно воспользоваться моим VIB-пакетом.
Для того, чтобы устанавливать подобные дополнения нужно, чтобы на сервере 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 монтируется следующей строчкой:
Фактически, такое сообщение появляется тогда, когда скрипт не находит бэкап ВМ.
Для того, чтобы задать путь без использования симлинков необходимо узнать UUID устройств. Следующая команда выводит список каждого LUN, подключенного к серверу ESXi и его сопоставление vmfs (Volume Name) к UUID:
Таким образом вместо “backup” и “datastore1” можно использовать соответствующий UUID:
backup: 9108f6f9–353aeed8;
datastore1: 56b74f4f-85fc58fa-87fe-94de8066eda2.
Подробную информацию про идентификацию дисков и файловых систем в ESX(i) можно получить здесь.
и восстанавливаем ВМ:
где:
-c — путь к списку восстанавливаемых машин.
-l — путь расположения логов.
Через vSphere клиент открываем, как на скриншоте ниже:
Troubleshooting.
Для отладки процесса восстановления:
Могут возникнуть ситуации, когда потребуется прервать выполнение ghettoVCB.sh, запущенного в ручном (интерактивном) режиме. Нажмите cntrl+C для остановки родительского процесса и далее:
Для остановки ghettoVCB, запущенного в неинтерактивном режиме:
и завершить оба дочерних процесса по их PID:
Если виртуальная машина находилась в процессе резервного копирования, то открыт дополнительный процесс — vmkfstools:
Бэкап VM ESXi средствами Bareos
Продолжаем серию публикаций о возможностях бэкапирования с помощью Bareos. В этой статье пойдет речь о резервном копировании VM ESXi средствами Bareos.
Для резервного копирования виртуальных машин VMware ESXi зачастую применяют такие средства как Veeam или же скрипт ghettovcb. В этой статье мы рассмотрим способ резервного копирования виртуальной машины средствами Bareos 16.2, а именно будем использовать один из плагинов позволяющего расширить функционал Bareos — vmware-plugin. В 16-й версии изменено расположение конфигурационных файлов, теперь каждый ресурс (pool, client, job и т.д.) распределены по своим директориям, добавлена мультиязычность для web UI, улучшена работа плагина MySQL, более подробную документацию можно просмотреть тут.
Для данного примера у нас есть ESXi 6.0 (для работы плагина достаточно лицензии Evaluation) и сервер под CentOS 7, на который будет установлен Bareos.
Установим необходимые компоненты:
Установим базу данных:
После установки выполним:
Выполняем скрипты подготовки базы данных, установленные вместе с Bareos:
Подробнее о установке и описание компонентов, а также описание основных директив можно просмотреть тут
В каждой поддиректории свой конфигурационный файл, отвечающий за ресурс, соответствующий названию директории.
Перед внесением каких-либо настроек, необходимо убедиться, что выполнены все требования для работы плагина VMware. Официальный список требований можно просмотреть тут.
Нужно установить все зависимости перед установкой плагина
Добавим один из репозиториев EPEL, т.к. нам понадобятся некоторые пакеты для дальнейшей установки:
Обязательным требованием является, чтобы VM на ESXi поддерживала и было разрешено CBT (Changed Block Tracking). На сайте VМware указано как данная опция включается, однако есть более простой способ — с помощью скрипта. Сам скрипт называется vmware_cbt_tool и его можно взять на GitHub.
Скачав на сервер BareOS, и перейдя в директорию скрипта, нужно выполнить следующее:
-s — адрес сервера
-u — пользователь на ESXi (специально завели пользователя bakuser)
-p — его пароль
-d — название нашего «datacenter» в ESXi, по-умолчанию «ha-datacenter»
-f — папка с нашими VM, корень по-умолчанию
-v — название самой VM
—info — отобразит нам текущие настройки CBT для VM
Выполнив команду, должны увидеть:
В результате увидим следующее:
CBT успешно включено.
Теперь необходимо перейти к настройкам самого BareOS, также можно руководствоваться официальной документацией.
Приводим содержимое конфигов:
Следующий файл в данном примере один из самых важных, т.к. в нем выполняется указание опций для плагина
python:module_path=/usr/lib64/bareos/plugins/vmware_plugin — указываем где расположен плагин
module_name=bareos-fd-vmware — указываем его имя
dc — название datacenter в ESXi
folder — папка с VM, по-умолчанию корень
vmname — имя виртуальной машины
vcserver — адрес сервера
vcuser — логин юзера специально заведенного для работ с бэкапом
vcpass — его пароль
Описание Job для восстановления:
Вид письма, которое приходит будет для наглядности отображено позже.
Пример пула Differential приводить не будем, т.к. хоть он и указан в JobDefs, но использовать его не будем.
Описание подключения к стореджу:
Настройки самого стореджа:
Параметры подключения стореджа к директору:
Используемые параметры оповещения:
Обязательно необходимо на стороне сервера выполнить подключение плагина, выполняется это в следующем конфиге:
Подключение к директору:
Тип оповещений, отправляемых на директор:
Принудительно в ручном режиме выполним резервное копирование, для этого войдем в bconsole
Командой message можем наблюдать, что происходит с заданием, видим, что процесс запустился успешно:
Во время выполнения задания на стороне ESXi можно наблюдать, что в консоли вывода сообщений появятся соответствующие уведомления о том, что происходит обращение к диску виртуальной машины, а по окончании удаляется временный snapshot.
Как видим сообщение говорит об успешном бэкапе, тип бэкапа Full, записано 499,5 Mb (на стороне ESXi vmdk файл занимает 560 M). В настройках FileSet мы устанавливали тип сжатия gzip, что в данном сообщении также видно в строке Software Compression.
Сообщение об ошибке будет выглядеть следующим образом. В данном примере как видно ошибка была смоделирована, если не активировать режим CBT для VM, который мы включали на предыдущих шагах при помощи специального скрипта.
В соответствии с нашим расписанием в директиве Schedule<> настройки директора, в течение дня должно было выполниться 3 инкрементальных бэкапа (последний в списке Full бэкап выполнен в ручном режиме). В bconsole, командой «status dir» можно просмотреть насколько размер инкрементальных бэкапов отличается от полного бэкапа:
Что касается восстановления, то оно может быть произведено сразу на хост с ESXi, что выполняется по умолчанию, но для этого сама виртуальная машина должна быть выключена. Или же восстановление можно выполнить на сервер с BareOS. Рассмотрим оба варианта.
После этого можно перейти в папку /tmp и увидеть восстановленный файл vmdk.
Восстановление же сразу на ESXi не требует внесения каких-либо правок перед выполнением restore, но как и писалось ранее, необходимо перед этим выключать виртуальную машину иначе произойдет ошибка:
В качестве теста достаточно создать на виртуальной машине пару тестовых файлов, запустить Job на бэкап. Удалить эти файлы, выключить машину, и восстановить через команду restore без внесения правок как в предыдущем примере, как правило, удаленные файлы будут на прежнем месте.
Теперь рассмотрим возможность добавления резервного копирования для еще одной VM, ее имя «VMBitrix5.1.8»
Важно! Вначале необходимо в настройках директора в файле /etc/bareos/bareos-dir.d/director/bareos-dir.conf подключить плагины для работы с VMware иначе при подключении дополнительных заданий для бэкапа VM получим ошибку о не загруженном плагине:
Теперь файл /etc/bareos/bareos-dir.d/director/bareos-dir.conf должен выглядеть так:
Как видим строки ниже и выполнили подключение плагина:
Далее переходим к редактированию директивы FileSet<> для бэкапа второй виртуальной машины
Переходим к добавлению нового Job для бэкапа новой VM создадим файл backup-bareos-bitrix.conf в директории /etc/bareos/bareos-dir.d/job. В этом файле пропишем параметры для нового Job (группа и владелец всех создаваемых файлов должны быть «bareos»):
Также необходимо создать Job для восстановления в случае необходимости для второй виртуальной машины VMBitrix5.1.8. Создадим файл /etc/bareos/bareos-dir.d/job/restorefiles-vm-bitrix.conf.
Обязательно соблюдение соответствий между FileSet и Pool.
Как видим, также необходимо создать новые пулы. Перейдем в директорию /etc/bareos/bareos-dir.d/pool
Создадим два файла Full-vm-bitrix.conf и Incremental-vm-bitrix.conf. Приводим содержимое каждого:
Опять же, как на предыдущих шагах нужно для второй VM активировать CBT через скрипт vmware_cbt_tool
После внесения каких-либо изменений в конфиге обязательно необходимо перезапустить службы:
Если не возникло никаких ошибок, то можно вновь перейти к консоли bconsole и увидеть добавленные Job для новой VM
Запустим новую задачу:
Частичный вывод команды «status dir» после успешного выполнения бэкапа:
Что касается восстановления второй виртуальной машины, то оно ничем не отличается от примера восстановления первой. Добавление дополнительных задач по бэкапу дополнительных VM аналогично добавлению задачи по бэкапу второй VM.
Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка