Выбор системы Backup/Restore

В сентябре-октебря 2015 года я выбирал систему резервного копирования (backup/restore) для одного нашего нового проекта.

Главный сервер у нас под Debian-ом. Хотелось гибкой системы, масштабируемой до корпоративных масштабов (чтобы одним сервером бэкапить сколько угодно машин).

Что нарылось первичным поиском:

  1. Bacula:
    http://www.bacula.org/
  2. backup2l
    http://backup2l.sourceforge.net/
  3. DIBS
    http://sourceforge.net/projects/dibs/
  4. Amanda (Maryland)
    https://en.wikipedia.org/wiki/Advanced_Maryland_Automatic_Network_Disk_Archiver
  5. BackupPC:
    https://en.wikipedia.org/wiki/BackupPC

Почитал обзоры:

Из этого всего мне стала нравиться Bacula + доп. примочки, потому что её встроенный веб-интерфейс обладает лишь частичной функциональностью.

В результате установил на нашем сервере Bacula + Webacula веб-интерфейс + Baculum веб-интерфейс.

Сразу хочется отметить недостатки документации (разрозненность, неполноту, местами она устаревшая или не вполне корректная), только на английском. Однако, тем не менее, с её помощью можно полностью настроить систему.

Работа с серверным рантаймом полностью идёт через консоль. И это правильно.

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

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

Настройка включает создание файлов настройки следующих серверных компонентов:

  • Director Daemon (dir) — главный демон, мозг, который всё координирует. Нужен в количестве 1 штука в сети.
  • File Daemon (fd) — демон, который выполняет сбор и резервирование файлов. На каждом хосте, который нужно резервировать, должен крутиться такой демон.
  • Storage Daemon (sd) — демон, который упаковывает и записывает резервируемые файлы на носитель. Нужно учесть, что обычно для резервирования в организации используется ленточный носитель (до сих пор). Поэтому терминология и подход там соответствующий. Однако, конечно, есть возможность в качестве носителя использовать раздел жёсткого диска. «Ленты» и «пулы» сохранятся, только будут логическими (условными).
  • Также требуется подключение к СУБД. У нас используется PostgreSQL 6.3, к которому Bacula успешно подключилась. Кстати, она же и занимается его резервированием. Могу рассказать отдельно, как я настраивал это.

Главное — настроить Директора. Его конфиг включает создание следующих сущностей:

  • Jobs — задания на backup или restore заданного сета (FileSet) по заданному расписанию (Schedule) на заданный пул (Pool)
  • FileSets — объект копирования (файлы, дитектории, атрибуты, разделы)
  • Schedules — расписание в какой час какого дня какой недели/месяца делать заданный тип (см. ниже) резервирования
  • Clients — хосты, с которых разрешается принимать заявки на backup/restore (серверы, десктопы, на которых крутится FileDaemon)
  • Storages — хосты, на которые разрешается складывать/извлекать резервируемые данные (на которых крутится StorageDaemon)
  • Pools — «набор лент» (Volumes), в которые складываются резервируемые данные

Bacula поставляется в исходных текстах. Вообще, проект open source с лицензией Creative Commons, основной разработчик — Kern Sibbald. Распространяется соответственно бесплатно. Сначала делается создание набора настроек для её компиляции/сборки, затем Bacula компилируется и запускается в виде фоновых процессов. Я собрал, прописал её в автозапуски и настроил.

Где-то читал, что под Windows компиляция всей бакулы не проходит. Мне это не страшно, т. к. всё равно сервер под *ix. Для Windows распространяется готовый, уже скомпилированный File Daemon — то есть всё, что нужно, чтобы подключить хост под виндами к серверу с Бакулой и забэкапить его. Это я начал делать, чтобы резервировать и наши виндовые машины, но вынужден был переключиться на другие задачи. Помню, та найденная виндовая сборка оказалась более старой версии (сервер я ставил новейший на тот момент stable, 7.0.6), но успешно установилась на новейшей версии Windows Server 2012 R2 Standard 64-bit и работает там сейчас в фоне. Настроить не успел пока.

Это заняло какое-то время, но, в общем я рад результатам. Работает очень хорошо. Ещё не справился email notification сделать (у нас через внешний Mailgun идёт исходящая почта), руки не доходят.

А веб-интерфейсы настроил. Выглядят так:

[siteorigin_widget class=»SiteOrigin_Widget_Image_Widget»][/siteorigin_widget]

Это Baculum, веб-интерфейс, который прилагается к основному пакету Bacula (но который, конечно, отдельно надо поднимать на вашем веб-сервере).

[siteorigin_widget class=»SiteOrigin_Widget_Image_Widget»][/siteorigin_widget]

Это Webacula. Внешний веб-интерфейс для бакулы. Надо собирать и налаживать и подключать к бакуле отдельно. Написан нашим соотечественником. Интерфейс посовременнее.

Часть функций есть только в Baculum, другая — только в Webacula. Поэтому я решил оставить их оба. Оставил работать на разных портах (и даже разных веб-серверах, nginx & apache).

Вот тут ещё статья о том, как настроить удалённые бэкапы в Бакулу на хосте с Убунтой:

https://www.digitalocean.com/community/tutorials/how-to-configure-remote-backups-using-bacula-in-an-ubuntu-12-04-vps