Pull to refresh

Comments 14

Увы, так и не сумели подружить бареос и оракловский RMAN-бэкап. Нигде нет внятных доков на эту тему, а стандартные оракловские скрипты не видят SBT-драйвера
Еще есть хорошая идея к уведомлению о завершении задания прикреплять вывод консольной команды «messages». Стандартные макросы в письме (%c %d %e %h и т.д.) не дают достаточной информации. А вот листинг «messages» позволит сразу в отчете видеть практически всю инфу о выполненном задании. Как это реализовать — вариантов уйма.
Главная проблема Бареоса на данный момент — отсутствие обновлений. В свободный доступ выкладывается только начальная версия, а вот обновления с багфиксами только по платной подписке. Ну и в добавок — слишком переусложненная конфигурация, очень тяжелая настрока SSL, остутствие дедупликации.
А разве не из-за такой же фигни форкнули bacula в bareos?
Из-за такой. И сами занялись точно тем же.
Мы — нет. Я пока не понял, что это и нужно ли нам оно.

Мне нравится концепция декрементального бэкапа, но это не про бареос.
Такие бекапы очень хороши — забираешь инкрементал, а уже на стороне хранилища из него и предыдущего полного лепится синтетический полный. Уменьшает объем передаваемых данных и, соответственно, окно бекапа. Сплошные плюсы, кроме того, что такая технология не работает с лентами в силу своей специфики.
На ленту результат можно перенести миграцией.
Я правильно понимаю: хотя для восстановления нужен только один полный бэкап, но на диске нужно иметь место для двух, т. к. при консолидации содержимое одного тома целиком копируется в другой?
Не тестил сабж, но как я понимаю под капотом там идет просто жонглирование записями о файлах в базе-каталоге. Новые файлы инкрементально прилетают и заносятся в базу, а старые (удаленные из файлового ресурса) удаляют из базы и стираются из стореджа. Таким образом все снапшоты тут попросту SQL-ные вьюшки на определенную дату. «Копирование» это было бы совсем ересью.
DPM и Антоан! Как знакомо, аж мороз по коже!
Очень рекомендую писать с нуля или собирать из модулей единую систему мониторинга и анализа СРК, включив туда и хранилки и процессы бекапа и клиенты и устройства РК. Если грамотно прописать взаимосвязи и настроить аналитику — можно удобно из одного места видеть всё. К примеру, я у себя написал достаточно педальную функцию, которая смотрит на текущий бекап и сравнивает его длительность с средним по последним десяти. Если бекап неожиданно идёт заметно дольше или выполнен слишком быстро — вывести тревожное сообщение. Медленный бекап обычно значит, что где-то в инфраструктуре узкое место (и если в одном интерфейсе видно состояние хранилки и медиасервера — обычно сразу ясен ответ), а слишком быстрый бекап — что мы забираем сегодня не тот объем, что всегда (например не успел создаться дамп или база уехала с виртуалки).
Касательно software шифрования — какие преимущества пред хардварным? Софтваре будет жрать ресурсы сервера, а хардваре — грузить специально обученный процессор на ленточном приводе.
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как? Один бекап — одна лента? У себя в СРК я с таким никогда не сталкивался.
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как?
Это про миграцию: бареос может перенести данные из одного пула в другой, например, с дисков на ленту. Но он не занимется объединением томов. Если на дисках данные лежали в нескольких томах (файлах), то он не соберёт их в один новый том (ленту).
Sign up to leave a comment.

Articles