После более года разработки представлен (http://www.bareos.org/en/news/bareos-17-2-published-348.html) шестой значительный релиз (17.2) проекта Bareos (http://www.bareos.org/), в рамках которого развивается форк клиент-серверной системы резервного копирования Bacula (http://www.bacula.org/). Код проекта распространяется (https://github.com/bareos/bareos) под лицензией AGPLv3. Готовые сборки сформированы (http://download.bareos.org/bareos/release/17.2/) для различных дистрибутивов Linux, Windows и macOS.
Bareos был создан участниками из сообщества в ответ (https://www.bareos.org/en/faq/why_fork.html) на смещение разработки Bacula в сторону развития закрытой коммерческой редакции, появления проблем с приёмом патчей и урезания возможностей открытой версии. Три года назад компания Bacula Systems SA попыталась инициировать судебное разбирательство в отношении нарушения своих авторских прав, но компания Bareos GmbH & Co выдвинула встречные претензии и дело было закрыто (https://www.bareos.org/en/news/bacula-systems-and-bareos-set... по соглашению сторон.После ответвления от Bacula в Bareos были добавлены такие возможности, как поддержка квот на стороне клиента, встроенная реализация NDMP, дедупликация, мультиарендность (multi-tenancy), средства для ограничения пропускной способности, новый установщик для Windows, пассивный режим работы клиента (все соединения инициируются с сервера), со стороны клиента, средства для аудита, бэкенды для Gluster и Ceph, возможность локализации интерфейса, новый интерфейс для плагинов, поддержка резервного копирования LDAP и VMware, web-интерфейс для управления через браузер. Bareos совместим с Bacula и предоставляет сценарий миграции для старых конфигураций Bacula.
Основные новшества (http://doc.bareos.org/master/html/bareos-manual-main-referen...:
- Проведена оптимизация хранения информации о файлах в БД, что позволило значительно повысить скорость работы при резервном копировании очень большого числа файлов (миллионы);
- Расширены возможности по сохранению бэкапов в хранилищах, поддерживающих протокол NDMP (https://en.wikipedia.org/wiki/NDMP) (Network Data Management Protocol). Добавлена поддержка двунаправленной передачи файлов из хранилища на ленту напрямую поверх сети хранения данных. Значительно ускорено восстановление единичных файлов через NDMP, благодаря реализации (http://doc.bareos.org/master/html/bareos-manual-main-referen... механизмов DAR и DDAR (Direct Recovery);
- В управляющий демон добавлена директива LanAddress, позволяющая клиентам из внутренних сетей напрямую записывать бэкапы в локальное хранилище, образуя распределённую сеть. Например, сетевые операторы могут выполнять резервное копирование из клиентских сетей;
- В web-интерфейс добавлено отображение прогресса выполнения операций для всех запущенных работ. Обеспечена возможность отдельного запуска кастомизированных работ с произвольным набором опций;- Добавлена поддержка резервного копирования и восстановления окружений Amazon S3;
- В базовую поставку добавлен пакет python-bareos;
- В число поддерживаемых платформ добавлен HP-UX 11.31 (ia64);
- В bareos-vmware-plugin добавлена поддержка Virtual Disk Development Kit (VDDK) 6.5.x, а также VMware vSphere 6.5 и более новых выпусков, сохраняя совместимость с VMware vSphere 5.5 и 6.0.
URL: http://www.bareos.org/en/news/bareos-17-2-published-348.html
Новость: http://www.opennet.me/opennews/art.shtml?num=47768
Mysql, Bacula, Vyatta... Пора уже проприерастам понять, что нельзя, купив права на опенсорсный продукт, купить заодно и всех его пользователей, большинство свалит на более открытый и дружественный к сообществу форк.
Какая зажигательная речь.
Совершенно правильная речь. Классический показательный пример - история "успеха" OpenOffice.
Ну, VyOS не сказать чтобы очень активна. Кто на Микротик ушел, а кто на Линуксе роутинг пилит. Так что форк, может, и дружественный, но идею загубили.
не понял, кто что загубил? все что было осталось на месте, только некоторые костыли причесали, хуже точно не стало. последнее время пилят бэкенд на Python, может больше народу в проект притечет (Perl сложноват, народу знающего его мало и бесплатно они не работают)
>В число поддерживаемых платформ добавлен HP-UX 11.31 (ia64);
>передачи файлов из хранилища на лентуСветлое будущее не за горами. Двигаются семимильнымми шагами...
>Светлое будущее не за горами. Двигаются семимильнымми шагами...ты не поверишь но в 21 веке бываеют ситуации когда на ленту выгоднее и проще
примеры надо приводить?
Да, конечно..
С ТСО и рисками пожалуйста..
а сюрреалистические маркетинговые фантазии про ленточки не интересно.
Поддержу.
Библиотека из лент в своё время избавила от кучи проблем.
Ну да - было дело. Но теперь то ... добавляет кучу проблем :(
Ну если иметь ввиду добавление поддержки Чпукса, да ещё IA64, то да, сарказм про светлое будущее уместен.
при большом количестве файлов веб-морда просто не справлялась на innoDB (postgre то же самое, висло всё наглухо) , после включения myisam норм более-менее.
Запилили бы этот индекс в elasticsearch, вот бы было круто.
Ну то что веб-морда, виснет о количества файлов (в бэкапах что ли?) это само по себе феерически круто... :)
Представь почтовый сервер - 1 письмо 1 файл, за несколько лет, примеров много могу привести где 16 версия веб-интерфейса с php и nginx просто складывается, упираясь в ограничение БД, толковых мануалов практически нет. Документации по bareos очень мало, в итоге такие костыли как смена движка.
Чаще всего, фраза "ограничение БД" применительно к веб приложению - означает либо плохо/архитектурно неправильно написанный sql-запрос, либо неверно сконфигурированную субд.То есть это не проблема субд как таковой, а скорее проблема умельцев наваявших такой код...
> Ну то что веб-морда, виснет о количества файлов (в бэкапах что ли?)в бэкапах, где ж еще.
ну это бакула, она вся такая.Там не только общение с тазой банных такое вот, по записи (с развесистыми foreign keys) на файл, там и структура хранилища, и протоколы - все сделано в лучших традициях полевой проктологии.
зато теперь у нас два несовместимых форка.
> при большом количестве файлов веб-морда просто не справлялась на innoDB (postgre то
> же самое, висло всё наглухо) , после включения myisam норм более-менее.
> Запилили бы этот индекс в elasticsearch, вот бы было круто.во-первых, дорогой Анони, перестаньте терять последнюю букву в названии Post Ingres
во-вторых, з@коп@й+е стюардессу. современный innodb ни в каких задачах не отстает от myisam на значимую величину (дело в развитии, myisam давно сдох, а innodb хоть и мелкими шажками но развивается непрерывно).и да, конфиг Postgres, на котором тормозило в студию! вместе посмеемся.
Допустим есть такое страннейшее техническое решение:
гипервизор подключается к ленте по sas, виртуалки лежат на СХД по iscsi. Нужно делать файловый бэкап виртуалки (винды) на ленту. Как это реализовать ?
> Допустим есть такое страннейшее техническое решение:
> гипервизор подключается к ленте по sas, виртуалки лежат на СХД по iscsi.
> Нужно делать файловый бэкап виртуалки (винды) на ленту. Как это реализовать
> ?если vmware я бы копал в сторону ghettoVCB, винду бэкапить бареосом стрёмно.
Гипервизором скорее всего будет проксмокс. Точно не vmware, т.к. дорого.
proxmox овно, был печальный опыт, обновы платные. Если подключишь сторонние репы centos(или что у них там сейчас) получишь неработоспособную систему.
Имхо бэкапить лучше отдельным сервером, не виртуалкой. Если, конечно, бюджет ограничен, я бы копал в сторону ухода из конторы, которая не может выделить денег на бэкап.
с 4й версией всё шоколадно, правда в основном кручу там линуксы.
Какие еще репозитарии centos? proxmox базируется на debian. И зачем там сторонние репозитарии вообще? Что вы с ними делать собрались?
Это не важно! Важно изгадить все вокруг. Создать видимость всезнайки и дать понять, что оппонент - дэбил.
Лента используется для архивов! Ах, у Вас нет архива, например, бухгалтерии? "Тогда мы идём к Вам!"
Это во времена работало в те времена когда ёмкость ленты была с десяток дисков.Теперь всё не так. Архивы есть. Лент - нету.
> Допустим есть такое страннейшее техническое решение:
> гипервизор подключается к ленте по sas, виртуалки лежат на СХД по iscsi.
> Нужно делать файловый бэкап виртуалки (винды) на ленту. Как это реализовать
> ?В Вашем случае, ставить на гипервизор storage daemon, а на винду file daemon.
Для bacula\bareos желательно выделить отдельную подсеть, чтобы бекапы с пользовательским трафиком не пересекались.
>Для bacula\bareos желательно выделить отдельную подсеть,Вы имеете в виду отдельную физическую подсистему (свои сетевые карты, свои свичи, своя кабельная структура) или "подсеть" просто как диапазон адресов?
>>Для bacula\bareos желательно выделить отдельную подсеть,
>Вы имеете в виду отдельную физическую подсистему (свои сетевые карты, свои свичи, своя кабельная >структура) или "подсеть" просто как диапазон адресов?Так как у Вас LTO лента подключена к гипервизору, а бекапить нужно файлы с его виртуалок, то будет достаточно сделать в гипервизоре еще один bridge на свободный ethernet интерфейс (даже loopback подойдет). Этот bridge раздать виртуалкам, прописать везде выделенную под бекапы подсеть. Если бекапы выходят за рамки одного гипервизора, то уже настроить на свиче VLAN под бекапы и гипервизоры подключать выделенным под бекапы интерфейсом (не loopback). iscsi у вас же наверно выделен в отдельный VLAN, не так ли? ;)
Можно пойти и дальше, ставить отдельный свич, агрегировать порты и т.д. это зависит от объемов и потребностей.
На Гипервизор ставится Bareos-Director + Bareos-Storage-Daemon.
На виртуалки ставится Bareos-Client (для соответствующей операционной системы).Если нужно делать бакапы/снапшоты самих вартуалок (бакапить образы виртуалок и их снапшоты), то на Гипервизоре нужен еще и Bareos-File-Daemon (он же bareos-client по сути).
Все настраивается.
У меня совершенно нормально все это работает. Гипервизор - KVM+Проксмокс, все виртуалки лежат в CEPH, 100 шпинделей, 7 серверов + один сервер, специально выделенный под бакап + мониторинг.
Помнится, мне не хватало возможности организации прямого соединения клиента и того что файлы собственно хранит, все приходилось бессмысленно перекачивать через "storage". То есть либо объявлять каждый файловый сервер "storage", теряя возможность их легко заменять и дублировать, либо забивать сеть.