Доброго времени суток, уважаемые!Подскажите, пожалуйста, пробовали ли вы бэкапить большое количество win-машин (порядка 30) по их выключению? (В качестве Shutdown-скрипта указываем bat-скрипт запускающий bconsole, на вход консоли направляем команды из текстового файла, которые и запускают бэкап.)
Я пробую, но пока несчастлив. Конкретно, не устраивает тот момент, что доки бакулы не рекомендует параллельные задания для storage daemon'a, а значит будет образовываться очередь из пользователей, желающих уйти домой и ожидающих завершения выключения компьютера (пока не завершиться бэкап первой машины остальные ждут своей очереди). После команды run yes приходится давать команду wait, иначе (часто) машины выключаются, а бэкап не успевает отрабатывать. Иной раз - скоре всего, когда происходит ошибка на стороне клиента и bacula-fd на сервере ждет уже выключенного клиента - процесс director'а, запускаемый для следующего клиента, не может забиндить порт (то, какой именно процесс директора не может забиндить порт - лишь мое предположение). Расплодившиеся процессы director'а имеют обыкновение не уменьшаться в количестве даже после завершения всех задач, лечиться перезапуском бакулы.
Т.е., получается, что бакула не устойчива к сбоям на стороне клиентов и один из таких сбоев может поставить раком всю систему бэкапа, а при условии невозможности параллельного бэкапа нескольких (хоть трех-пяти) клиентов ошибки неизбежно будут - те-же пользователи могут выключить машину не дождавшись нормального завершения его работы.
Ситуация осложняется наличием в конторе сегментов беспроводной сети, в одном из кабинетов - ужасного качества (сигнал слаб)...
Есть решение моей проблемы?
PS Версии ПО:
Debian Stable (Sarge), соответственно, и на сервере и на клиентах бакула версии 1.36.2
Если вы решали подобную задачу с новой версией бакулы и не натыкались на вышеописанные проблемы - отзовитесь, пожалуйста.// greyork
Бакуловоды, отзовитесь, пожалуйста. Никто не сталкивался разве?// greyork
Я так понимаю, что оригинальная документация не читалась?
Вернее даже не открывалась?
А зря.Параллельные задания необходимо тестировать, прежде чем эксплуатировать далее.
Сейчас доступна новая версия Bacula, где достаточно много нового именно в win32 клиенте.
[понты поскипаны]
>Параллельные задания необходимо тестировать, прежде чем эксплуатировать далее.Вот конкретно вы тестировали параллельные задания? Я документацию читал - там ясно написано, что это делать НЕ РЕКОМЕНДУЕТСЯ. Читал именно документацию к последней стабильной версии бакулы. Если у вас есть подобный опыт - лучше поделитесь тем как бэкапите win-машины, вместо того, чтобы голословно о чем-то писать.
>Сейчас доступна новая версия Bacula, где достаточно много нового именно в win32
>клиенте.Вот взяли бы, да написали, например, так: "у меня проблем с такой-то версией бакулы на таком-то кол-ве win-машин нет. но бэкаплю я по такой схеме...". Я описывал конкретные проблемы, вы ответили грубо - "доки даже не открывал". Если бы не открывал - не спрашивал бы.
// greyork
>Вот конкретно вы тестировали параллельные задания?Конкретно как раз на днях собираюсь.
> Если у вас есть подобный опыт - лучше
>поделитесь тем как бэкапите win-машиныБэкаплю win-сервера, ч/з win32-клиент бакулы.
Просто по описанию проблемы указать ошибку сложно, нужны рабочие конфиги, скрипты, логи.
Если есть желание можем вместе поразбираться.
Спасибо за отклик.>>Вот конкретно вы тестировали параллельные задания?
>
>Конкретно как раз на днях собираюсь.Это хорошо. Используете ли вы один пул или несколько? После прочтения предостережения об одновременной записи в один volume данных от двух разных задач, первая мысль была - организовать несколько пулов (по числу допустимых параллельных (в терминах бакулы - конкурентных) заданий). Но, в бакуле, afaik, невозможно при занятости конкурентной задачей одного пула, писать в свобоный, а после - коррректно восстанавливать данные из этих (_разных_) пулов. Т.е. балансировка по нескольким пулам отсутствует. И единственный способ - поставить эксперимент по записи данных от конкурентных задач в один пул и volume. Верно ли мое понимание ситуации?
>Бэкаплю win-сервера, ч/з win32-клиент бакулы.
С серверами проще - их можно и нужно бэкапить по расписанию. Нет того бардака, из процессов bacula-director, возникающего после возникновения ошибки на одной или нескольких клиентских машин, которые могут инициировать бэкап в любое время (по завершению работы компьютера или по желанию сотрудника).
Ситуация: наблюдаю 20 (или чуть больше) процесс даемонов бакулы (большинство - director'ы, которых в режиме ожидания клиентов, после первого запуска бакулы, в норме ~ 4 штуки), запускаю bconsole и периодически смотрю на status storage, в течении двадцати минут, и вижу, что статус запущенной имеет одна-единственная задача, которая не движется (FD socket close, если память не изменяет). Спрашивается - нафига остальные процессы висят и ждут "мертвого" уже клиента? Почему некорректно отрабатывается отключение/выключение клиента? (После nmap -sP по диапазону IP, видно, что машины и отключились-то уже не дождавшись начала бэкапа, из-за одной - поставившей все раком)
Следующая ситуация: все то-же, что и в первой, за исключением того, что bconsole вообще не может подцепиться к director'у! Зависает. Кстати, ps в этот момент говорит, что процессов консоли не один, а три (!). После Ctrl-C, процессы консоли висят в памяти... Это ли не прелестно написанный софт? ;)
Да, у меня в заданиях был wait, но без него машина выключалась сразу после отработки моего скрипта logout.bat (в схеме для бэкапа по выключению машин).
Отсюда мораль: 1. не бэкапте машинки бакулой параллельно или по желанию клиентов (которые рано или поздно запустят задачи параллельно); 2. будте готовы рестартануть бакулу, после "затора"; 3. если есть нужда в бэкапе по выключению машин - делайте его по включению (меньше гарантий прерывания бэкапа ДО его нормальнго завершения и нарушения, таким образом, бэкапа для других машин).>Просто по описанию проблемы указать ошибку сложно, нужны рабочие конфиги, скрипты, логи.
В настоящий момент сервак выключен (в биосе указано время выключения сервака на ночь). Это не постоянная моя работа, а шабашка.
>Если есть желание можем вместе поразбираться.
Спасибо, желание есть.
Да, бакула у меня из стабильного дистрибутива Debian, поскольку с нее начинали, бэкапы достигли 30 Гб, а коней на production-сервере менять.. простите - черный юмор.
Хочу, сперва убедиться, что новая версия решит имеющиеся проблемы, не создаст новых проблем, а переезд будет гладким.// greyork
храни профили на сервере - а от туда и бэкапь в нужное время..
>Используете ли вы один пул или несколько?Несколько. Разнятся по срокам хранения информации (пол-года, год, два, пять и т.п.) и по носителям: файл, лент
а, DVD.Проблему с параллельными заданиями хочу решить за счет указания для каждого задания
Job {
...
SpoolData = yes
...
}Судя по докам, бакула сначала свалит все в кучу во временный файл, а потом аккуратно, последовательно запишет
в соответствующие пулы.
Стр. 407 «Running Concurrent Jobs»> И единственный способ - поставить эксперимент по записи данных от конкурентных задач в один пул и volume.
Ну, если сделать файл-том безразмерным, то и писать будет только туда.
Еще есть пар-р:
Maximum Volume Jobs = nnn>Нет того бардака, из процессов bacula-director, возникающего после возникновения ошибки на одной или нескольк
их клиентских машин
Я начинал с версии 1.38.4 (сейчас буду тестировать последнюю 1.38.9-1), там при ошибках на клиенте выдавалось
сообщение на консоль и задание прерывалось. Параллельные задания не тестировались.Для заданий есть еще параметры:
Max Run Time = <time>
Max Wait Time = <time>
можно попробовать их настроить.Для директора:
FD Connect Timeout = <time>
SD Connect Timeout = <time>И еще. Я так понял, что в бакуле нет понятия "по желанию клиента". Хотя при желании клиенту можно сунуть консоль с правами только на запуск его задания (в командной строке), т.е. клиент становится как бы оператором бакулы (с ограниченными правами, конечно).
Кстати, а что за данные у юзеров.
В смысле, а пусть они сами ложат на сервер бэкапа на самбу в каталог то, что нужно бэкапить?