Bareos tray monitor что это

Бэкап 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.

Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка

Источник

Bareos (Русский)

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Bareos (Backup Archiving Recovery Open Sourced) — высоконадежное сетевое кроссплатформенное программное обеспечение для резервного копирования, архивирования и восстановления данных. Bareos, основанный в 2010 году как 100-процентное открытое ответвление проекта Bacula, активно развивается и пополняется многими новыми функциями.

Contents

Описание пакетов

Установка серверной части

Для минимальной установки серверной части достаточно установить следующие пакеты:

Пакет главного демона (Директора):

Пакет предпочитаемой базы данных (допустим MySQL):

Пакет хранилища архивных данных (можно устанавливать на другом сервере или даже на нескольких серверах):

Настройка базы данных MySQL

Для создания mysql базы данных на localhost и пользователя root выполним:

Создадим пользователя bareos и настроим привилегии:

Пример содержания файла:

Настрока места хранения бекапов Storage (SD)

Структура каталога с конфигурационными файлами может иметь следующий вид:

Пример файла конфигурации:

Пример файла конфигурации:

Пример файла конфигурации:

Запуск демона Storage:

Примеры конфигурационных файлов

Источник

Bareos: ленты, Hyper-V и ещё всякое

Это пост про жизнь после Getting Started with Bareos, и о чем пришлось дольше всего читать всеобъемлющий мануал.

Стородж

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

Ситуация

У нас просто организация, не ИТ-профиля, не хостинг. Бэкапим виртуальные машины с кластеров Hyper-V, файлы с файлопомоек и дампы баз данных, ну и ещё разные мелочи.

Почему бареос

Потому что доступен виндовый клиент. Как известно, Bareos — это драматический форк Bacula, заслуженной и проверенной. Но во время выбора бакула зажимала исходники (да и бинари) своего fd для Windows, поэтому нет. Veeam хорош, но стóит как кресло стадиона ФК «Зенит». Был DPM, но сколько мы с Антоаном из техподдержки Майкрософта с ним не боролись, любви так и не возникло.

Установка

была описана неоднократно. Кто такой директор и чем он занимается с другими демонами — можно почитать, например, здесь. Замечу только, что dir и sd крайне желательно должны быть одной версии, версия fd не так важна. По ощущениям от чейнджлогов, версию лучше иметь 16 или выше.

Базовая настройка

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

Hyper-V

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

А вот c:\cmd\search-vm.ps1, который и отдаёт путь к машине:

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

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

Кассеты

Scratch-пулы. Хочу обратить на них внимание: из них бареос берёт кассеты для добавления в другие пулы, в которые он собирается писать. Незнакомую кассету без метки бареос в рабочий пул добавлять не станет. Поэтому все новые ленты добавляем в пул Scratch:

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

Размер блоков и файлов нужно поставить побольше, это благотворно скажется на скорости лент. «If you are configuring an modern drive like LTO-4 or newer, you probably will want to set the Maximum File Size to 20GB», так что не скромничайте.

Чтобы у бареоса не возникло искушения что-нибудь записать на кассету, которая уже находится в далёком сейфе, лучше перед выемкой сменить ей статус с Append на Used:

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

Кассету легко выкрасть (ну, легче, чем IBM DS8800), поэтому данные крайне желательно зашифровать. Можно сделать это средствами самой писалки, но я люблю софтовые решения как более универсальные и гибкие. Просто не забудьте.

Если не даёт сделать unload, то предварительно

Спулинг

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

Чтобы работало, сначала на стороне sd нужно указать расположение и размер спулера:

а затем уже включить для конкретных заданий:

У меня эта директива в шаблоне «ленточного» задания, а для «дисковых» заданий спулинг практически бесполезен.

Про файлы

Линуксовая привычка — лезть во внутренности, расковыривать и грепать. То же самое хотелось и с файлами-томами бареоса, чтобы можно было найти нужный том и восстановить даже при неработающем директоре. Для этого попробовал на каждое задание создавать новый файл с именем, содержащим имя задания. Пришлось удалять устаревшие тома скриптом по крону, а ещё следить, чтобы у каждого тома было задание в базе и наоборот. Бареос быстро начал обрастать жуткими костылями, решено было отказаться от человекочитаемого именования, использовать бессмысленные имена и Recycle (очистка и повторное использование файла для другого задания). Всё-таки без директора никуда, при потере серверной в первую очередь нужно восстанавливать именно его.

А ещё IBM рекомендует хранить одно задание в одном файле, и пока что я с ними согласен.

Мониторинг

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

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

Скрипт для дискаверинга (LLD) приколочен к формату вывода bconsole и легко может сломаться, но пока работает. И JSON лепится руками, но пока тоже работает.

А ещё я люблю stacked-графики в заббиксе, вот, например, занятый разными заданиями объём пленки:

Видно, что синее задание пора поделить на несколько маленьких.

Приятные мелочи

Будущие свершения

Источник

Бэкап с помощью Open Source решения — Bareos

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

Bareos – была выбрана как система резервного копирования по таким причинам:

Описание задачи

Допустим у нас есть 3 машины. Серверы: Bareos, BitrixVm, Windows Server 2012 R2. Для примера все это будет находиться в пределах одной сети, но сам Bareos, конечно же, позволяет выполнять резервное копирование если машина находиться за ее пределами.

Bareos — 172.16.10.10
BitrixVM — 172.16.10.11
Windows Server — 172.16.10.12

Для сервера с Bareos будем использовать CentOS 7. Происходит обычная установка:

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

При установке Bareos в /etc/bareos имеем следующий список файлов и папок, за исключением директории «ssl», к ней перейдем чуть позже:

После установки в директории /usr/lib/bareos/scripts/ появятся подготовленные скрипты для работы с Bareos. Благодаря им выполним предварительную настройку базы данных (создадим базу, таблицы, и права):

Важным моментом является то, что имена наших машин должны резолвиться, если нет, то добавим соответствующие строки в /etc/hosts

bareos-server — сам сервер, bareos-fd — также будем делать бэкап самого сервера, т.е. в то же время, будет выступать как клиент, далее в конфигурации это будет видно, bitrixvm — название клиента говорит само за себя, win-fd — клиент с Windows Server 2012 R2.

Настройку серверной части для BareOS, а именно директора, необходимо выполнить в файле bareos-dir.conf. Директор отвечает за все выполняемые операции.

Из основных директив:

Director — описание самого директора,
Storage — устройство на которое пишем бэкапы,
Catalog — содержит информацию по выполненным Job, сохраненным файлам, клиентам, статусам,
Messages — какие сообщения будут собраны и как их доставлять,
Console — настройка консоли для управления директором,
Client — описание клиента, с которого будут сниматься резервные копии,
Pool — позволяет управлять т.н. Volume куда будут писаться данные для разных типов бэкапа (Full, Incremental, Differential), ограничить сроки хранения Volume, размеры,
FileSet — что бэкапим и дополнительные атрибуты,
Schedule — расписание,
Job — описание задачи по бэкапу.

Из официальной документации схема взаимодействия между службами:

Director <
#Обязательный параметр имя директора
Name = bareos-server
# Обязательный параметр для файлов запросов
QueryFile = «/usr/lib/bareos/scripts/query.sql»
# Количество одновременно выполняемых Job
Maximum Concurrent Jobs = 10
# Пароль (зачастую используется 20-40 символов, для теста ограничимся 9 знаками)
Password = «zcx@#$BGj»
# Указание какие оповещения использовать (директива Message описывается далее)
Messages = Standart
# TLS шифрование. Будет описано далее.
# TLS включено
TLS Enable = yes
TLS Require = yes

TLS Verify Peer = yes
#Разрешенные CN
TLS Allowed CN = «bareos-server»
TLS Allowed CN = «bitrixvm»
TLS Allowed CN = «win-fd»
# Расположение CA сертификата
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
# Расположение сертификат
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
# Расположение ключа к сертификату
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
TLS DH File = /etc/bareos/ssl/dh1024.pem
>

Storage <
Name = bareos-server-sd
# Можно указать как по IP так и по имени, для корректной работы TLS важно указывать по #имени
Address = bareos-server
Password = «zcx@#$BGj»
# Задается имя для устройства где будут храненится данные. Параметры устройства установлены в файле bareos-sd.conf
Device = bareos-sd
Media Type = File
Port = 9103
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
>

Catalog <
#Задаются все параметры для подключения к БД
Name = bareos-server
dbdriver = «postgresql»
dbname = «bareos»
dbuser = «bareos»
dbpassword = «»
>

Client <
# Имя клиента для бэкапа
Name = bareos-fd
# Название каталога
Catalog = bareos-server
Enabled = yes
# Адрес задаем именем
Address = bareos-server
Password = «zcx@#$BGj»
Port = 9102
# Параметры TLS будут описаны позже
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
>

Pool <
# Имя пула для инкрементального бэкапа
Name = bareos-pool-Incremental
Pool Type = Backup
Recycle = yes
Auto Prune = yes
Volume Retention = 10 days
Label Format = «bareos-client-Incremental-»
>

Pool <
# Имя пула для дифференциального бэкапа
Name = bareos-pool-Differential
Pool Type = Backup
Recycle = yes
Auto Prune = yes
Volume Retention = 11 days
Label Format = «bareos-client-Differential-»
>

FileSet <
# Задаем имя для набора файлов
Name = bareos-fileset
# В Include указажем какие файлы будут сохраняться. В данном случае папка /etc
Include <
File = «/etc»
>
>

Schedule <
#Имя расписания
Name = «MonthlyCycle»
# 1 раз в неделю выполняется полный бэкап
Run = Level = Full mon at 2:00
# В течении дня 5 инкрементальных бэкапов каждый час
Run = Level= Incremental hourly at 13:00
Run = Level = Incremental hourly at 14:00
Run = Level = Incremental hourly at 15:00
Run = Level = Incremental hourly at 16:00
Run = Level = Incremental hourly at 17:00
>

# Добавляем в качестве отдельных файлов конфигурации двух остальных клиентов.

Важно чтобы было соответствие между конфигурациями:

Storage <
# Имя
Name = bareos-server-sd
# Максимальное количество одновременно выполняющихся Job
Maximum Concurrent Jobs = 20
# Адрес, указываем по имени
SDAddress = bareos-server
SDPort = 9103
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = no
TLS Allowed CN = «bareos-server»
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
>

Director <
# Описываем параметры директора, который может подключаться к Storage
Name = bareos-server
Password = «zcx@#$BGj»
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = «bareos-server»
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
TLS DH File = /etc/bareos/ssl/dh1024.pem
>

Device <
# Описываем само устройство для хранения
Name = bareos-sd
Media Type = File
# Путь к устройству
Archive Device = /opt/backup
# Разрешить автоматически размечать тома
LabelMedia = yes
# Для одновременного доступа при одновременном выполнении нескольких задач
Random Access = yes
# Автоматически монтировать устройство
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
>

Messages <
Name = Standard
director = bareos-server = all
>

Настройка клиента bareos-fd.conf:

Director <
# Параметры для подключения директора
Name = bareos-server
Password = «zcx@#$BGj»
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = «bareos-server»
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
TLS DH File = /etc/bareos/ssl/dh1024.pem
>

FileDaemon <
# FileDaemon синоним Client
Name = bareos-fd
Maximum Concurrent Jobs = 20
# Отключается совместимость с Bacula. В таком случае включаются все возможности #bareos, которые включены по умолчанию.
Compatible = no
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem

Messages <
Name = Standard
director = bareos-server = all
>

После всех основных настроек нужно перезапустить службы bareos:

В случае возникновения ошибок состояние смотрим командой:

Перейдем к установке плагина bareos клиента для Windows. Можно скачать тут.

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

Прописываем такие данные:

Client Name — win-fd
Director Name — bareos-server
Password — zcx@#$BGj
Networks Address — bareos-server

Введенные настройки всегда можно подправить, файл конфигурации по умолчанию лежит в «C:\Program Data\Bareos\bareos-fd.conf».

В файле hosts также указываем IP для сервера BareOS, чтобы имя резолвилось. Со стороны сервера (bareos-server) конфиг для клиента (win-fd) выглядит следующим образом и находиться по пути /etc/bareos/bareos-dir.d/win.conf:

Client <
Name = win-fd
Address = win-fd
Password = «zcx@#$BGj»
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem
>

Pool <
Name = win-bareos-pool-Full
Auto Prune = yes
Label Format = «bareos-client-Full-»
Pool Type = Backup
AutoPrune = yes
Recycle = yes
Volume Retention = 3 months
>

Pool <
Name = win-bareos-pool-Differential
Pool Type = Backup
AutoPrune = yes
Recycle = yes
Volume Retention = 11 days
Label Format = «win-bareos-client-Differential-»
>

Pool <
Name = win-bareos-pool-Incremental
Pool Type = Backup
AutoPrune = yes
Recycle = yes
Volume Retention = 10 days
Label Format = «win-bareos-client-Incremental-»
>

FileSet <
Name = bareos-fileset-win
Include <
File = «C:\\Users\\»
>
>

Job <
Name = Job-win-Full
Type = Backup
Level = Incremental
Client = win-fd
FileSet = bareos-fileset-win
Schedule = «MonthlyCycle»
Storage = bareos-server-sd
Messages = Standart
Pool = win-bareos-pool-Incremental
Full Backup Pool = win-bareos-pool-Full
Differential Backup Pool = win-bareos-pool-Differential
Incremental Backup Pool = bareos-pool-Incremental
>

Job <
Name = Job-win-Full-restore
Type = Restore
Client = win-fd
FileSet = «bareos-fileset-win»
Storage = bareos-server-sd
Pool = win-bareos-pool-Full
Messages = Standart
Where = «C:/tmp»
>

Из директивы FileSet видим, что для задачи Job-win-Full копируем папку пользователей «C:\Users» и в задаче Job-win-Full-restore восстанавливаем ее в папку при необходимости «C:\tmp».

Остался еще один клиент (bitrixvm) для которого нужно выполнять копирование корневой директории и в отдельной задаче копирование базы данных mysql.

Перейдем в каталог /etc/bareos

Для настройки клиента перейдем в директорию /bareos-fd.d

По умолчанию, после установки конфигурация разбросана на три показанные выше директории, поэтому для дальнейшего удобства закомитируем частичные конфигурации в директориях director и messages, и выполним все настройки в /client/myself.conf

Client <
Name = bitrixvm
Maximum Concurrent Jobs = 20
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bitrixvm.cert.pem
TLS Key = /etc/bareos/ssl/bitrixvm.nopass.key.pem
compatible = no
>

Director <
Name = bareos-server
Password = «zcx@#$BGj»
TLS Enable = yes
TLS Require = yes
TLS Verify Peer = yes
TLS Allowed CN = «bareos-server»
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bitrixvm.cert.pem
TLS Key = /etc/bareos/ssl/bitrixvm.nopass.key.pem
TLS DH File = /etc/bareos/ssl/dh1024.pem
>

Вносим параметры и перезапускаем службу:

Прописываем в hosts адрес для bareos-server

Со стороны сервера (bareos-server) конфигурация для клиента (bitrixvm) выглядит следующим образом и находиться — /etc/bareos/bareos-dir.d/bitrixvm.conf:

Client <
Name = bitrixvm
Address = bitrixvm
Password = «zcx@#$BGj»
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = /etc/bareos/ssl/ca-chain.cert.pem
TLS Certificate = /etc/bareos/ssl/bareos-server.cert.pem
TLS Key = /etc/bareos/ssl/bareos-server.nopass.key.pem

Pool <
Name = bitrixvm-bareos-pool-Full
Label Format = «bitrixvm-bareos-client-Full-»
Pool Type = Backup
AutoPrune = yes
Recycle = yes
Volume Retention = 3 months
>

Pool <
Name = bitrixvm-bareos-pool-Differential
Pool Type = Backup
Label Format = «bitrixvm-bareos-client-Differential-»
AutoPrune = yes
Recycle = yes
Select Job resource (1-6): = 11 days
>

Pool <
Name = bitrixvm-bareos-pool-Incremental
Pool Type = Backup
Label Format = «bitrixvm-bareos-client-Incremental-»
AutoPrune = yes
Recycle = yes
Volume Retention = 10 days
>

Job <
Name = Job-bitrixvm-mysql
Type = Backup
Level = Full
Client = bitrixvm
FileSet = bareos-fileset-bitrixvm-mysql
Schedule = «MonthlyCycle»
Storage = bareos-server-sd
Messages = Standart
Pool = bitrixvm-bareos-pool-Incremental
Full Backup Pool = bitrixvm-bareos-pool-Full
Differential Backup Pool = bitrixvm-bareos-pool-Differential
Incremental Backup Pool = bitrixvm-bareos-pool-Incremental

Job <
Name = Job-bitrixvm-Full
Type = Backup
Level = Full
Client = bitrixvm
FileSet = bareos-fileset-bitrixvm
Schedule = «MonthlyCycle»
Storage = bareos-server-sd
Messages = Standart
Pool = bitrixvm-bareos-pool-Incremental
Full Backup Pool = bitrixvm-bareos-pool-Full
Differential Backup Pool = bitrixvm-bareos-pool-Differential
Incremental Backup Pool = bitrixvm-bareos-pool-Incremental
>

FileSet <
Name = bareos-fileset-bitrixvm
Include <
Options <
compression = GZIP
>
File = «/»
>
>

FileSet <
Name = bareos-fileset-bitrixvm-mysql
Include <
Options <
# Ставим тип сжатия
compression = GZIP
signature = MD5
>
File = «/tmp/dump.sql»
>
>

Job <
Name = Job-bitrixvm-mysql-restore
Type = Restore
Client = bitrixvm
FileSet = «bareos-fileset-bitrixvm-mysql»
Storage = bareos-server-sd
Pool = bitrixvm-bareos-pool-Full
Messages = Standart
Where = /tmp
>

Job <
Name = Job-bitrixvm-Full-restore
Type = Restore
Client = bitrixvm
FileSet = «bareos-fileset-bitrixvm»
Storage = bareos-server-sd
Pool = bitrixvm-bareos-pool-Full
Messages = Standart
Where = /tmp
>

Сохраненный файл dump.sql будет после бэкапирован как указано для FileSet с названием «bareos-fileset-bitrixvm-mysql».

Для шифрования передачи данных Bareos использует протокол TLS. Для каждого клиента и для директора у нас должны быть CA сертификат, сертификат и ключ. Будем использовать самоподписанные сертификаты, все это можно сделать через openssl.

Перейдем по пути конфигурационного файла openssl /etc/pki/tls/openssl.cnf

Генерируем CA сертификат:

После ввода пароля и остальных данных получим два файла:

Подправим/проверим файл настроек openssl.cnf чтобы были верно указаны пути к сертификатам, жирным выделено то, что нужно будет изменить.

Также нужно создать файлы index.txt и serial в папке /etc/pki/CA:

В файл serial сразу заносим значение «01», в файле будет содержаться следующий номер для следующего сертификатам:

Генерируем ключ для сервера, необходимо будет ввести пароль.

Подписываем CSR через CA, получаем сам сертификат

Убираем пароль для ключа, т.к. bareos он нужен безпарольный

CA ключ и сертификат преобразуем в один файл с расширением PEM

Генерируем DH ключ

Копируем сертификаты bareos-server.cert.pem bareos-server.nopass.key.pem ca-chain.cert.pem dh1024.pem в папку /etc/bareos/ssl, которую предварительно нужно создать и установить группу bareos

Для каждого сертификата меняем группу на bareos

Аналогичные действия нужно проделать для каждого клиента (bitrixvm, win-fd):

Посредством SCP копируем 4 файла bitrixvm.cert.pem bitrixvm.nopass.key.pem ca-chain.cert.pem dh1024.pem на удаленную машину bitrixvm в папку /etc/bareos/ssl, которую предварительно нужно создать и установить группу bareos как для папка так и для сертификатов.

В конфигурации клиента bitrixvm (/etc/bareos/bareos-fd.d/client/myself.conf) в секции Director <> необходимо чтобы были прописаны сертификаты клиента, но не директора. В конфигурации на стороне сервера (/etc/bareos/bareos-dir.d/bitrixvm.conf) в секции Client <> указаны сертификаты директора. После внесения изменений в конфигурации перезапустить службы.

Создание сертификатов для машины win-fd идентично.

Также нужно прописать сертификаты для bconsole, утилита, позволяющая управлять директором в файле /etc/bareos/bconsole.conf:

Процедура бэкапа или восстановления выглядит следующим образом. Воспользуемся утилитой bconsole, в качестве приветствия увидим *
run Покажет все возможные Job:

*run
A job name must be specified.
The defined Job resources are:
1: Job-Full
2: Job-Full-restore
3: Job-bitrixvm-mysql
4: Job-bitrixvm-Full
5: Job-bitrixvm-mysql-restore
6: Job-bitrixvm-Full-restore
Select Job resource (1-6): 3

Run Backup job
JobName: Job-bitrixvm-mysql
Level: Full
Client: bitrixvm
Format: Native
FileSet: bareos-fileset-bitrixvm-mysql
Pool: bitrixvm-bareos-pool-Full (From Job FullPool override)
Storage: bareos-server-sd (From Job resource)
When: 2016-10-16 11:05:16
Priority: 10
OK to run? (yes/mod/no):
# Задача ушедшая на выполнение получает JobId
Job queued. JobId=75

Результат выполнения команды можно просмотреть либо через команду message и в ответ получим примерно такое:

Или через команду status dir

Где по графе статус можно просмотреть состояние бэкапа. Job с номером 75 прошел успешно.

Восстановление происходит по команде restore

После чего будет предложен список всех возможных вариантов

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

Покажем список последних 20 заданий:

Жмем 3 и указываем номер JobID, например 75. После этого автоматически попадаем в консоль для выбора файлов, которые хотим восстановить

Список всех доступных команд можно просмотреть через команду help. Проверяем какие файлы есть в наличии в данном бэкапе, отмечаем нужные файлы командой mark через указание файлов или через *, выбрав таким образом все. По завершении выполняем команду done после чего пойдет диалог с системой.

bitrixvm-bareos-client-Full-0011 bareos-server-sd bareos-sd

Volumes marked with «*» are online.

1 file selected to be restored.

Выбираем нужную нам задачу восстановления (пункт 2)

The defined Restore Job resources are:
1: Job-Full-restore
2: Job-bitrixvm-mysql-restore
3: Job-bitrixvm-Full-restore
Select Restore Job (1-3): 2

Задаем клиента для которого выполняем восстановление (2)

Defined Clients:
1: bareos-fd
2: bitrixvm
3: win-fd
Select the Client (1-3): 2

Using Catalog «bareos-server»
Run Restore job
JobName: Job-bitrixvm-mysql-restore
Bootstrap: /var/lib/bareos/bareos-server.restore.1.bsr
Where: /tmp
Replace: Always
FileSet: bareos-fileset-bitrixvm-mysql
Backup Client: bitrixvm
Restore Client: bitrixvm
Format: Native
Storage: bareos-server-sd
When: 2016-10-16 11:26:54
Catalog: bareos-server
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): yes

Подтверждаем задачу через yes, командой mod можно отредактировать параметры восстановления перед началом, в том числе и сменить директорию для восстановления. Далее задаче назначается JobId.

По команде status dir можно увидеть состояние восстановления. Как видим все прошло успешно. После этого можно переходить на удаленный клиент, и в папке /tmp обнаружим восстановленный файл dump.sql.

В заключении можно сказать, что Bareos активно развивается, имеет в своем арсенале множество полезных функций, которые остались за пределами этой статьи, а наличие плагинов, которые могут расширить функционал также оказывают положительное впечатление (резервное копирование MS SQL, плагины для хранения данных на Ceph, Gluster, бэкап LDAP).

Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка

Источник