Bacula, выполнение скриптов после бекапа?

Question

[Александр]

Добрый день.

Используем Bacula для резервного копирования, после бекапа на клиенте Bacula запускает скрипт, который еще дополнительно жмет нужные данные tar'ом.


В настройках директора в job для клиента это выглядит так:

Run Script {
      Runs When = After
      Runs On Client = yes
      Runs On Success = yes
      Runs On Failure = no
      Fail Job On Error = no
      Command = "sh /home/test2.sh"
    }

Все замечательно, скрипт запускается после бекапа, но вот bacula не считает задание завершенным пока скрипт не отработает до конца, а это может занять продолжительно время, из-за чего могу создаваться ненужные очереди в директоре…


Пытался обойти это стандартным башевским амперсандом (&):
Command = "sh /home/test2.sh &"

Ничего не выходит, пытался даже из скрипта запускать другой скрипт с амперсандом, все равно bacula считает задание не завершенным пока не отработает скрипт… Оо


Есть уже конечно мысли, создавать скриптом, который запускает бакула, какой-нибудь файл в tmp, а скриптом по крону проверять наличие этого файла и запускать tar, но городить такие костыли не хочется. Должен же быть выход!


Подскажите, кто сталкивался с Bacula, как решить эту задачу?

Answer 1

[MealstroM]

«mycommand.sh | at now » пробывали такую конструкцию? можно добавить at now + 1 hour. Попробуйте так.

Comments

[Александр]

Спасибо за наводку, испытаю сегодня, отпишу, что из этого получится…

[Александр]

Удивитесь, но не сработало!

[MealstroM]

а команда в запланированные задачи добавилась?

[MealstroM]

попробуй в скрипт exit code добавить. Или в строку запуска команды

Answer 2

[merlin-vrn]

Bacula ждёт завершения всех дочерних процессов. Другими словами, вы «в фоне» не оставите задачу, если ваши процессы будут запускаться из бакулы — даже если вы сделаете форк в скрипте и убъёте родителя, сироту подхватит бакула и будет ждать её завершения. Логично, потому, что сериализация задач в бакуле сделана для ускорения каждой из них: чтобы системы «не распылялись» при выполнении, выполняя каждую из задач и все в целом бысрее.

Частично обойти это можно, указав Maximum Concurrent Jobs больше 1 в Client, Storage, Director ресурсах (где это необходимо). Тогда система сможет запустить другие задания, несмотря на то, что данное задание ещё выполняется.
Возможно, другое решение — разворачивать только что сделанный бекап из бакулы и запаковывать в tar уже его. Если сейчас память не врёт, restore job-ы по-другому работают с этими ограничениями на число одновременных задач.

Вообще у меня стойкое ощущение, что вы неправильно её используете, а точнее — архитектура бекапов у вас неправильная. Для чего вам этот tar? Если это «второй бекап», почему он запускается из bacula, если он не имеет никакого к ней отношения? Попытка сериализовать задачи? Ну так они у вас и сериализовались правильно, диск и прочие ресурсы в каждый момент времени заняты одной конкретной задачей.

Comments

[merlin-vrn]

P.S. «костыль», который вы описали в конце, мне видится самым нормальным решением вашей задачи (которая сама по себе, похоже, костыль)

[merlin-vrn]

хм. Подумал сам и понял. Maximum Concurrent Jobs для клиента установить 2, для стораджа — 1. Тогда собственно копирование в сторадж сериализуется, а если в задании есть что-то помимо этого копирования — например, RunBeforeJob и т. д. — они не задействуют сторадж и смогут выполняться, пока другое задание задействует его.

[Александр]

Спасибо вам за развернутый ответ. Бакула у нас снимает бекап с около 40 серверов. На 3 маил серверах помимо снятия бекапа бакулой, руководство требует, чтобы хранилась папка рсинка и ужатый каждодневный бекап в течении недели. От этого и приходится плясать.

Ранее было так, останавливался маил сервер, делался снапшот, из этого снапшота все переливалось рсинком в папку на отдельный винт, потом запускался тар и жал эту папку, а уже через часа два стартовала паралельно бакула. Я решил жать папку таром после бакулы… от сюда и эксперементы :)

Maximum concurent jobs для стораджа менять не могу, он вроде установлен в 10, т.к. к серверу подключено файовое хранилище с рейд6 и вроде двадцатью винтами по 2тб каждый.