Продолжаем серию публикаций о возможностях бэкапирования с помощью 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-й версии выглядит так:
/bareos-dir-export
/bareos-dir.d
     	/catalog
     	/client
    	/console
    	/counter
    	/director
    	/fileset
    	/job
    	/jobdefs
    	/messages
    	/pool
    	/profile
    	/schedule
    	/storage
/bareos-fd.d
	     /client
	     /director
	    /messages
/bareos-sd.d
	/autochanger
	/device
	/director
	/messages
	/ndmp
	/storage
/tray-monitor.d
	/client
	/director
	/storage
bconsole.conf


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

Перед внесением каких-либо настроек, необходимо убедиться, что выполнены все требования для работы плагина 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 для бэкапа:
/etc/bareos/bareos-dir.d/job/backup-bareos-fd.conf
Job {
  Name = "vm-ubuntu-backup-job"
  JobDefs = "DefaultJob"
  Client = "vmware"
}

/etc/bareos/bareos-dir.d/jobdefs/DefaultJob.conf

JobDefs {
  Name = "DefaultJob"
  Type = Backup
  Level = Incremental
  FileSet = "vm-ubuntu"                    
  Schedule = "WeeklyCycle"
  Storage = bareos-sd
  Messages = Standard
  Pool = Incremental
  Priority = 10
  Write Bootstrap = "/var/lib/bareos/%c.bsr"
  Full Backup Pool = Full                  
  Differential Backup Pool = Differential  
  Incremental Backup Pool = Incremental    
}


Описание 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 = admin@testdomain.com = 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.



Приходящее сообщение выглядит примерно так:
13-Nov 22:47 bareos-dir JobId 36: No prior Full backup Job record found.
13-Nov 22:47 bareos-dir JobId 36: No prior or suitable Full backup found in catalog. Doing FULL backup.
13-Nov 22:47 bareos-dir JobId 36: Start Backup JobId 36, Job=vm-ubuntu-backup-job.2016-11-13_22.47.47_04
13-Nov 22:47 bareos-dir JobId 36: Using Device "FileStorage" to write.
13-Nov 22:47 bareos-sd JobId 36: Volume "Full-0001" previously written, moving to end of data.
13-Nov 22:47 bareos-sd JobId 36: Ready to append to end of Volume "Full-0001" size=583849836
13-Nov 22:47 vmware JobId 36: python-fd: Starting backup of /VMS/ha-datacenter/ubuntu/[datastore1] ubuntu/ubuntu.vmdk_cbt.json
13-Nov 22:47 vmware JobId 36: python-fd: Starting backup of /VMS/ha-datacenter/ubuntu/[datastore1] ubuntu/ubuntu.vmdk
13-Nov 22:51 bareos-sd JobId 36: Elapsed time=00:04:01, Transfer rate=2.072 M Bytes/second
13-Nov 22:51 bareos-dir JobId 36: Bareos bareos-dir 16.2.4 (01Jul16):
  Build OS:               x86_64-redhat-linux-gnu redhat CentOS Linux release 7.0.1406 (Core)
  JobId:                  36
  Job:                    vm-ubuntu-backup-job.2016-11-13_22.47.47_04
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "vmware" 16.2.4 (01Jul16) x86_64-redhat-linux-gnu,redhat,CentOS Linux release 7.0.1406 (Core) ,CentOS_7,x86_64
  FileSet:                "vm-ubuntu" 2016-11-13 22:47:47
  Pool:                   "Full" (From Job FullPool override)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "bareos-sd" (From Job resource)
  Scheduled time:         13-Nov-2016 22:47:45
  Start time:             13-Nov-2016 22:47:50
  End time:               13-Nov-2016 22:51:51
  Elapsed time:           4 mins 1 sec
  Priority:               10
  FD Files Written:	  2
  SD Files Written:	  2
  FD Bytes Written:	  499,525,599 (499.5 MB)
  SD Bytes Written:	  499,527,168 (499.5 MB)
  Rate:                   2072.7 KB/s
  Software Compression:   73.1 % (gzip)
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):         Full-0001
  Volume Session Id:	  9
  Volume Session Time:    1479067525
  Last Volume Bytes:	  1,083,996,610 (1.083 GB)
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK


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

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

Развернуть
14-Nov 01:17 vmware JobId 39: Fatal error: python-fd: Error VM VMBitrix5.1.8 is not CBT enabled
14-Nov 01:17 vmware JobId 39: 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=VMBitrix5.1.8:vcserver=172.17.10.1:vcuser=bakuser:vcpass=kJo@#!a" requested, but is not loaded.
14-Nov 01:17 bareos-dir JobId 39: Error: Bareos bareos-dir 16.2.4 (01Jul16):
  Build OS:               x86_64-redhat-linux-gnu redhat CentOS Linux release 7.0.1406 (Core)
  JobId:                  39
  Job:                    vm-bitrix-backup-job.2016-11-14_01.17.51_04
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "vmware" 16.2.4 (01Jul16) x86_64-redhat-linux-gnu,redhat,CentOS Linux release 7.0.1406 (Core) ,CentOS_7,x86_64
  FileSet:                "vm-bitrix-fileset" 2016-11-14 01:17:51
  Pool:                   "vm-bitrix-Full" (From Job FullPool override)
  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "bareos-sd" (From Job resource)
  Scheduled time:         14-Nov-2016 01:17:47
  Start time:             14-Nov-2016 01:17:53
  End time:               14-Nov-2016 01:17:54
  Elapsed time:           1 sec
  Priority:               10
  FD Files Written:	  0
  SD Files Written:	  0
  FD Bytes Written:	  0 (0 B)
  SD Bytes Written:	  0 (0 B)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    no
  Encryption:             no
  Accurate:               no
  Volume name(s):
  Volume Session Id:	  12
  Volume Session Time:    1479067525
  Last Volume Bytes:	  0 (0 B)
  Non-fatal FD errors:    1
  SD Errors:              0
  FD termination status:  Fatal Error
  SD termination status:  Canceled
  Termination:            *** Backup Error ***


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



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

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

Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Select full restore to a specified Job date
    13: Cancel
Select item:  (1-13): 3
Enter JobId(s), comma separated, to restore: 66

Building directory tree for JobId(s) 66 ...  
1 files inserted into the tree.

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.

cwd is: /
$ ls
VMS/

$ mark *
1 file marked.

$ done

Defined Clients:
1: vmware
...
Select the Client (1-4): 1

Using Catalog "MyCatalog"
Client "bareos-fd" not found.
Automatically selected Client: vmware
Restore Client "bareos-fd" not found.
Automatically selected Client: vmware
Run Restore job
JobName:         RestoreFiles
Bootstrap:       /var/lib/bareos/bareos-dir.restore.1.bsr
Where:           /tmp/
Replace:         Always
FileSet:         vm-ubuntu
Backup Client:   bareos-fd
Restore Client:  vmware
Format:          Native
Storage:         bareos-sd
When:            2016-11-14 07:37:57
Catalog:         MyCatalog
Priority:        10
Plugin Options:  *None*
OK to run? (yes/mod/no): mod

Parameters to modify:
     1: Level
     2: Storage
     3: Job
     4: FileSet
     5: Restore Client
     6: Backup Format
     7: When
     8: Priority
     9: Bootstrap
    10: Where
    11: File Relocation
    12: Replace
    13: JobId
    14: Plugin Options

Select parameter to modify (1-14): 14
Please enter Plugin Options string: python:localvmdk=yes

Run Restore job
JobName:         RestoreFiles
Bootstrap:       /var/lib/bareos/bareos-dir.restore.1.bsr
Where:           /tmp/
Replace:         Always
FileSet:         vm-ubuntu
Backup Client:   vmware
Restore Client:  vmware
Format:          Native
Storage:         bareos-sd
When:            2016-11-14 07:37:57
Catalog:         MyCatalog
Priority:        10
Plugin Options:  python:localvmdk=yes
OK to run? (yes/mod/no): yes


После этого можно перейти в папку /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 файл выглядит так:
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=qLpE1QQv"
  }
}

FileSet {
  Name = "vm-bitrix"

  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=VMBitrix5.1.8:vcserver=172.17.10.1:vcuser=bakuser:vcpass=kJo@#!a"
  }
}


Переходим к добавлению нового 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.


SIM-Networksотказоустойчивое облако в Германии, SSD хостинг и VPS.
Поделиться с друзьями
-->

Комментарии (11)


  1. lovecraft
    17.11.2016 08:22

    Подскажите, какую скорость бэкапа вы получили? Плагин написан на Python, но дампер — на C++, это вселяет надежду )


  1. rub_ak
    17.11.2016 09:48

    С бесплатным ESXI 5,1 работать будет?


    1. Berezoff
      17.11.2016 11:13
      +1

      Скорее всего, нет. У бесплатного ESXi закрыта API через, которые делаются снапшоты. Хотя от билда к билду API может и отличаться — возможно вам повезёт и у вас всё получится.


      1. SlavikF
        18.11.2016 02:44
        +1

        API для снэпшотов работает на всех редакциях ESXI. Снэпшоты можно даже делать из командной строки через SSH.
        У бесплатного ESXI выключен backup API, в частности CBT.


  1. Viktoraska
    17.11.2016 11:13

    не рекомендую
    «In some cases, such as a power failure or hard shutdown while virtual machines are powered on, CBT might reset and lose track of incremental changes. In vSphere 4.1 and prior, Cold Migration (but not Storage vMotion) could reset but not disable CBT. In vSphere 5.x versions earlier to vSphere 5.5 Update 2, storage vMotion resets CBT. For more information, see Changed Block Tracking is reset after a storage vMotion operation in vSphere 5.x (2048201).»


  1. MortumSK
    17.11.2016 11:13
    +2

    В чём принципиальное преимущество перед бесплатным Veeam Backup Free Edition?


  1. merlin-vrn
    17.11.2016 11:14

    а вот тут инкрементальные бекапы… это вообще насколько эффективно для случая виртуалок? Оно реально только изменившиеся блоки забирает?


    1. MortumSK
      17.11.2016 11:47
      +1

      Реально. Change Block Tracking для этого и сделан, эффективность бэкапов заметно повышается. Конечно это не отменяет необходимость делать full-backup'ы. Например, во вторник и четверг инкрементные, а на выходных — полный.


  1. banuchka
    17.11.2016 15:03

    Доброго времени суток, у меня к Вам несколько вопросов:
    1. Какую сборку ESXi используете? Если это 6+ ветка, то интересно услышать точную версию сборки.
    2. Делаете ли вы верифай(проверку на то, что бекапится не мусор, а то, что забекапили – восстановимо) для того, что бекапите?
    3. Не было ли проблем с рестором цепочки Full -> Incr1 -> Incr2… -> IncrN => RESTORE?

    Спасибо.


  1. varnav
    17.11.2016 17:02

    Инструкция по настройке GhettoVCB короче раз в 20.


    1. sashaboyko
      18.11.2016 12:20

      Конечно. Но ghettoVCB создает только полный слепок ВМ. А предложенное решение на базе Bareos поддерживает дифференциальное и инкрементное резервное копирование. Плюс у ghettoVCB весьма ограниченные возможности по ведению журналов и контролю за корректностью выполнения заданий.