Бэкап VM ESXi средствами Bareos

Автор: vik_kr Дата: . Категория: Статьи

Продолжаем серию публикаций о возможностях бэкапирования с помощью Bareos. В этой статье пойдет речь о резервном копировании VM ESXi средствами Bareos.


Предыдущие посты: «Бэкап с помощью Open Source решения — 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.

Добавим репозиторий:
 

wget http://download.bareos.org/bareos/release/16.2/CentOS_7/bareos.repo -O /etc/yum.repos.d/bareos.repo


Установим необходимые компоненты:
 

yum install -y bareos-client bareos-database-tools bareos-filedaemon bareos-database-postgresql bareos bareos-bconsole bareos-database-common bareos-storage bareos-director bareos-common


Установим базу данных:
 

yum install -y postgresql-server postgresql-contrib


После установки выполним:
 

# postgresql-setup initdb


Выполняем скрипты подготовки базы данных, установленные вместе с Bareos:
 

su postgres -c /usr/lib/bareos/scripts/create_bareos_database
su postgres -c /usr/lib/bareos/scripts/make_bareos_tables
su postgres -c /usr/lib/bareos/scripts/grant_bareos_privileges


Подробнее о установке и описание компонентов, а также описание основных директив можно просмотреть тут
 

Список директорий в 16-й версии выглядит так:


В каждой поддиректории свой конфигурационный файл, отвечающий за ресурс, соответствующий названию директории.

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

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

rpm -ivh 

yum install python

yum install python-pip

yum install python-wheel

pip install --upgrade pip

pip install pyvmomi

yum install python-pyvmomi

После можем установить сам плагин:

yum install bareos-vmware-plugin


Обязательным требованием является, чтобы VM на ESXi поддерживала и было разрешено CBT (Changed Block Tracking). На сайте VМware указано как данная опция включается, однако есть более простой способ — с помощью скрипта. Сам скрипт называется vmware_cbt_tool и его можно взять на GitHub.

Скачав на сервер BareOS, и перейдя в директорию скрипта, нужно выполнить следующее:
 

./vmware_cbt_tool.py -s 172.17.10.1 -u bakuser -p kJo@#!a -d ha-datacenter -f / -v ubuntu --info


По опциям:

-s — адрес сервера
-u — пользователь на ESXi (специально завели пользователя bakuser)
-p — его пароль
-d — название нашего «datacenter» в ESXi, по-умолчанию «ha-datacenter»
-f — папка с нашими VM, корень по-умолчанию
-v — название самой VM
--info — отобразит нам текущие настройки CBT для VM




Выполнив команду, должны увидеть:
 

INFO: VM ubuntu CBT supported: True
INFO: VM ubuntu CBT enabled: False


То есть CBT поддерживается, но в данный момент не включено, поэтому включим все тем же скриптом добавив в конце команды опцию --enablecbt
 

./vmware_cbt_tool.py -s 172.17.10.1 -u bakuser -p kJo@#!a -d ha-datacenter -f / -v ubuntu --enablecbt


В результате увидим следующее:
 

INFO: VM ubuntu CBT supported: True
INFO: VM ubuntu CBT enabled: False
INFO: VM ubuntu trying to enable CBT now
INFO: VM ubuntu trying to create and remove a snapshot to activate CBT
INFO: VM ubuntu successfully created and removed snapshot


CBT успешно включено.

Теперь необходимо перейти к настройкам самого BareOS, также можно руководствоваться официальной документацией.

Приводим содержимое конфигов:
 

/etc/bareos/bareos-dir.d/client/bareos-fd.conf

Client {
  Name = vmware
 #Адрес клиента оставляем именно localhost
 Address = localhost
  Password = "wai2Aux0"
}

/etc/bareos/bareos-dir.d/director/bareos-dir.conf

Director {                           
  Name = "bareos-dir"
  QueryFile = "/usr/lib/bareos/scripts/query.sql"
  Maximum Concurrent Jobs = 10
  Password = "wai2Aux0"         
  Messages = Standard
  Auditing = yes
}


Следующий файл в данном примере один из самых важных, т.к. в нем выполняется указание опций для плагина
 

/etc/bareos/bareos-dir.d/fileset/SelfTest.conf

FileSet {
  Name = "vm-ubuntu"

  Include {
    Options {
         signature = MD5
         Compression = GZIP
    }
    Plugin = "python:module_path=/usr/lib64/bareos/plugins/vmware_plugin:module_name=bareos-fd-vmware:dc=ha-datacenter:folder=/:vmname=ubuntu:vcserver=172.17.10.1:vcuser=bakuser:vcpass=kJo@#!a"
  }
}

 

python:module_path=/usr/lib64/bareos/plugins/vmware_plugin — указываем где расположен плагин
module_name=bareos-fd-vmware — указываем его имя
dc — название datacenter в ESXi
folder — папка с VM, по-умолчанию корень
vmname — имя виртуальной машины
vcserver — адрес сервера
vcuser — логин юзера специально заведенного для работ с бэкапом
vcpass — его пароль

 

Описание Job для бэкапа:


Описание Job для восстановления: 
 

/etc/bareos/bareos-dir.d/job/RestoreFiles.conf

Job {
  Name = "RestoreFiles"
  Type = Restore
  Client = vmware
  FileSet = "vm-ubuntu"
  Storage = bareos-sd
  Pool = Incremental
  Messages = Standard
  Where = /tmp/
}


Настройка оповещений:
 

/etc/bareos/bareos-dir.d/messages/Standard.conf

Messages {
  Name = Standard
# Описание команды для отправки email
  mailcommand = "/usr/bin/bsmtp -h localhost -f \"\(Bareos\) \<%r\>\" -s \"Bareos: Intervention needed for %j\" %r"
  operator = root@localhost = mount                                
  #Отправляем уведомление о всех основных событиях
mail = 
 Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.
  = alert,error,fatal,terminate, !skipped
# В консоль отображаем все основные события
 console = all, !skipped, !saved
# Указываем, что будет записываться в лог, т.е. все  
append = "/var/log/bareos/bareos.log" = all, !skipped
# Отправлять сообщения в каталог БД  
catalog = all
}


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

Описание пулов:
 

/etc/bareos/bareos-dir.d/pool/Full.conf

Pool {
  Name = Full
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                     
  Volume Retention = 365 days         
  Maximum Volume Bytes = 50G          
  Maximum Volumes = 100               
  Label Format = "Full-"              
}

/etc/bareos/bareos-dir.d/pool/Incremental.conf
Pool {
  Name = Incremental
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                     
  Volume Retention = 30 days          
  Maximum Volume Bytes = 1G         
  Maximum Volumes = 100               
  Label Format = "Incremental-"      
}


Пример пула Differential приводить не будем, т.к. хоть он и указан в JobDefs, но использовать его не будем.

Настройка расписания:
 

/etc/bareos/bareos-dir.d/schedule/WeeklyCycle.conf

Schedule {
  Name = "WeeklyCycle"
# Первого числа в 21:00 запускается полный бекап  
Run = Full on 1 at 21:00
# С второго по 31 число в час ночи запускается также полный бэкап  
Run = Full 2-31 at 01:00
# С 2 по 31 число в 10,15 и 19:00 запускается инкрементальный бэкап  
Run = Incremental on 2-31 at 10:00
  Run = Incremental on 2-31 at 15:00
  Run = Incremental on 2-31 at 19:00
}


Описание подключения к стореджу:
 

/etc/bareos/bareos-dir.d/storage/File.conf
Storage {
  Name = bareos-sd
  Address = localhost                 
  Password = "wai2Aux0"
  Device = FileStorage
  Media Type = File
}


Настройки самого стореджа:
 

/etc/bareos/bareos-sd.d/device/FileStorage.conf

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /opt/backup
  LabelMedia = yes;                  
  Random Access = yes;
  AutomaticMount = yes;               
  RemovableMedia = no;
  AlwaysOpen = no;
 }


Параметры подключения стореджа к директору:
 

/etc/bareos/bareos-sd.d/director/bareos-dir.conf
Director {
  Name = bareos-dir
  Password = "wai2Aux0"
}


Используемые параметры оповещения:
 

/etc/bareos/bareos-sd.d/messages/Standard.conf

Messages {
  Name = Standard
  Director = bareos-dir = all
}

/etc/bareos/bareos-sd.d/storage/bareos-sd.conf

Storage {
  Name = bareos-sd
  Maximum Concurrent Jobs = 20
}


Обязательно необходимо на стороне сервера выполнить подключение плагина, выполняется это в следующем конфиге:
 

/etc/bareos/bareos-fd.d/client/myself.conf
Client {
  Name = vmware
  Maximum Concurrent Jobs = 20
# Подключение плагинов
  Plugin Directory = /usr/lib64/bareos/plugins
  Plugin Names = "python"
}


Подключение к директору:
 

/etc/bareos/bareos-fd.d/director/bareos-dir.conf
Director {
  Name = bareos-dir
  Password = "wai2Aux0"
}


Тип оповещений, отправляемых на директор:
 

/etc/bareos/bareos-fd.d/messages/Standard.conf
Messages {
  Name = Standard
  Director = bareos-dir = all, !skipped, !restored
}


Принудительно в ручном режиме выполним резервное копирование, для этого войдем в bconsole
 

*run

Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
A job name must be specified.
The defined Job resources are:
     1: RestoreFiles
     2: vm-ubuntu-backup-job

Select Job resource (1-2): 2

Run Backup job
JobName:  vm-ubuntu-backup-job
Level:    Incremental
Client:   vmware
Format:   Native
FileSet:  vm-ubuntu
Pool:     Incremental (From Job IncPool override)
Storage:  bareos-sd (From Job resource)
When:     2016-11-14 07:22:11
Priority: 10
OK to run? (yes/mod/no): yes


Командой message можем наблюдать, что происходит с заданием, видим, что процесс запустился успешно:
 

14-Nov 07:22 vmware JobId 66: python-fd: Starting backup of /VMS/ha-datacenter/ubuntu/[datastore1] ubuntu/ubuntu.vmdk_cbt.json
14-Nov 07:22 vmware JobId 66: python-fd: Starting backup of /VMS/ha-datacenter/ubuntu/[datastore1] ubuntu/ubuntu.vmdk


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


 

Приходящее сообщение выглядит примерно так:


Как видим сообщение говорит об успешном бэкапе, тип бэкапа Full, записано 499,5 Mb (на стороне ESXi vmdk файл занимает 560 M). В настройках FileSet мы устанавливали тип сжатия gzip, что в данном сообщении также видно в строке Software Compression.

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

Развернуть


В соответствии с нашим расписанием в директиве Schedule{} настройки директора, в течение дня должно было выполниться 3 инкрементальных бэкапа (последний в списке Full бэкап выполнен в ручном режиме). В bconsole, командой «status dir» можно просмотреть насколько размер инкрементальных бэкапов отличается от полного бэкапа:



Что касается восстановления, то оно может быть произведено сразу на хост с ESXi, что выполняется по умолчанию, но для этого сама виртуальная машина должна быть выключена. Или же восстановление можно выполнить на сервер с BareOS. Рассмотрим оба варианта.
 

При восстановлении локально на сервер с BareOS. Заходим в bconsole:


После этого можно перейти в папку /tmp и увидеть восстановленный файл vmdk.
 

cd /tmp/" [datastore1] ubuntu"
ls
ubuntu.vmdk


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

JobId 80: Fatal error: python-fd: Error VM VMBitrix5.1.8 must be poweredOff for restore, but is poweredOn


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

Теперь рассмотрим возможность добавления резервного копирования для еще одной VM, ее имя «VMBitrix5.1.8»

Важно! Вначале необходимо в настройках директора в файле /etc/bareos/bareos-dir.d/director/bareos-dir.conf подключить плагины для работы с VMware иначе при подключении дополнительных заданий для бэкапа VM получим ошибку о не загруженном плагине:

Пример:
 

JobId 41: Fatal error: fd_plugins.c:654 Command plugin "python:module_path=/usr/lib64/bareos/plugins/vmware_plugin:module_name=bareos-fd-vmware:dc=ha-datacenter:folder=/:vmname=" requested, but is not loaded


Теперь файл /etc/bareos/bareos-dir.d/director/bareos-dir.conf должен выглядеть так:
 

Director {                            # define myself
  Name = "bareos-dir"
  QueryFile = "/usr/lib/bareos/scripts/query.sql"
  Maximum Concurrent Jobs = 10
  Password = "wai2Aux0"         # Console password
  Messages = Standard
  Auditing = yes
  Plugin Directory = /usr/lib64/bareos/plugins
  Plugin Names = "python"
}


Как видим строки ниже и выполнили подключение плагина:
 

Plugin Directory = /usr/lib64/bareos/plugins
  Plugin Names = "python"


Далее переходим к редактированию директивы FileSet{} для бэкапа второй виртуальной машины
 

/etc/bareos/bareos-dir.d/fileset/SelfTest.conf

 

После добавления новых строк для бэкапа виртуальной машины VMBitrix5.1.8 файл выглядит так:


Переходим к добавлению нового Job для бэкапа новой VM создадим файл backup-bareos-bitrix.conf в директории /etc/bareos/bareos-dir.d/job. В этом файле пропишем параметры для нового Job (группа и владелец всех создаваемых файлов должны быть «bareos»):
 

Job {
  Name = "vm-bitrix-backup-job"
  Client = "vmware"
  Type = Backup
  Level = Incremental
  FileSet = "vm-bitrix"                     
  Schedule = "WeeklyCycle"
  Storage = bareos-sd
  Messages = Standard
  Pool = vm-bitrix-Incremental
  Priority = 10
  Write Bootstrap = "/var/lib/bareos/%c.bsr"
  Full Backup Pool = vm-bitrix-Full                  
  Incremental Backup Pool = vm-bitrix-Incremental    
}


Также необходимо создать Job для восстановления в случае необходимости для второй виртуальной машины VMBitrix5.1.8. Создадим файл /etc/bareos/bareos-dir.d/job/restorefiles-vm-bitrix.conf.

Его содержимое:
 

Job {
  Name = "restorefiles-vm-bitrix"
  Type = Restore
  Client = vmware
  FileSet = "vm-bitrix"
  Storage = bareos-sd
  Pool =  vm-bitrix-Incremental
  Messages = Standard
  Where = /tmp/
}


Обязательно соблюдение соответствий между FileSet и Pool.

Как видим, также необходимо создать новые пулы. Перейдем в директорию /etc/bareos/bareos-dir.d/pool

Создадим два файла Full-vm-bitrix.conf и Incremental-vm-bitrix.conf. Приводим содержимое каждого:
 

# cat  /etc/bareos/bareos-dir.d/pool/Full-vm-bitrix.conf

Pool {
  Name = vm-bitrix-Full
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                    
  Volume Retention = 365 days         
  Maximum Volume Bytes = 50G          
  Maximum Volumes = 100               
  Label Format = "Full-vm-bitrix-"              
}

# cat /etc/bareos/bareos-dir.d/pool/Incremental-vm-bitrix.conf
Pool {
  Name = vm-bitrix-Incremental
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                     
  Volume Retention = 30 days          
  Maximum Volume Bytes = 1G           
  Maximum Volumes = 100               
  Label Format = "Incremental-vm-bitrix-"
}


Опять же, как на предыдущих шагах нужно для второй VM активировать CBT через скрипт vmware_cbt_tool

После внесения каких-либо изменений в конфиге обязательно необходимо перезапустить службы:
 

systemctl restart bareos-fd
systemctl restart bareos-dir


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

Список новых Job:



Запустим новую задачу:



Частичный вывод команды «status dir» после успешного выполнения бэкапа:



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