Уже многие годы open source версия Bacula является популярным решением для управления процессов «создания резервных копий, восстановления и верификации компьютерных данных» в сетях с различными компьютерами, операционными системами и запоминающими устройствами. Благодаря модели клиент-сервер, Bacula используется как на отдельных компьютерах, так и на предприятиях, состоящих из сотен элементов.

Впервые open source версия Bacula вышла в 2002 году и быстро получила поддержку у общества. В последнее время разработке бесплатной версии Bacula все меньше уделяется внимания. Новые добавления в общедоступный проект Git совершаются лишь раз в несколько месяцев, в то время как разработчики работают над коммерческой версией Bacula Enterprise Edition, которая не открыта для общего доступа.

В 2010 году Марко вам Виринген (Marco van Wieringen), уже давно занимающийся разработкой Bacula, стал поддерживать улучшения и чистки кода, которые либо не были приняты, либо были предложены для коммерческой версии в отдельном репозитории Git. Исходя из этого, некоторые бывшие члены команды разработчиков Bacula приняли решение продолжать разработку независимого продукта Bareos.

Первым стабильным релизом был Bareos 12.4, который вышел в апреле 2013 (номер версии обозначает год и квартал объявления «feature freeze»). В настоящее время существует бета версия 13.2. 25 сентября 2013 года на конференции Open Source Backup Conference, которая ранее называлась Bacula Conference, проект Bareos был представлен заинтересованной публике.

Перед тем как начать работать с Bacula или Bareos либо размышлять о тестовой установке, вам следует взглянуть на то, как эти инструменты функционируют (Рисунок 1).

Рис. 1. Структура простой Bacula/Bareos

В состав основной структуры всегда входят управляющий блок, Директор создания резервной копии (Backup Director), один или несколько Серверов Хранения (Storage Daemon), а также Службы файлов (File Daemons) на клиентских компьютерах, для которых необходимо создать резервные копии.

Службы Файлов отвечают за создание резервной копии данных с клиентов или же за повторное восстановление данных на клиенте. Эта служба постоянно запущена на клиентах и выполняет команды Директора.

Директор – это контроллер, на котором находится вся логика и большинство настроек. В файле конфигурации указывается следующая информация:

• Конфигурация базы данных
• Все клиенты системы и способ обращения к ним
• Файлы, для которых необходимо создать резервную копию (FileSet)
• Конфигурация плагина
• Предыдущие и последующие задачи (т.е. программы, которые будут запущены до либо после выполнения резервного копирования, например, запуск или остановка служб)
• Пул памяти и носителей, его свойства и период хранения
• Расписание выполнения резервного копирования
• Адреса сообщений
• Задачи и их значения по умолчанию

Просто определить хранилище, FileSet и клиента недостаточно. Данные компоненты объединены задачами, которые определяют, что где находится и когда нужно создать резервную копию.

Период хранения резервной копии данных определяется периодами Хранения Файла (File Retention), Хранения Задачи (Job Retention) и Хранения Тома (Volume Retention). Для осуществления контроля над периодами хранения имеет смысл пользоваться только Хранением Тома, так как перекрытие нескольких опций хранения может привести к неожиданным результатам.

Хранение Тома определяется для каждого пула. При определении нескольких пулов, вы также можете указать различные периоды хранения, например, для различных систем или различных типов резервного копирования (к примеру, полное, дифференциальное или инкрементное). Указанные периоды являются минимальными периодами хранения.

Больше удобства в использовании

Одной из задач в разработке Bareos являлось максимальное уменьшение трудностей для начинающих пользователей. Так как пользователей обычно поражают опции настройки, проект Bareos предлагает пакет репозиториев для популярных дистрибутивов Linux и Windows. Также для Windows предлагаются дополнительные пакеты для решения по управлению ПО OPSI. Все версии созданы автоматически с использованием собственного экземпляра Open Build Service (OBS). В отличие от Bacula.org, где выложен исходный код, двоичные файлы Windows доступны только за деньги.

Необходимо лишь добавить соответствующий репозиторий для того, чтобы установить сервера Bareos на Linux. Bareos поддерживает три типа серверных баз данных: MySQL, PostgreSQL и SQLite. SQLite следует использовать лишь для тестовых установок.

В дальнейшем большая часть усилий по оптимизации будет направлена на PostgreSQL соединение. Чтобы убедиться, что нужный сервер базы данных действительно установлен, необходимо выбрать пакеты bareos и bareos-database-postgresql (или bareos-database-mysql).

База данных должна быть установлена отдельно. Это позволяет запускать базу данных на компьютере, а не на самом сервере Bareos.

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

При первичной установке Bareos, программа вносит свои файлы конфигурации с определенными значениями в папку /etc/bareos. После того, как установка завершится, администратору необходимо инициализировать базу данных и запустить службы (Листинг 1).

Листинг 1: Запуск Служб

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

service bareos-dir start
service bareos-sd start
service bareos-fd start

При автоматической настройке резервное копирование производится на диск (в /var/lib/bareos/storage). Bareos совершает резервное копирование на диск точно так же, как и в ленточную библиотеку, т.е. файлы создаются в /var/lib/bareos/storage, каждый файл соответствует ленте. Преимуществом данного метода является то, что здесь применяются универсальные правила и периоды хранения обрабатываются одинаково как для лент, так и для дисков. Максимальный размер файла и максимальное количество файлов определяется Директором в пуле ресурсов (т.е. в файле /etc/bareosbareos-dir.conf).

Для создания виртуальной ленты нужно запустить консоль bconsole, который сразу же выведет на экран символ * . После ввода label и присвоения имени (в данном примере это file1), нажмите 2 для определенного пула File (Листинг 2).

Листинг 2: Разметка виртуальной ленты

*label

Automatically selected Storage: File

Enter new Volume name: file1

Defined Pools:

 1: Default

 2: File

 3: Scratch

Select the Pool (1-3): 2

Connecting to Storage daemon File at bareos:9103 ...

Sending label command for Volume "file1" Slot 0 ...

  3000 OK label. VolBytes=186 Volume="file1" Device="FileStorage" (/var/lib/bareos/storage)

Catalog record for Volume "file1", Slot 0 successfully created.

Requesting to mount FileStorage ...

3001 OK mount requested. Device="FileStorage" (/var/lib/bareos/storage)

*

Команда status director позволяет просматривать запланированные задачи (Листинг 3).

Листинг 3: Отображение Состояния

*status director

Scheduled Jobs:

Level  Type Pri Scheduled  Name  Volume

=====================================================

Incremental     Backup 10 18-Jul-13 23:05 BackupClient1 file1

Full            Backup 11 18-Jul-13 23:10 BackupCatalog file1

...

Время выполнения резервного копирования указано в файле конфигурации: 23:05 (BackupClient1: файловая система) и 23:10 (BackupCatalog: резервное копирование самой базы данных). Вы можете выполнить тестовое резервное копирование, запустив компанду run и указав только нужного клиента. Результат можно просмотреть с помощью команды status director (Листинг 4).

Листинг 4: Состояние Директора

*status director

...

Terminated Jobs:

 JobId Level Files Bytes Status Finished Name

=====================================================

 1 Full 135 6.679 M OK 18-Jul-13 16:00 BackupClient1

 2 Incr  0  0       OK 18-Jul-13 16:01 BackupClient1

...

Команда status scheduler показывает запланированные задачи, а status scheduler days = 365 – все задачи, запланированные на год.

Улучшения

Кроме установки, администратору Bareos упрощают жизнь и несколько других улучшений: любой человек, которому когда-либо приходилось работать с файлами конфигурации Bacula, будет рад услышать, что почти все стандартные настройки имеют разумные значения. В отличие от Bacula, Bareos также поддерживает установки для строковых параметров, а это значит, что больше не нужно волноваться о вводе директив Pid Directory и Working Directory в конфигурацию Службы файлов клиента. Bareos задает нужные значения для определенных платформ при создании пакетов.

В системах Windows легко можете создать резервную копию не только одного, но и нескольких соединенных жестких дисков (Windows Drive Discovery). Однако данная функция доступна лишь в коммерческой версии. Вызов службы Volume Shadow Copy Service (VSS) позволяет автоматически обнаруживать все жесткие диски Windows.

Упрощена работа с ленточными библиотеками. Теперь ленты можно перемещать из одного слота в другой с помощью bconsole. Кроме того, к любым существующим слотам Импорта/Экспорта можно обратиться, используя команды import или export. Монитор, расположенный в трее (небольшая иконка в системном трее на панели задач) запускается как в Windows, так и в Linux. Мигание иконки означает, что в данный момент в системе выполняется резервное копирование.

Если копирование выполнить не удалось, то вы легко можете запустить задачу с точно такими же параметрами:

*rerun jobid=id

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

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

Комплексные Среды

Иногда подсчёт размера резервной копии может вызвать трудности. С одной стороны, можно исключить некоторые типы данных в списке файлов, которые описывает резервную копию. Или же можно исключить файлы, размер которых превышает определенное значение. Как бы то ни было, исключение не дает гарантии, что клиент не накопит большое количество данных для резервного копирования.

В Bareos имеется клиентская квота, которая позволяет определять общий объем данных для копирования для одного клиента. Кроме того, в первое время вы можете применять мягкие квоты и периоды отсрочки, если квота практически использована.

Помните о том, что есть вероятность передачи по сети больших объемов данных, особенно при полном резервном копировании. Следовательно, в данном случае будет полезной функция Bareos устанавливать лимит на максимальную пропускную способность сети для каждого клиента. Следует добавить директиву Maximum Bandwidth Per Job в запись соответствующего клиента в /etc/bareos/bareos-dir.conf.:

Client {

 Name = client2-fd

 Address = client2

 Password = "secret"

 Maximum Bandwidth Per Job = 512 k/s

}

Важной инновацией является прямая поддержка NDMP (Network Data Management Protocol), стандартного протокола резервного копирования таких крупных NAS устройств, как NetApp. Bareos версии 14.2 поддерживает полное резервное копирование и восстановление, но функция восстановления отдельных файлов всё еще тестируется.

Был создан новый плагин для создания резервных копий баз данных Microsoft SQL Server, который поддерживает полное, инкрементальное и дифференциальное копирование; он также находится на стадии тестирования.

В планах выпустить проект по созданию резервных копий виртуальных машин с помощью Vmware vStorage API. Уже предприняты первые шаги по его разработке.

Задачи копирования

Ленты резервного копирования всё еще являются способом резервного копирования данных. Однако создание резервных копий на диске также имеет свои преимущества. Поэтому часто данные подходы комбинируют: широкое распространение получило резервное копирование Disk-to-disk-to-tape (D2D2T). При использовании данного метода, данные сначала сохраняются на диск, затем перемещаются на ленту с помощью задачи Migration или Copy.

До версии Bareos v13.2 задачи Migration и Copy поддерживались лишь Сервером хранения (Рис. 2).

Рисунок 2: Ранее копирование могли выполнять лишь Серверы хранения

Данное ограничение было снято в Bareos v13.2 – теперь Серверы хранения могут обмениваться данными (Рисунок 3).

Рисунок 3: Сейчас копирование возможно между различными Серверами хранения в сети

Вы можете создавать резервные копии данных из разных зон брандмауэра. В данном случае можно изменять свойства данных так, чтобы они хранились без сжатия на первом Сервере хранения, но компрессировались на втором, что позволяет разрабатывать различные сценарии, как, например, backup-to-disk-to-cloud.

Пассивные клиенты

Чаще всего брандмауэры создают проблемы при настройке среды для резервного копирования. При нормальном соединении в среде Bareos/Bacula Директор Резервного копирования установил бы соединение с клиентом и указал ему, что и куда нужно сохранить. Он также соединяется с Сервером хранения резервных копий и говорит ему принять и сохранить данные клиента. И, наконец, клиент устанавливает реальное информационное соединение с Сервером хранения и передает ему данные.

В случае, если клиент находится за брандмауэром, фильтрация пакетов и трансляция сетевых адресов (NAT) в брандмауэре могут затруднить соединение клиента с Сервером хранения или вообще сделать его невозможным. Таким образом, проблематичным соединением является реальное информационное соедиинение между клиентом и Сервером хранения (Рисунок 4).

Рисунок 4: Ранее информационное соединение с Сервером хранения устанавливал клиент

Начиная с Bareos 13.2, данное поведение можно изменять. С помощью опции Passive client вы указываете, что все соединения должны исходить от компонентов сервера. Таким образом, клиенту требуется лишь принять соединения. Сам процесс установления соединения между Директором и клиентом, а также между Директором и Сервером хранения остается неизменным, но реальное информационное соединение инициируется уже не клиентом, а Сервером хранения. После того, как соединение установлено, клиент отправляет данные Серверу хранения (Рисунок 5).

Рисунок 5: Пассивный клиент: Сервер хранения выступает инициатором информационного соединения с клиентом

Кроме решения проблем с брандмауэром, такой метод имеет ещё одно преимущество: так как пассивный клиент не устанавливает никаких информационных соединений, здесь не требуется разрешение имен. На практике разрешение имен всегда причиняло неудобства при использовании обычного метода.

Безопасность

Что касается безопасности, то Bareos использует уже известные меры безопасности Bacula, такие как:

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

Кроме того, в Bareos были добавлены некоторые более интересные функции по обеспечению безопасности: к примеру, сейчас Вы можете выбрать метод програмного шифрования. Ранее использовался лишь AES. Сейчас же также доступны AES128, AES192, AES256, CAMELIA128, CAMELIA192, CAMELIA256, AES128HNACSHA1, AES256HNACSHA1 и Blowfish.

В дополнение к выбору метода шифрования в ПО, также можете прямо использовать аппаратное шифрование в магнитных лентах LTO. Так как шифрование LTO4 является частью стандарта LTO, то данная опция доступна на всех лентах. Шифрование магнитных лент основывается на аппаратной поддержке и никак не влияет на скорость создания резервной копии.

Использовать аппаратное шифрование LTO или нет – решать вам. Этот вариант особенно полезен тем, кто хочет передать кому-либо свои накопители, но не желает, чтобы третьи лица смогли прочитать их содержимое. Опция пассивного клиента, о которой я рассказывал ранее, также предоставляет повышенную безопасность: поскольку больше нет необходимости устанавливать соединение с Сервером хранения, брандмауэры могут предотвратить все соединения, входящие в сеть, в которой осуществляется резервное копирование.

Ранее вы могли посылать произвольные команды клиенту через Директора. В число таких команд входили backup (запустить резервное копирование), restore (выполнить восстановление), verify (запустить задачу сканирования для синхронизации системных и зарезервированных данных), estimate (вычислить объем зарезервированных данных) и runscript (запустить скрипт на системе клиента).

Сейчас можете воспользоваться директивой Allowed JobCommand для фильтации этих команд на клиенте. Команды, которые будут запрещены, не будут приниматься клиентом и не будут выполняться.

Запуск скриптов на системе, резервное копирование которой будет производиться, представляет особую угрозу безопасности. Если вы не можете полностью запретить этот сценарий с помощью Allowed JobCommand, есть возможность указать с помощью Allowed ScriptDir директорию, в которой должны размещаться скрипты и команды. Команды, которые не находятся в данной папке, не будут выполняться.

Интеграция

Должна быть возможность максимально эффективно распределения зарезервированного клиента на клиентские системы, а также его запуска с наименьшим сопровождением, особенно если объединены разные платформы. Поэтому Bareos также поддерживает старые клиентские версии и Службы файлов Bacula, начиная с версии 2.0 (с 2007 года).

В средах Univention Corporate также есть версия Bareos для Univention App Center. Используя UCS интерфейс, Вы можете указать, выполнять резервное копирование компьютера или нет. Конфигурация сервера Bareos генерируется с учётом Вашего выбора, а затем идёт подготовка конфигурации клиента.

Bareos также предоставляет пакеты для open source решения для управления ПО Windows OPSI. Эти пакеты могут быть установлены на OPSI сервер, им можно задать необходимые настройки, а затем раздать на все подсоединенные системы Windows. С помощью OPSI JSON-RPC интерфейса скрипт создает необходимую конфигурацию Директора Bareos.

Чтобы завершить базовую настройку ПО, Bareos использует стандартный инсталлятор Windows, который устанавливает пароли и даже открывает брандмауэр Windows. Служба файлов и монитор в трее настроены таким образом, что они сразу же начинают работать.

Очень хорошей системой для экстренного восстановаления компьютеров с Linux является проект Relax-and-Recover (REAR). Данный проект использует двусторонний подход. После установки на систему, которую необходимо зарезервировать, команда

sudo /usr/sbin/rear -v mkrescue

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

sudo /usr/sbin/rear -v mkbackup

(например, в общую NFS папку).

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

Гарантия качества

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

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

• Тесты сборок, основанные на Travis
• Регрессионные тесты, в основе которых находится CDASH
• Тесты различных платформ, основанные на Jenkins и виртуальных машинах

Каждое изменение в GitHub автоматически запускает процесс сборки в репозитории Travis CI Bareos. Репозиторий представляет из себя место, где компилируется исходный код, запускаются службы, выполняются процессы создания резервной копии и восстановления. Он проверяет функционирование Bareos после каждого изменения. Дальнейшие тесты выполняются в регрессионной системе тестирования CDASH. В настоящий момент примерно 130 различных тестов проверяют особые функции Bareos.

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

Новый релиз создаётся лишь тогда, когда пакеты, разработанные для Bareos на сервере Open Build Server, успешно прошли и тест на Jenkins. В этом тесте пакеты для различных платформ тестируются на соответствующих виртуальных машинах. На каждой платформе автоматически проверяются инсталляция пакета, резервное копирование данных и процесс восстановления.

Пакеты Windows создаются с использованием OBS и кросскомпиляции. Результатом является Windows Installer и пакеты OPSI.

Будущее

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

Другим положительным аспектом является то, что Bareos разрабатывается в полностью открытой среде. Несмотря на то, что Bareos GmbH & Co KG предлагают коммерческие подписки и поддержку, все дополнения и новые функции разрабатываются в открытом проекте GitHub.

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

Отдельный проект занимается разработкой API для конфигурации, чтобы обеспечить беспроблемное изменение некоторых настроек во время работы программы (например, добавление клиентов). А такие пользовательские веб-интерфейсы, как Webacula, смогут легко расширить свою функциональность.

Авторы

Йорг Штеффенс сотрудничал с Linux в качестве консультанта в SUSE Linux AG с 1995 года, также с 2004 года он является директором open source консалтинговой компании dass IT GmbH в Кёльне, Германия. В 2012 году он объединися с несколькими давними пользователями Bacula для создания проекта Bareos и основал Bareos GmbH & Co KG.

Филипп Шторц уделяет внимание Linux с 1998, Bacula – с 2007. Профессионально работает с Linux с 2001 года, вначале как консультант в SUSE Linux AG, а с 2004 года как сооснователь dass IT GmbH в Кёльне. Его книга о Bacula была опубликована издательством электронных книг Open Source Press в 2012 году. Со времени основания проекта Bareos и одноименной компании он и Марко ван Виринген посодействовали техническому развитию Bareos.

Йорг Штеффенс, Филипп Шторц