Tue 09 April 2013 Category: IT. Tags: bacula

Развертывание Bacula в малом офисе

Введение

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

Из википедии:

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

Бэкап-сервер расположен в виртуальной машине под управлением гипервизора VmWare ESXi 5.1. Операционная система - Ubuntu server 12.10. Физической устройство сервера:

  • Supermicro X9SAE-V
  • Intel Xeon E3 1245v2
  • RAM 32 GB

Система хранения данных (СХД) физически расположена на отдельном сервере под управлением NAS4FREE. Диски подключаются к бекап-серверу как блочные устройства по протоколу iSCSI. Подробно процедура подключения описана в отдельной статье.

В статье будет описана процедура установки и настройки системы bacula, а так же опробовано несколько фронт-эндов.

На момент написания последний стабильный релиз был: 20 February 2013: Bacula 5.2.13

В репозитории убунту: quantal: 5.2.6, raring: 5.2.6

Разница между последним стабильным релизом и версией в репозитории составляет около 7 месяцев разработки: http://www.bacula.org/en/?page=news

Устройство системы bacula

Bacula Application Interactions

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

  • Director Daemon (DD) (порт 9101) — это центральный элемент системы, осуществляющий управление её остальными компонентами. В его задачи входит управление процессом резервирования/восстановления данных, обеспечение интерфейса управления для администраторов и многое другое. Говоря проще – это диспетчер, который инициирует все процессы и отслеживает ход их выполнения. Директор осуществляет централизованный контроль и администрирование всего комплекса задач. Планирование и управление заданиями на резервное копирование (Job). Обслуживание Каталога (Catalog) — центральной БД для хранения метаданных.

  • Storage Daemon (SD) (порт 9103) — приложение, отвечающее за чтение/запись данных непосредственно на устройства хранения информации. Принимает управляющие команды от DD, а также резервируемые данные от/к File Daemon.

  • File Daemon (FD) (порт 9102) — клиент выполняющий непосредственное копирование, восстановление и проверку данных по запросу Director. File Daemon должен быть установлен на нужной клиентской машине и он обменивается информацией с Director и Storage Daemon. Также на стороне FD выполняется шифрование резервных копий, если это определено конфигурацией.

  • Bacula Console (BC) — интерфейс администратора сиcтемы. По своей сути, это командный интерпретатор для управления Bacula. Строго говоря, Bacula Console может быть расширена с помощью графических систем управления, которые, как правило, являются всего лишь надстройкой над BC. К таким системам можно отнести Tray Monitor и Bat. Первая устанавливается на компьютере администратора системы и осуществляет наблюдение за работой системы резервирования, а вторая обеспечивает возможность управления посредством графического интерфейса.

  • Catalog — база данных, в которой хранятся сведения обо всех зарезервированных файлах и их местонахождении в резервных копиях. Каталог необходим для обеспечения эффективной адресации к требуемым файлам. Поддерживаются MySql, PostgreSql и SqLite.

  • Tray Monitor — апплет GNOME/KDE/Win32 GUI для показа активности Director, File daemons, Storage daemon в реальном времени.

Такое структурное деление позволяет организовать очень гибкую систему резервирования, когда Storage Daemon разворачивается на выделенном сервере с несколькими устройствами хранения данных. Также Bacula Director может управлять несколькими экземплярами SD, обеспечивая резервирование части данных на одно устройство хранения, а части – на другое.

Установка пакетов

$ apt-get install bacula

Метапакет установит части Bacula - директор, клиент, консоль, common и mysql-бэкенд. В процессе установки нужно задать пароль mySql для mysql-пользователя root.

На вопрос "Configure database for bacula-director-mysql with dbconfig-common?" отвечаем да - установщик сам создаст базы данных.

Установщик спросить нас пароль mySql, введенный чуть раньше, а потом спросит о пароле mysql для базы bacula-director-mysql, или предложить сгенерировать его автоматически, нажав Enter. Я так и поступил.

Далее устанвливем apache и php

$ apt-get install apache2 php5 libapache2-mod-php5 php5-mysql php5-gd php-db gettext

Проверяем /etc/php5/conf.d, чтобы установленные php-моды были включены.

Активируем модуль PHP и mod_rewrite.

$ sudo a2enmod php5
This module already enabled.

$ sudo a2enmod rewrite
Module rewrite installed; run /etc/init.d/apache2 force-reload to enable.
$ service apache2 force-reload

Настройка Bacula

Файлы конфигурации

Каждый конфиг содержит ресурсы типа

Название ресурса {
  ключ = значение
}

В ключах регистр и пробелы полностью игнорируются. Поэтому ключи: name, Name, и N a m e полностью индентичны. Пробелы до и после знака "равно" игнорируются. Если "значение" содержит пробелы, оно должно быть заключено в двойные кавычки, а порбелы должны быть экранированы обратным слешем.

Что бы было проще ориентироваться в конфигурационных файлах, можно выносить часть конфигурации в отдельные файлы. Из оригинального bacula-dir.conf можно удалить ВСЕ ресурсы, заменив их приведенными в статье, КРОМЕ Messages, эти ресурсы я подробно не описывал.

Например вся последующая конфигурация (Pool, File set, Schedule и Job) может быть вынесена в отдельный файл /etc/bacula/conf.d/test.conf, который можно подключить в конфигурацию директора (bacula-dir.conf) следующим образом:

@/etc/bacula/conf.d/test.conf

Картинка с описанием смысла основных ресурсов Bacula

Ресурсы Bacula

Понимание Job

Далее, корневой ресурс - это Job. Он объеденяет другие ресурсы, формируя "задание", которое будет выполнено. В Job подключаются:

  • Storage - описывает, на какой Storage записывать бекап (грубо говоря, это сервер с демоном Storage)
  • Pool - описывает, в какие файлы на Сторадже будет записан данный бекап. См. сноску
  • FileSet - определяет, какие именно файлы надо бекапить с компьютера Client
  • Shedule - расписание, по которому будет выполняться Job
  • Client - описывается клиентский компьютер, с которого будут забираться файлы для бекапа
  • └--> Catalog - в ресурс Client, в свою очередь, подключается ресурс Catalog. Описывает подключение к базе данных (MySQL, PgSQL, SQlite)

Каталог определяет, какая база данных будет содержать список файлов и названия томов, где содержаться бэкапы. Большинство администраторов используют один каталог. Однако, если вы хотите расширить Директор на множество клиентов, множественные каталоги могут быть полезны. Множественные каталоги требуют больше усилий в управлении, потому что вы должны знать, какие данные содержаться в каком каталоге. В настоящий момент, каждый Pool определяется в своем каталоге. Это ограничение будет снято в будущих редизах.

Не уверен в правильности перевода про Каталоги, вот оригинальный текст из мануала: To define in what database to keep the list of files and the Volume names where they are backed up. Most people only use a single catalog. However, if you want to scale the Director to many clients, multiple catalogs can be helpful. Multiple catalogs require a bit more management because in general you must know what catalog contains what data. Currently, all Pools are defined in each catalog. This restriction will be removed in a later release.

Понимание Storage, Pool и Volume

Что такое Storage, Pool и Volume хорошо описано в вики Bacula - Pools, Volumes and Labels

Pools - Volumes - Lables

Итак:

  • Storage - это физический сервер хранения бекапов. Может быть совмещен с Директором. Работает на 9103 порту.
  • Pool - логическое объеденение Томов. Бэкап производится в Pool, а не в Volume. Бакула сама выбирает нужный Том.
  • Volume (Том) - это или физическая лента, или физический файл специального бакула-формата.
  • Label - Прежде чем bacula сможет использовать том (volume), он должен иметь метку (label).

Понимание Retention Period

Есть различные виды периодов хранения данных, поддерживаемых Bacula. Самые важные: File Retention Period, Job Retention Period, Volume Retention Period. Каждый из этих периодов определяет время, когда определенный учет будет вестись в БД Каталога. Из трех периодов File Retention оказывает наибольшее влияние на размер Каталога.

  • File Retention Period - определяет время, когда записи о файлах (не сами файлы!) хранятся в БД. Когда этот период времени истекает и AutoPrune = yes, то Bacula удалит (prune) записи о файлах из БД Каталога, которые старше чем указанный период хранения.  Это затрагивает только записи в БД каталога, но не затрагивает ваши архивные копии. (См. команду консоли retention). 

  • Job Retention Period - отрезок времени, когда записи о Заданиях будут храниться в БД. Все записи о Файлах привязаны к Заданию, которое сохранило эти файлы. Записи о Файлах могут быть удалены, независимо от записей о Заданиях. В этом случае будет доступна информация о выполненных заданиях, но не детальная информация о файлах, которые были скопированы. Обычно, когда запись о Задании удалена, все записи о Файлах будут также удалены. 

  • Volume Retention Period - минимальное время хранения Тома перед его повторным исипользованием. Обычно Bacula никогда не будет перезаписывать Том, содержащий единственную резервную копию файла. В идеальных условиях, Каталог сохранил бы все записи о всех скопированных файлах для всех текущих Томов. Как только Том перезаписан, файлы, которые были забэкаплены на этом Томе будут автоматически удалены из Каталога. С другой стороны, если есть очень большой пул Томов, или Том никогда не перезаписывается, БД Каталога может стать огромной. Чтобы управлять размером Каталога, резервная информация должна быть удалена из Каталога после определенного File Retention Period.  Минимальный период Volume Retention должен быть в вдвое больше интервала ваших Full резервных копий. Это означает, что, если Вы делаете Full резервную копию один раз в месяц, то минимальный период Volume Retention должен быть два месяца.

Bacula Director (BD) bacula-dir.conf

Этот файл содержит ресурсы, определяющие работу сердца системы - Bacula Director. Сокращается до BD - Bacula Director или DD - Director Daemon

Director

Первый ресурс - Director. Его изменять нет нужды, кроме пароля. :

Director {
  Name = bacula-dir                           # Имя директора
  DIRport = 9101                              # Порт который слушает DIR
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"        # Директория, в которой лежат 
                                              # статус-файлы Директора
  PidDirectory = "/run/bacula"
  Maximum Concurrent Jobs = 1                 # Максимальное количество параллельных заданий.
                                              # Не рекомендуется одновременно запускать
                                              # более одного задания
  Password = "director-password"              # Пароль директора (для привилегированной консоли)
  Messages = Daemon                           # Набор настроек для отправки сообщений
  #DirAddress = 127.0.0.1                     # IP указывать не нужно, если директор
                                              # слушает локальный порт
}
Storage

Описывает, как подключиться к демону Storage

Storage {
  # имя хранилища и пароль
  Name = File
  Password = "storage-password"

  # fqdn имя сервера ИЛИ IP
  # Do not use "localhost" here....
  Address = 192.168.0.204

  # порт оставляем стандартный
  SDPort = 9103.

  # имя устройства хранения, которое описано в `bacula-sd.conf`
  Device = iSCSI_Slot4

  # Указывает, устройство хранения - это файл (то бишь - не лента)
  Media Type = File
}
Pool

Ресурс Pool определяет набор томов (том - Volume), которые будут использоваться Bacula для записи данных. Томами могут быть файлы или ленты.

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

Кроме того, можно назначить новый набор Volume'ов на каждую машину, которая должна бекапится. Это легче всего сделать, определив несколько Pool'ов.

Пока непонятно, чем должны отличаться пулы для разных бекапов (full, inc, diff) разных клиентов

Pool {
  # имя пула, указывается в заданиях резервного копирования
  Name = TestPool

  # тип пула (может быть только Backup)
  Pool Type = Backup

  # повторно использовать тома(сначала пишет в 1-ый, потом в 2-ой,
  # потом 3-й, 3-й закончился - снова в 1-й).
  Recycle = yes

  # удалять записи из bacula catalog(из mysql базы бакулы)
  # старше нижеуказанных значений
  AutoPrune = yes

  # Период в течении которого информация о томах(volumes)
  # хранится в базе данных, по истечению периода эта информация удаляется.
  # То есть можно восстановить файлы за Х дней
  Volume Retention = 30 days

  # Максимальный объем тома
  # Тут есть небольшая хитрость - если файл поврежден, данные не могут быть
  # восстановлены, исходя из этого, размер файла должен быть небольшим,
  # но с другой стороны, если у вас закончится место на дисках, нужно будет
  # удалять тома,  по одному за раз, так что размер тома должны быть
  # большими, чтобы избежать необходимости вручную удалять слишком много
  # томов. Обычное значение из различных туторов - десятки гектар.
  Maximum Volume Bytes = 20G

  # максимальное количество томов в пуле
  # Жесткий диск - 3TB, на нем я могу разместить 150 томов по 20G, для
  # запаса ставим 149
  Maximum Volumes = 149

  # с каких символов начинается имя тома. Удобно использовать для каждого
  # клиента свой префикс. Тогда нужно описать столько пулов, сколько
  # клиентов. Если у вас разные пулы для фул и инкрементал бекапов,
  # возможно, вы захотите использовать такие названия, как Full- и Incr-
  LabelFormat = "USER1_volume-"

  # хитрый формат метки тома
  # LabelFormat = "${Pool}-${Level}-${Year}-${Month:p/2/0/r}- \
  # ${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}-${Job}"
  # но имхо это работать не будет, так как старые файлы бакула не будет
  # удалять (не умеет), то есть логика работы - реюз старых файлов (томов),
  # а не их удаление и создание новых

  # ноль (по-умолчанию) означает: "без ограничений на кол-во Заданий,
  # которые могут быть записаны в один Том"
  Maximum Volume Jobs = 1
}

Рекомендуемое значение Maximum Volume Jobs - 1. Из статьи на ibm.com:

Параметр Maximum Volume Jobs рекомендуется установить в значение 1 (один). Это будет означать, что в рамках одного носителя данных могут быть размещены резервные данные, полученные в ходе выполнения только одного задания. <...> если мы говорим о файлах, то желательно придерживаться правила "один файл – одна копия", т.е. в одном файле Bacula должны храниться резервные данные, которые были сформированы в рамках выполнения одного задания. Для каждого последующего будут создаваться новые файлы.

Другой важный аспект Пула - это то, что он содержит значения атрибутов по умолчанию (Maximum Jobs, Retention Period, Recycle flag, ...), которые будут присваиваться новому Тому, когда он будет создан. Это избавляет вас от необходимости отвечать на большое количество вопросов, маркируя (labeling) новый Том (Volume). Каждый из этих признаков может позже быть изменен для Тома командой update

Ротацию томов можно настроить двумя способами. Первый, классический способ, разработанный для удобной работы с лентами, состоит в повторном использовании одних и тех же томов при достижении определенных условий. В первую очередь это устанавливается директивой ресурса Pool Recycle = yes. При такой схеме, когда закончится наше количество томов (имеющихся в наличии лент) Maximum Volumes = nnn, Директор снова станет использовать самый старый том.

Другой же способ заключается в удалении старых томов, без повторного использования. При использовании этой схемы мы указываем Recycle = yes, а директиву Maximum Volumes опускаем. Время хранения томов регулируется параметром Volume Retention. Мне кажется, такой способ более прост для осмысления и управления, а так же позволяет использовать индивидуальние метки для каждого тома (см. выше). При таком способе нужно более внимательно подходить к планированию заполнения дискового массива, так как сама Bacula не проверяет количество свободного места в Storage. Так же следует иметь ввиду, что Bacula не умеет удалять тома, так что об этом нужно позаботится самостоятельно, например после каждого задания запускать bash или python скрипт.

FileSet

Описывает, какие файлы будут бекапится с клиента. У каждой клиентской машины будет, скорее всего, свой FileSet

FileSet {
  Name = "fs-swasher"
  Include {
    Options {
      signature = MD5
      Compression=GZIP
    }
    # При наличии в пути пробелов нужно использовать двойные кавычки
    # Слэш нужно всегда экранировать, или можно использовать бэкслэш.
    File = "C:/Users/Swasher/Desktop"
    File = "C:\\Users\\Swasher\\Мои документы"
  }
  Exclude {
    File = "*.mp3"
    File = "*.avi"
    File = "*.wmv"
  }
}

Тестирование Fileset-ов

Если вы хотите убедиться в том, что ваши FileSet действительно работают, и ваши правила исключения работают правильно, вы можете проверить его с помощью команды estimate в консоле.

В качестве примера, предположим у нас есть такой FileSet:

FileSet {
  Name = Test
  Include {
    File = /home/xxx/test
    Options {
      regex = ".*\\.c$"
    }
  }
}

Вы должны добавить тестовые файлы в директорию /home/xxx/test и затем использовать следующую команду в консоле бакулы:

$ estimate job=<any-job-name> listing client=<desired-client> fileset=Test

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

Schedule

Описывает, КОГДА будет запускаться Задание (Job) по выполению бекапа. Так же скорее всего будет свой для каждого клиента.

Schedule {
  Name = "sch-swasher"
  #  When to do the backups, full backup on first sunday of the month,
  #  differential (i.e. incremental since full) every other sunday,
  #  and incremental backups other days
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}
Client

Описывает физическую машину, которая будет бекапится

Client {
  # имя
  Name = fd-swasher

  # ip адрес клиента
  Address = swasher

  # порт, который клиент слушает
  FDPort = 9102

  # имя mysql базы данных Bacula
  Catalog = MyCatalog

  # пароль для FileDaemon
  Password = "client-password"

  # период, в течении которого информация о ФАЙЛАХ
  # хранится в базе данных, по истечению периода эта информация
  # удаляется(но не сами данные!!).
  File Retention = 45 days.

  # тоже самое, только для ЗАДАНИЙ
  Job Retention = 90 days.

  # удалять записи из каталога(бд mysql) старше вышеуказанных значений
  AutoPrune = yes.
}
Catalog

Здесь указываем путь и учетные данные для доступа к базе данных. На Ubuntu создается автоматически во время установки.

Catalog {
  Name = MyCatalog
  dbname = "bacula"; DB Address = ""; dbuser = "bacula"; dbpassword = "db-password"
}
JobDefs

Этот ресурс хранит задачу-шаблон, которую потом могут расширять и изменять Job-русурсы

JobDefs {                     # Дефолтное задание, "шаблон"
  Name = "DefaultJob"         # Имя задания
  Type = Backup               # Тип (backup, restore и т.д.)
  Level = Full                # Уровень бэкапа (Full, Incremental, Differential и тп)
  Client = fd-swasher         # Имя клиента
  FileSet = fs-swasher        # Набора файлов для сохранения.
  Schedule = "WeeklyCycle"    # Расписание
  Storage = File              # Файловое хранилище
  Messages = Standard         # Поведение уведомлений
  #Pool = File                 # Пул, куда будем писать бэкапы. Если мы хотиим сделать отдельный пул
                              #для каждого клиента, или использовать префиксы, тогда пул указывается в Job'е
  Priority = 10               # Приоритет. Давая заданиям приоритеты
                              # от 1 (max) до 10 (min), можно регулировать
                              # последовательность выполнения.
  Write Bootstrap = "/var/db/bacula/%c.bsr" # Файл хранит информацию откуда извлекать
                                            # данные при восстановлении (???????????????)
}

Разобраться, как работает Bootstrap файл - он каждый раз перезаписывается? Ротируется? Что такое %c выше и т.д

По умолчанию, одновременно запускается только 1 задание, остальные ставятся в очередь. Это регулируется параметром Maximum Concurrent Jobs = number, которое офф. мануал не рекомендует ставить больше еденицы.

Job

Собирает вместе все ресурсы и создает задание по бекапу.

# Test Backup
Job {
  # имя задания
  Name = "TestBackup"

  # Используем шаблон
  JobDefs = "DefaultJob"

  # имя клиента
  Client = fd-swasher

  # имя файл-сета(там рассказано что бекапить, а что не бекапить)
  FileSet = fs-swasher

  # имя пула(для разных клиентов разные пулы томов(volume) куда пишутся сами бекапы)
  Pool = TestPool

  # скрипт запускающийся ДО выполнения задания (путь до скрипта  -
  # это путь НА КЛИЕНТЕ!)
  #ClientRunBeforeJob = "/root/sh/before_bg_db_backup.sh"

  # скрипт запускающийся ПОСЛЕ выполнения задания
  #ClientRunAfterJob = "/root/sh/after_bg_db_backup.sh"

  # в этом файле содержится информация о том, какие файлы должны будут
  # востанавливаться, на каком вольюме находятся файлы,
  # где конкретно они находятся - это очень важные файлы, их нужно бэкапить.
  # Этот файл позволит восстановить копии в случае каких-либо проблем с sql-каталогом
  Write Bootstrap = "/mnt/bacula/bsr-files/bgbilling.bsr"
}

Шаблон восстановления

# Стандартный шаблон восстановления, который может изменен консольной программой
# Только одна такая работа необходима для всех Работа/Клиентов/Хранилищ...
# [единственное я изменил путь к Where для клиента thor.kmps.local-fd
# это куда Bacula будет складывать восстановленные из архивов файлы]
Job {
  Name = "RestoreFiles"
  Type = Restore
  Client=thor.kmps.local-fd
  FileSet="Full Set"
  Storage = File
  Pool = Default
  Messages = Standard

  ## Это путь НА КЛИЕНТЕ, куда будут восстановлены файлы. Если он пустой 
  ## или /  - файлы восстановятся на свои места и перазапишут (!!!) существующие файлы
  ## Должен начинаться со слеша. На windows соотв. c:\bacula
  Where = /bacula
}

Для восстановления я применяю ту же схему - общие свойства Job'а описаны в bacula-dir.conf в JobDef, а настройки, индивидуальные для каждого клиента (Name, Client, FileSet, и Pool) - в подключаемом конфиге в Job'е

Messages

Далее идут ресурсы сообщений (Messages). Логи могут высылаться на почту. Прописываем почтовый адрес, на который будут высылаться сообщения. Используется в два ресурса - Standart и Daemon

# Reasonable message delivery -- send most everything to email address
# and to the console
Messages {
  Name = Standard
      #mail = root = all, !skipped
      mail = root@domen.ru = alert,error,fatal,terminate, !skipped 
}

# Message delivery for daemon messages (no job).
Messages {
  Name = Daemon
  #mail = root = all, !skipped
  mail = root@domen.ru = alert,error,fatal,terminate, !skipped 
}

Конфигурационный файл BD на этом завершен.

Storage Device (SD) bacula-sd.conf

Переходим к конфигурации SD — описанию файла bacula-sd.conf

Storage Daemon
Storage {
  # имя для SD
  Name = bacula-sd

  # биндится на этом ip
  SDAddress = storage.dir

  # порт стандартный
  SDPort = 9103

  # рабочая директория процесса(для статус файлов)
  WorkingDirectory = "/var/lib/bacula"

  # pid будет здесь
  Pid Directory = "/var/run/bacula"

  Maximum Concurrent Jobs = 20
}
Director

Ресурс Director(связь с BD описанном в конфиге bacula-dir.conf)

Director {
  # имя BD, того самого, который был описан ранее
  Name = bacula-dir
  # пароль
  Password = "storage-password"
}
Device

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

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

Параметр Media Type определяет произвольное уникальное имя, которое будет использоваться Bacula при восстановлении данных. Согласно ему определяется устройство хранения, с которого будет производиться восстановление. Если вы храните резервные копии в файлах, то для КАЖДОЙ секции Device должен быть задан уникальный Media Type.

Device {
  # имя
  Name = FileStorage

  # тип
  Media Type = File

  # директория где лежат файлы этого устройства(тома, volumes)
  Archive Device = /mnt/raid/bacula

  # Автоматическое маркирование носителей информации.
  # новые тома будут обзываться согласно настроек Pool'а
  LabelMedia = yes

  # для устройства типа File должно быть yes
  Random Access = Yes

  # если устройство открыто, использовать его
  AutomaticMount = yes

  # возможно ли извлечение устройства хранения. Необходимо для Tape, CD и т.д. Для файлов устанавливается в значение No.
  RemovableMedia = no

  # открывать только тогда, когда стартует соответствующие задание
  AlwaysOpen = no
}
Messeges

Ресурс Messeges

Messages {
  # имя
  Name = Standard 
  # отправлять  DD = имя директора  = слать все
  director = bacula-dir = all
}

Console - bconsole.conf

Конфигурационный файл bconsole.conf, предоставляющий доступ в консоль Bacula. 

Director {
  Name = bacula-dir
  DIRport = 9101
  address = bacula.local
  Password = "director-password"
}

File Daemon (FD) bacula-fd.conf и Windows-Клиент

Клиент, кстати, запускается в качестве службы достаточно просто, достаточно указать соответствующую опцию: "C:\Program Files\Bacula\bin\bacula-fd.exe" /service -c "C:\Documents and Settings\All Users\Application Data\Bacula\bacula-fd.conf" Отключить функционал запуска клиента в качестве службы не сложнее: "C:\Program Files\Bacula\bin\bacula-fd.exe" /remove

Установка на клиентские машины включает в себя следующие компоненты:

  • Bacula File Backup Service - служба windows, которая собственно и является File Daemon'ом. Конфиг - .conf
  • Bat - win-GUI административный интерфейс, подключается к Director'у. Конфиг - bat.conf
  • bconsole - аналог консоли bacula, подключается к Director'у. Конфиг - bconsole.conf
  • Tray Monitor - windows-утилита мониторинга BD, FD, SD. Имеет отграниченый доступ. Конфиг - tray-monitor.conf

На простые компьютеры, которые нужно архивировать, нужды устанавливать Bat, bconsole или TrayMonitor нет. Это исключительно инструменты администратора.

Так же отмечу, что я использовал более свежую сборку FD, чем Директора (director 5.2.6, а FD 5.2.13). Проблем с совместимостью замечено не было, но зато можно использовать обновленный Bat.

Установку начинаем со скачивания бинарников http://sourceforge.net/projects/bacula/files/Win32_64/ Имеются версии для Windows x32 и x64. Скачиваем, запускаем. Во время установки инсталлятор попросит ввести данные о Bacula Director.

Вводим параметры

Вводим соответствующие параметры из bacula-dir.conf/director. Если все правильно ввести, инсталятор подставит нужные параметры, и bat, bconsole будут работать "из коробки". Далее установщик спросит про сохранение конфига machinename-fd.conf. Этот конфиг содержит ресурс Client, который скопировать на сервер и подключить в Директора. В принципе, нам из него нужен только пароль, остальное пропишем на сервере руками.

После установки обращаем внимание на следующие моменты.

Все экзешники должны запускаться с явно указанным конфигом. Для этого установщик создает ярлыки в меню windows, в свойствах ярлыком можно увидеть, какие именно конфиг-файлы используются.

Bat

Начнем с запуска Bat - Bacula Admin Tool. Для него используется конфиг C:\Program Files\Bacula\bin32\bat.conf. Все значения копируем из секции director конфига bacula-dir.conf

Director {
  Name = bacula-dir
  DIRport = 9101
  address = bacula.local
  Password = "director-password"
}

Настройки этого файла файла достаточно для запуска Bat.

bconsole

Далее настраиваем bconsole. Она использует Файл настроек C:\Program Files\Bacula\bconsole.conf. Этот файл полностью аналогичен предыдущему, используется пароль от director. Конечно, консоль с таким паролем имеет польный доступ к Бакуле. Возможно создание консолей с ограниченными возможностями.

Настроив конфиг, пробуем запустить ярлык bconsole

Служба Bacula File Backup Service

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

"C:\Program Files\Bacula\bacula-fd.exe" /service  -c "C:\Program Files\Bacula\bacula-fd.conf"

теперь становится очевидно, какой conf-файл используется для File Daemon.

File Daemon

Редактируем файл наструе File Daemon - bacula-fd.conf. Приводим его в соответствие с настройками Director Daemon на сервере. Я организовал структуру конфигов на сервере так, что каждый новые клиент подключается отдельным конфиг файлом.

#
# Default  Bacula File Daemon Configuration file
#
#  For Bacula release 5.2.10 (06/28/12) -- Windows MinGW64
#
# There is not much to change here except perhaps the
# File daemon Name
#

#
# "Global" File daemon configuration specifications
#
FileDaemon {                            # this is me
  Name = alexey-fd
  FDport = 9102                # where we listen for the director
  WorkingDirectory = "C:\\Program Files\\Bacula\\working"
  Pid Directory = "C:\\Program Files\\Bacula\\working"
# Plugin Directory = "C:\\Program Files\\Bacula\\plugins"
  Maximum Concurrent Jobs = 10
}

#
# List Directors who are permitted to contact this File daemon
#
Director {
  Name = bacula-dir
  Password = "ilANXUAMbm1x_C8-t91BGgjQt6FxGOJv02"
}

#
# Restricted Director, used by tray-monitor to get the
#   status of the file daemon
#
Director {
  Name = bacula-mon
  Password = "password"
  Monitor = yes
}

# Send all messages except skipped files back to Director
Messages {
  Name = Standard
  director = bacula-dir = all, !skipped, !restored
}

Выше я привел оригинальный конфиг клиента. Теперь перечислю, что откуда нужно взять и откорректировать:

FileDaemon {
  Name = имя из bacula-dir.conf секция Client
}
Director { #имя и пароль директора
  Name = имя из bacula-dir.conf секция Director
  Password = пароль из bacula-dir.conf секция Client
}
Director { # связь read-only для консоли
  Name = имя из bacula-dir.conf секция Console
  Password = пароль из bacula-dir.conf секция Console
  Monitor = yes
}

Связи паролей несколько запутанны, разработчики даже нарисовали картинку по этому поводу: Связи в конфигах Бакулы

После изменения настроек нужно перезапустить службу Bacula File Backup Service.

Tray monitor

Tray monitor предназначен только для наблюдения за происходящими процессами, поэтому он запускается с минимальными привелегиями. Файл конфигурации - C:\Program Files\Bacula\bin32\tray-monitor.conf. Файл этот имеет четыре ресурса - Monitor, Client, Storage и Director, для наблюдения за соответсвующими службами. Опишу, откуда что берется.

  • секция Monitor - Обязательная секция. Берем имя и пароль из bacula-dir.conf секция Console (ограниченная консоль)
  • секция Client - имя, порт, пароль из /etc/bacula/conf.d/user.conf. Адрес обычно localhost.
  • секция Storage - Имя, адрес, порт от StorageDaemon. Пароль от ограниченного директора из bacula-sd.conf с опцией Monitor = yes
  • секция Director - Имя, адрес, порт от DirectorDaemon.
Проверяем

Заходим в bconsole и проверяем, нормально ли Директор конектится к Клиенту

#вывод информации о соеденении
*status client=masha-fd
#вывод списка файлов для бекапа
*estimate client=masha-fd listing

Последнаяя команда выдаст важную информацию - объем бекапа с данного клиента. Эта информация - точка отсчета при планировании стратегии бекапов и времени хранения.

Добавление нового клиента

Для добавления нового клиента необходимо добавить в конфиг bacula director инклуд нового файла, который будет содержать следующие ресурсы:

  • Client, в который прописываем имя, ip и пароль
  • Pool - нужно описать отдельный Pool для каждого клиента, если мы хотим видеть, какому клиенту принадлежит том: Ivanov-****
  • FileSet - список файлов на клиенте, которые будем архивировать
  • Job - два русурса Job, на архивацию и на восстановление

Тестирование conf файлов

You can test if your configuration file is syntactically correct by running the appropriate daemon with the -t option. The daemon will process the configuration file and print any error messages then terminate. For example, assuming you have installed your binaries and configuration files in the same directory.

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

$ cd <bacula-conf-directory>
bacula-dir -t -c bacula-dir.conf
bacula-fd -t -c bacula-fd.conf
bacula-sd -t -c bacula-sd.conf
bconsole -t -c bconsole.conf
bwx-console -t -c bwx-console.conf
bat -t -c bat.conf
su <normal user> -c "bacula-tray-monitor -t -c tray-monitor.conf"

Если с конфигами все хорошо, команды завершаться, ничего не выдав.

Ресет системы после тестирования

Если после наших эксперементов нам нужно удалить все тестовые джобы, делаем это так:

$ mysql -u root -p
mysql> drop database bacula;
mysql> quit

$ dpkg-reconfigure bacula-director-mysql

Мы уничтожили базу данных, а затем создали ее вновь. Осталось удалить сами файлы томов.

Восстановление

Вкратце:

  • Восстановление запускается через консоль: restore
  • Запустится мастер, в нем выбираем задачу, клиента и файл-сет
  • Затем нужно добавить файлы в restrore job, чтобы добавить все пишем add *
  • Заканчиваем мастер директивой done
  • Забираем файлы на клиенте, в директории c:\bacula, см Шаблон восстановления

Запуск

Не забудьте создать соответствующие Storage папки и назначить bacula владельцем этих папок.

Заходим в консоль

$ bconsole

и проверяем, все ли работает

status all

Директор должен нормально коннектится к клиентам и к Стораж демону.

Команда принудительного запуска задания - run. Входим в bacula console и запускаем.

Запускаем bacula console и в ней пишем:

$ bconsole
*status client=fd-swasher
Connecting to Client fd-swasher at swasher:9102

fd-swasher Version: 5.2.10 (28 June 2012)  VSS Linux Cross-compile Win64
Daemon started 12-Apr-13 15:09. Jobs: run=0 running=0.
Microsoft Windows 7 Ultimate Edition (build 7600), 64-bit
 Heap: heap=0 smbytes=40,687 max_bytes=69,345 bufs=69 max_bufs=124
 Sizeof: boffset_t=8 size_t=8 debug=0 trace=1 
Running Jobs:
Director connected at: 12-Apr-13 16:33
No Jobs running.
====

Terminated Jobs:
====

Фронтэнды

Webacula

System Requirements

У Webacula довольно обширный список зависимостей, поэтому приведу их:

  • Bacula 3.0 or later
  • Supported MySQL, PostgreSQL and Sqlite databases
  • Zend Framework version 1.8.3 or later
  • Zend Framework is built with object-oriented PHP 5 and requires PHP 5.2.4 or later with PDO extension active. Please see the system requirements appendix for more detailed information
  • Apache and mod_rewrite
  • Installed php-gd package
  • Create separate database "webacula" (script in install/ directory) for use Logbook and Restore Job features
  • Enable JavaScript
  • http://php.net/dom for RSS feed. Installed php-xml package
  • Browser Compatibility.
Скачивем

Забираем webacula с git:

$ cd ~
$ git clone https://github.com/tim4dev/webacula.git

Доустанавливаем Zend и создаем симлинк на него в папке library:

$ apt-get install zend-framework
$ ln -s /usr/share/php/libzend-framework-php/Zend ~/webacula/library/

В последней версии Webacula появился скрипт для проверки наличия необходимых компонентов, лежит в /webacula/install/:

$ php5 check_system_requirements.php

Webacula check System Requirements...

sh: 1: psql: not found
sh: 1: sqlite3: not found
Current MySQL version = 5.5.29  OK

Current PHP version = 5.4.6-1ubuntu1.2  OK

php pdo installed.      OK
php gd installed.       OK
php xml installed.      OK
php dom installed.      OK

php pdo_mysql installed.        OK
Warning. PHP extension pdo_pgsql not installed.
Warning. PHP extension pdo_sqlite not installed.
php-dom, php-xml installed.     OK

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

Права и конфиги

Редактируем конфиг в application/config.ini, настраиваем доступ к базе данных, таймзону, локаль, путь к bconsole, по необходимости другие параметры.

db.config.username = root
db.config.password = пароль-рута-от-mysql
def.timezone = "Europe/Kiev"
locale = "ru"
bacula.bconsole = "usr/sbin/bconsole"

Добавляем пользователя bacula в группу веб-сервера

$ usermod -aG bacula www-data

Устанавливаем необходимые права доступа к bconsole из Apache. В мануале используется путь к bconsole /usr/bin/, но в ubuntu 13.04 там лежит симлинк на /usr/sbin/bconsole. Соответственно, права нужно выдавать ему.

$ chown root:bacula /usr/sbin/bconsole
$ chmod u=rwx,g=rx,o= /usr/sbin/bconsole
$ chown root:bacula /etc/bacula/bconsole.conf
$ chmod u=rw,g=r,o= /etc/bacula/bconsole.conf

Далее, в /etc/sudoers дописываем

www-data ALL=NOPASSWD: /usr/sbin/bconsole

Проверить, запускается ли bconsole от пользователя www-data, можно так:

$ su -l www-data -s /bin/sh -c \
"/usr/bin/sudo /usr/sbin/bconsole -n -c /etc/bacula/bconsole.conf"

Изменяем пароли в файле install/db.conf. Если мы используем root для доступа к MySql (db_user="root), указываем пароль рута.

webacula_root_pwd="пароль-для-входа-в-вебинтерфейс"
db_pwd="пароль-рута-от-mysql"

Далее создаем таблицы Webacula, пользователей и роли:

$ cd install/MySql
$ ./10_make_tables.sh
$ ./20_acl_make_tables.sh
Настройка Bacula

Для просмотра сообщение Job output, нужно внести измнения в bacula-dir.conf:

Messages {
    Name = Standard
    ...
    #catalog = all
    catalog = all, !skipped, !saved
}

и сделать рестарт Bacula Director.

Настройка PHP

Неизвестна необходимость этих изменений, но они есть в официальном Installation Manual. Увеличить значения в /etc/php.ini:

memory_limit = 32M
max_execution_time = 3600
Веб-сервер

Копируем сайт-конф для Апача из дистрибутива Webacula 

$ cp  ~/webacula/install/apache/webacula.conf /etc/apache2/sites-available/webacula

и правим под нашу систему

#line 17,18,87 - правим алиас
Alias /webacula  /home/swasher/webacula/html
#line 38 - добавляем, откуда можно заходить
Allow from 192.168

Подсоеденяем и запускаем

$ a2enmod rewrite
$ a2ensite webacula
$ service apache2 restart

Смотрим что получилось

http://<IP>/webacula/
Troubleshooting

Ошибка

Fatal error:  Uncaught exception 'Zend_Exception' with message 
'Bacula version mismatch for the Catalog database. Wanted 12, 
got 14. ' in /home/swasher/webacula/html/index.php:194
Stack trace:
#0 {main}
  thrown in /home/swasher/webacula/html/index.php on line 194

Решение
Найдено тут. В файле html/index.php заменяем номер версии БД:

define('BACULA_VERSION', 12);
#change to
define('BACULA_VERSION', 14);

Ошибка

Fatal error:  Uncaught exception 'Zend_Exception' with message 'Directory \
"/home/swasher/webacula/data/cache" is not exists or not writable.' \
in /home/swasher/webacula/html/index.php:202
Stack trace:
#0 {main}
  thrown in /home/swasher/webacula/html/index.php on line 202

Решение
Директория webacula/data/cache должна принадлежать пользователю веб-сервера

$ chown www-data /home/swasher/webacula/data/cache

Ошибка

Fatal error: Uncaught exception 'PDOException' with \
message 'SQLSTATE[42S02]: Base table or view not found <...>

Решение
Не созданы таблицы Webacula (см. выше)

Bacula-web

Monitoring and reporting web gui for Bacula

Родной фронт-энд от Бакула, является частью Bacula community project. Bacula-web написан на PHP и работает в режиме read-only, предоствляя обощенную статистику о выполненных заданиях. Информация собирается из Каталога. Пакет называется bacula-gui.

Это выжимка из официальной документации, квик-старт установки на Ubuntu-server.

Устанавливаем необходимые Apache Web server и PHP

$ apt-get install apache2 libapache2-mod-php5 php5-mysql php5-gd

Редактируем /etc/php5/apache2/php.ini, устанавливаем нашу таймзону

date.timezone = Europe/Kiev

Скачиваем архив, распаковываем в /var/www или в какую-то другую директорию, тогда делаем сим-линк

$ wget http://bacula-web.org/tl_files/downloads/bacula-web-latest-version-number.tar.gz
$ mkdir /var/www/bacula-web
$ tar -zxf bacula-web-latest-version-number.tar.gz -C /var/www/bacula-web

Права доступа. Владелец должен быть тот пользователь, из под которого работает наш вебсервер.

Hint! echo $(ps axho user,comm|grep -E "httpd|apache"|uniq|grep -v "root"|awk 'END {if ($1) print $1}')

$ cd /var/www
$ chown -Rv www-data:www-data bacula-web
$ chmod -Rv u=rx,g=rx,o=rx bacula-web
$ chmod -v ug+w bacula-web/application/view/cache

Копируем конфиг

$ cd bacula-web/application/config
$ cp -v config.php.sample config.php
$ chown -v www-data: config.php

Редактируем config.php, добавляем такую секцию

// SWASHER bacula catalog
$config[0]['label'] = 'Backup Server';
$config[0]['host'] = 'localhost';
$config[0]['login'] = 'bacula';
$config[0]['password'] = 'verystrongpassword';
$config[0]['db_name'] = 'bacula';
$config[0]['db_type'] = 'mysql';
$config[0]['db_port'] = '3306';

password берется из bacula-dir.conf, секция Catalog, dbpassword

Тестируем установку: http://yourserveroripaddress/bacula-web/test.php. Красные крестики покажут нам, если чего-то нехватает.

Можно пользоваться: http://yourserveroripaddress/bacula-web

Webmin

С помощью Webmin можно просматривать и менять конфиги, запускать и просматривать задания, и многое другое. Однако, без понимания принципов работы Бакулы этот графический интерфейс ничем помочь не сможет.

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

Добавим в источники репозиторий и установим ключи ключи:

$ echo -e "\ndeb http://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list
$ cd /root
$ wget http://www.webmin.com/jcameron-key.asc
$ apt-key add jcameron-key.asc

Обновимся и установим webmin. Apt сам вытянет необходимые зависимости.

$ apt-get update
$ apt-get install webmin

Открываем браузером https://bacula.local:10000. Логин и пароль - пользователя системы, который может sudo. Ищем модуль bacula и правим настройки. В разделе Bacula database settings в поле пользователь базы данных пишем root, а пароль - тот, который мы задали для MySql во время инсталляции Бакулы.

bweb

bweb - это основанный на Perl веб-фронтэнд, предоставляющий инструменты для простых операций и сбора статистики. Он собирает информацию из Каталога и утилиты bconsole. Этот фронтэнд поддерживается коммерческим проектом Bacula Systems, и называется он у них BWeb™ Management Suite

Забираем с репозитория пакет bacula-web, распаковываем и переходим в директорию bweb. Дальнейшие инструкции основаны на файле INSTALL.

Устанавливаем зависимости

apt-get install libgd-graph-perl libhtml-template-perl libexpect-perl \ libdbd-mysql-perl libdbd-pg-perl libdbi-perl \ libdate-calc-perl libtime-modules-perl

apt-get install libgd-graph-perl libhtml-template-perl libexpect-perl libdbd-mysql-perl libdbd-pg-perl libdbi-perl libdate-calc-perl libtime-modules-perl

Проверяем зависимости

cd bweb/lib ../cgi/bweb.pl

Не находит error.tpl в путях, проверю позже

Troubleshooting

Я долго не мог понять, почему клиенты с небольшим объемом бекапа отрабатывают нормально, а если объем составляет сотни гигабайт, то после первой-второй сотни процесс прерывается с ошибкой Fatal error: Network error with FD during Backup: ERR=Connection reset by peer. Хорошенько погуглив, я понял так, что Директор прерывает слишком долгий процесс бекапа, предполагая, что он завис. Это лечится следующей опцией, которую нужно прописать на клиенте:

Heartbeat Interval = 60

Описание этой опции читаем в документации

TODO

  • Munin plugin for Bacula https://trac.bawue.org/munin/wiki/bacula_job
  • BaculaFS https://code.google.com/p/baculafs/
  • глава Восстановление
  • Глава Клиент
  • Глава Запуск
  • Ничего не написано про how-to-use
  • Глава Стратерия бэкапа

Камент с Хабры:
Когда я поднимал bacula с хранилищем на дисках, пришлось написать специальный сервисный скрипт (Job с Type=Admin), который перед backup job'ами пробегает по всем томам, удаляя устаревшие задачи, после чего удаляет все пустые тома из базы и с диска.

Про различия prune/purge/delete

Can someone explain the difference between the delete and purge commands?

I read the manual and it seems that they both do the same thing.

No, they do not.

If you purge a volume, all the jobs on it and their associated metadata are deleted, and the volume is marked as purged/reusable, but the volume is not deleted and is available for reuse. If you delete a volume, the entire volume is gone from the database, along with all jobs that were on it and their metadata.

If you delete a job, naturally all of its associated database records are purged, which may cause a volume to become completely purged.

Так же purged - это состояние тома, при котором он не содержит ничего полезного

Источники

Comments !

blogroll

social