Comments 14
Увы, так и не сумели подружить бареос и оракловский RMAN-бэкап. Нигде нет внятных доков на эту тему, а стандартные оракловские скрипты не видят SBT-драйвера
0
Еще есть хорошая идея к уведомлению о завершении задания прикреплять вывод консольной команды «messages». Стандартные макросы в письме (%c %d %e %h и т.д.) не дают достаточной информации. А вот листинг «messages» позволит сразу в отчете видеть практически всю инфу о выполненном задании. Как это реализовать — вариантов уйма.
+1
Главная проблема Бареоса на данный момент — отсутствие обновлений. В свободный доступ выкладывается только начальная версия, а вот обновления с багфиксами только по платной подписке. Ну и в добавок — слишком переусложненная конфигурация, очень тяжелая настрока SSL, остутствие дедупликации.
+1
Используете ли вы Always Incremental backup?
0
Мы — нет. Я пока не понял, что это и нужно ли нам оно.
Мне нравится концепция декрементального бэкапа, но это не про бареос.
Мне нравится концепция декрементального бэкапа, но это не про бареос.
0
Такие бекапы очень хороши — забираешь инкрементал, а уже на стороне хранилища из него и предыдущего полного лепится синтетический полный. Уменьшает объем передаваемых данных и, соответственно, окно бекапа. Сплошные плюсы, кроме того, что такая технология не работает с лентами в силу своей специфики.
0
На ленту результат можно перенести миграцией.
0
Я правильно понимаю: хотя для восстановления нужен только один полный бэкап, но на диске нужно иметь место для двух, т. к. при консолидации содержимое одного тома целиком копируется в другой?
0
Не тестил сабж, но как я понимаю под капотом там идет просто жонглирование записями о файлах в базе-каталоге. Новые файлы инкрементально прилетают и заносятся в базу, а старые (удаленные из файлового ресурса) удаляют из базы и стираются из стореджа. Таким образом все снапшоты тут попросту SQL-ные вьюшки на определенную дату. «Копирование» это было бы совсем ересью.
0
DPM и Антоан! Как знакомо, аж мороз по коже!
0
Очень рекомендую писать с нуля или собирать из модулей единую систему мониторинга и анализа СРК, включив туда и хранилки и процессы бекапа и клиенты и устройства РК. Если грамотно прописать взаимосвязи и настроить аналитику — можно удобно из одного места видеть всё. К примеру, я у себя написал достаточно педальную функцию, которая смотрит на текущий бекап и сравнивает его длительность с средним по последним десяти. Если бекап неожиданно идёт заметно дольше или выполнен слишком быстро — вывести тревожное сообщение. Медленный бекап обычно значит, что где-то в инфраструктуре узкое место (и если в одном интерфейсе видно состояние хранилки и медиасервера — обычно сразу ясен ответ), а слишком быстрый бекап — что мы забираем сегодня не тот объем, что всегда (например не успел создаться дамп или база уехала с виртуалки).
Касательно software шифрования — какие преимущества пред хардварным? Софтваре будет жрать ресурсы сервера, а хардваре — грузить специально обученный процессор на ленточном приводе.
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как? Один бекап — одна лента? У себя в СРК я с таким никогда не сталкивался.
Касательно software шифрования — какие преимущества пред хардварным? Софтваре будет жрать ресурсы сервера, а хардваре — грузить специально обученный процессор на ленточном приводе.
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как? Один бекап — одна лента? У себя в СРК я с таким никогда не сталкивался.
+1
Еще я не очень понял, насчет «Бареос не станет писать несколько файлов-томов на одну кассету». Это как?Это про миграцию: бареос может перенести данные из одного пула в другой, например, с дисков на ленту. Но он не занимется объединением томов. Если на дисках данные лежали в нескольких томах (файлах), то он не соберёт их в один новый том (ленту).
0
Sign up to leave a comment.
Bareos: ленты, Hyper-V и ещё всякое