Bareos: ленты, Hyper-V и ещё всякое

[FlyingDutchman]

Увы, так и не сумели подружить бареос и оракловский RMAN-бэкап. Нигде нет внятных доков на эту тему, а стандартные оракловские скрипты не видят SBT-драйвера

[ewgenik]

Еще есть хорошая идея к уведомлению о завершении задания прикреплять вывод консольной команды «messages». Стандартные макросы в письме (%c %d %e %h и т.д.) не дают достаточной информации. А вот листинг «messages» позволит сразу в отчете видеть практически всю инфу о выполненном задании. Как это реализовать — вариантов уйма.

[ingvarhost]

Главная проблема Бареоса на данный момент — отсутствие обновлений. В свободный доступ выкладывается только начальная версия, а вот обновления с багфиксами только по платной подписке. Ну и в добавок — слишком переусложненная конфигурация, очень тяжелая настрока SSL, остутствие дедупликации.

[overmind88]

А разве не из-за такой же фигни форкнули bacula в bareos?

[ingvarhost]

Из-за такой. И сами занялись точно тем же.

[Tabletko]

Используете ли вы Always Incremental backup?

[muon]

Мы — нет. Я пока не понял, что это и нужно ли нам оно.

Мне нравится концепция декрементального бэкапа, но это не про бареос.

[FlashHaos]

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

[rahs]

На ленту результат можно перенести миграцией.

[muon]

Я правильно понимаю: хотя для восстановления нужен только один полный бэкап, но на диске нужно иметь место для двух, т. к. при консолидации содержимое одного тома целиком копируется в другой?

[ls1]

Не тестил сабж, но как я понимаю под капотом там идет просто жонглирование записями о файлах в базе-каталоге. Новые файлы инкрементально прилетают и заносятся в базу, а старые (удаленные из файлового ресурса) удаляют из базы и стираются из стореджа. Таким образом все снапшоты тут попросту SQL-ные вьюшки на определенную дату. «Копирование» это было бы совсем ересью.

[rahs]

DPM и Антоан! Как знакомо, аж мороз по коже!

[FlashHaos]

Очень рекомендую писать с нуля или собирать из модулей единую систему мониторинга и анализа СРК, включив туда и хранилки и процессы бекапа и клиенты и устройства РК. Если грамотно прописать взаимосвязи и настроить аналитику — можно удобно из одного места видеть всё. К примеру, я у себя написал достаточно педальную функцию, которая смотрит на текущий бекап и сравнивает его длительность с средним по последним десяти. Если бекап неожиданно идёт заметно дольше или выполнен слишком быстро — вывести тревожное сообщение. Медленный бекап обычно значит, что где-то в инфраструктуре узкое место (и если в одном интерфейсе видно состояние хранилки и медиасервера — обычно сразу ясен ответ), а слишком быстрый бекап — что мы забираем сегодня не тот объем, что всегда (например не успел создаться дамп или база уехала с виртуалки).
Касательно software шифрования — какие преимущества пред хардварным? Софтваре будет жрать ресурсы сервера, а хардваре — грузить специально обученный процессор на ленточном приводе.
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как? Один бекап — одна лента? У себя в СРК я с таким никогда не сталкивался.

[muon]

Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как?

Это про миграцию: бареос может перенести данные из одного пула в другой, например, с дисков на ленту. Но он не занимется объединением томов. Если на дисках данные лежали в нескольких томах (файлах), то он не соберёт их в один новый том (ленту).