bareos
"будьте готовы к непредвиденным последствиям" ©
Потыкал тут бареос палкой, не пора ли мигрировать. Оказалось пока не стоит: на мой взгляд оно ещё несколько сыроватое.
Баги
Самая последняя на текущий момент версия:
- из-за добавления новых директив в конфиг, парсер иногда лажает
Баг. Пример проявления:
11-Dec 23:05 ma-dir: ERROR in dird_conf.c:2130 Unknown include/exclude option: N
... что именно ему не нравится сходу раскопать не удалось. Пишут что исправлено в 14.2+, но хрен ты угадал, в 16.2 этот глюк ещё есть.
- заявленная совместимость с клиентами baculы - на самом деле не такая уж и совместимая.
Баг. Пример проявления:
11-Dec 23:05 ma-dir JobId 24: Using Device "disk" to write.
11-Dec 23:05 ma-dir JobId 24: Warning: Unexpected Client Secure Erase Cmd: 2999 Invalid command
11-Dec 23:05 ma-dir JobId 24: Fatal error: Bad response to Storage command: wanted 2000 OK storage
Гугл по поводу этой ошибки выдал только исходник самого директора.
Вот что мне ответили по поводу перспектив использования совместно с бакулой 7 (нужно, чтобы не обновлять всех клиентов разом).
Bareos to Bacula compatibility has only tested up to Bacula 5.2.x. AFAIK Bacula changed there hello strings after this. As you might have already seen, the Director only tries to configure the Secure Erase Command when it detects a client with protocol version >= 53. Bacula 5 did use "5". I just found out that Bacula 7.4 is using 213 (I did expect "7").
We'll accept patches to extend the compatibility. However, contributors should be aware of Bacula license in Bacula >= 6 (Bacula header).
I'll update the documentation, to clarify, that Bacula >= 6 is not supported.
т.е. заявленная совместимость резко поуменьшилась в объёме.
Базу на директоре до бареоса можно обновить только с пятой бакулы, с 6+ - хрен, "это не тестировалось".
Вебморда
У меня были большие надежды на нативную вебморду, однако там по прежнему всё плохо.
Они оживили старый проект webacula, портировав его на ZendFramework2. Опять похапе, ещё жирнее рантайм, ещё больше зависимостей.
По сравнению с bacula-web, там есть 2 основных отличия:
- bareos-webui честно работает через директора (протокол которого стабилен), а не лезет в базу напрямую (её схема меняется при обновлениях).
- есть возможности управлять заданиями (восстановление/запуск бэкапа)
Тем не менее - всё что выходит за рамки управления уже настроенным конфигом - по прежнему ручками в консоли, каких-то кардинальных улучшений здесь нет.
Схема организации конфигов
Не в последнюю очередь хотел посмотреть что они там придумали по этому поводу. Так вот - основная идея - это доведение модульности конфига до абсурда.
Помню, когда в третьей бакуле появился include через @"file.conf" - я был счастлив. Портянка основного конфига, была побита на логичные блоки и дзен таки наступил.
Я даже по этому поводу написал схему организации конфига, которой придерживался несколько лет. В процессе использования я немного её поменял, например описания заданий логично держать рядом с описанием клиентов. JobDef'ы и расписания тоже логично держать в одном файле.
Теперь покажу что сделали в bareos'е. Ниже - абсолютно пустой конфиг DIR/SD из пакета bareos-server.
.
|-- bareos-barcodes.sample
|-- bareos-dir.d
| |-- catalog
| | `-- MyCatalog.conf.sample
| |-- client
| | `-- bareos-fd.conf.sample
| |-- console
| | `-- bareos-mon.conf.sample
| |-- counter
| |-- director
| | `-- bareos-dir.conf.sample
| |-- fileset
| | |-- Catalog.conf.sample
| | |-- LinuxAll.conf.sample
| | |-- SelfTest.conf.sample
| | `-- WindowsAllDrives.conf.sample
| |-- job
| | |-- BackupCatalog.conf.sample
| | |-- RestoreFiles.conf.sample
| | `-- backup-bareos-fd.conf.sample
| |-- jobdefs
| | `-- DefaultJob.conf.sample
| |-- messages
| | |-- Daemon.conf.sample
| | `-- Standard.conf.sample
| |-- pool
| | |-- Differential.conf.sample
| | |-- Full.conf.sample
| | |-- Incremental.conf.sample
| | `-- Scratch.conf.sample
| |-- profile
| | `-- operator.conf.sample
| |-- schedule
| | |-- WeeklyCycle.conf.sample
| | `-- WeeklyCycleAfterBackup.conf.sample
| `-- storage
| `-- File.conf.sample
`-- bareos-sd.d
|-- autochanger
|-- device
| `-- FileStorage.conf.sample
|-- director
| |-- bareos-dir.conf.sample
| `-- bareos-mon.conf.sample
|-- messages
| `-- Standard.conf.sample
|-- ndmp
`-- storage
`-- bareos-sd.conf.sample
21 directories, 28 files
... не смотрите на .sample, они все потом в дело пойдут.
28 directories, 49 files
... это уже рабочий конфиг (без *.sample!) на тестовой машине с четырьмя FD.
Прогрессию можете посчитать сами, с учётом того факта, что в этом конфиге Job {} определяется не в отдельном файле, а вместе с блоком Client {}.
Любимая отговорка в таких случаях начинается на "никто не запрещает", но я хочу обратить внимание на тот факт, что она неплохо показывает уровень мышления и наличие отсутствия здравого смысла у основных разработчиков проекта.
Вот например как это организовано у перца, который обслуживает бэкапы в трёх датацентрах и реально работает с этой системой каждый день (см с 17й страницы и далее).
Итого
Вобщем одно другого стоит. В бареосе улучшили поддержку венды, если вам это не критично - особой разницы пока нет.
Почему бежать впереди паровоза не стоит:
- плавной миграции не получится, переделывать придётся всё.
- активность проекта - это и свежие баги в каждом новом релизе
- пассивный режим пока не допилен, в 16.2 он ещё в экспериментальном режиме.
Но если разворачиваете новую систему - можно попробовать.