Bacula - реквестую истории успеха.

www.linux.org.ru/wiki/en/Bacula

Как-то так...

а чем отличается установка бакулы в сложной сети от установки бакулы не в сложной сети? Достаточно написать конфиги, iptables'ом прикрыть порты вовне и все.

Годная ссылка. Спасибо, но меня больше личный опыт интересует. В частности как там с lan-free - он вроде есть, а вроде и нет - непонятно.

Отличие в возможнотях. В частности lan-free бэкапы, перенос бэкапов между двумя инсталяциями бакулы (необходимо максимально сдублировать критическую инфу по двум ЦОДам).

Не очень понял что это, но ты в принципе можешь на каждом клиенте свой сторадж поставить, что бы сеть не грузить, и на него с этого клиента копировать.

Отличие в возможнотях. В частности lan-free бэкапы, перенос бэкапов между двумя инсталяциями бакулы (необходимо максимально сдублировать критическую инфу по двум ЦОДам).

технически это выполнимо, но как на практике не знаю.

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

На случай отказа директора - делаешь резервную копию его конфига и его базы данных, в которой собственно всё и лежит.

На случай отказа директора - делаешь резервную копию его конфига и его базы данных, в которой собственно всё и лежит.

Ок. Такой вариант тоже вполне работоспособен. Это из кjробки или rsync?

Не очень понял что это, но ты в принципе можешь на каждом клиенте свой сторадж поставить, что бы сеть не грузить, и на него с этого клиента копировать.

Lan-free, это когда у тебя есть одна библиотека, драйв которой примаплен ко всех клиентам, а робот к одному упровляющему серверу. Хитрость в том, что клиенты пишут непосредственно на ленту, а управляющий сервер только ленточки подносит (с помощью робота) и следит, чтобы с двух мест не начали писать/читать.

В настройках по умолчанию как раз задано копирование своей базы данных. Правда копируется это в свой том, из которого придётся извлекать, но есть утилиты восстановления и для полностью аварийного случая, на голой системе.

При lan-free ты не забиваешь ethernet потоком данных, а льешь их по более производительному fc соединению.

Оно пишет через своего сторадж демона. Каковых ты можешь размещать где хочешь, в произвольных количествах. Главное только потом в них не запутаться :) .Соответственно, если в системе есть возможность писать на ленту или на файловую систему, то сторадж сможет это сделать.

Хотя, если стримеры уже есть то стоит почитать о совместимости. Кажется оно не со всеми стримерами работает.

Да это то понятно, что деманов можно натыкать. Но можно ли контролировать с одного хоста процесс записи на всех остальных и управлять роботом в библиотеке. В этом весь смысл.

Так директор-то один, он всем и управляет. По умолчанию все задания идут как раз по очереди, то есть наоборот, если хочешь что бы при сбое одного задания остальные продолжали выполняться - нужно совершить какие-то действия.

Ну а про робота в библиотеке - не знаю, он сможет сам последовательные обращения обслужить? Или им вручную управлять надо? Там есть возможность выполнять скрипты до и после задания, как на директоре так и на клиенте.

Ну а про робота в библиотеке - не знаю, он сможет сам последовательные обращения обслужить? Или им вручную управлять надо?

Трудно сказать, насколько я знаю робота нельзя подключать к двум хостам одновременно, но обходится ли это ограничение или нет хз. надо тестить.

Ну так и пусть по очереди пишут, и не надо одновременно. В общем, в любом случае надо видимо смотреть и пробовать. Хотя бы что бы просто составить представление о системе.

Ну так и пусть по очереди пишут, и не надо одновременно.

Я боюсь, что там фикс зонинга. Т.е. пока есть fc линк с одного хоста, робот не будет с другими общаться, но это надо проверять.

а чем отличается установка бакулы в сложной сети от установки бакулы не в сложной сети?

Тем, что бакапя локалхост с багами не сталкиваешься. А как только речь хотя бы о десятках серверов, то сразу баги вылазят.

Честно говоря, я не очень понимаю контекст, но это мне кажется хорошо и правильно.

Вот у нас начинается копирование с одного клиента на один сторадж. Соответственно оно монопольно захватывает устройство записи и больше к нему никто не может обратиться. Соответственно, когда оно завершает работу, то устройство освобождается и когда начинает выполняться следующее задание, на своём клиенте и со своим стораджем, устройство захватывается уже им.

Пожалуй единственное, что нужно уточнить - это, если устройство видно как стример, то умеет ли именно с таким стримером работать бакула, у них даже был где то список поддерживаемых стримеров. Но и это тоже легко проверить, просто поставив на произвольный свободный компьютер минимальную конфигурацию, и указав пару маленьких заданий, на посмотреть.

Что за проблемы были?

Например:

Write error sending 65536 bytes to Storage daemon: ...:9103: ERR=Input/output error

Исключительно для win32-sd агента. Весь инет завален, и решения нет. Улыбаемся и машем.

для win32-sd агента.
Улыбаемся и машем.

Эээ.., ну да.

А что, стример совсем не совместим ни с какими фрюниксами?

Тем, что бакапя локалхост с багами не сталкиваешься. А как только речь хотя бы о десятках серверов, то сразу баги вылазят.

ололо, еще один любитель локалхоста :) Чего ж вас на него так и тянет.

Вообще, когда я знакомился у меня сложилось впечатление что win32 версия там появилась чуть ли не случайно. Типа попробовали и собралось, а о поддержке этого даже думать не стали. Благо мне такие странные вещи не нужны.

человеку нужен Lan-free, т.е. видимо на каком-то сервере есть подключенный SAN. Нужно с клиента сразу писать на SAN, без серверной части.

Он вроде объяснил. Но мне кажется что в таком случае можно на каждого клиента ставить своего стораджа и тут же на месте, не отходя от кассы...?

На той стороне видна просто файловая система или может быть какое то ленточное устройство?

А что, стример совсем не совместим ни с какими фрюниксами?

Стриммера нет, пишем на диск.

Вот у нас начинается копирование с одного клиента на один сторадж. Соответственно оно монопольно захватывает устройство записи и больше к нему никто не может обратиться. Соответственно, когда оно завершает работу, то устройство освобождается и когда начинает выполняться следующее задание, на своём клиенте и со своим стораджем, устройство захватывается уже им.

Проверять надо. Ещё раз. В библиотеке минимум два устройства: собствено стример, который хорошо шарится (пробовал) и робот, который толи шарится, толи нет - надо тестировать. Разнообразные TSM/NetBackup и др. предлагают управлять роботом с одного хоста, а читать/писать со всех остальных, разгружая таким образом ethernet от трафика. Это они и называют lan-free.

Бакула этого не предоставляет. Она предлагает другой вариант. Насколько он действенен надо проверять.

Пожалуй единственное, что нужно уточнить - это, если устройство видно как стример, то умеет ли именно с таким стримером работать бакула, у них даже был где то список поддерживаемых стримеров.

Работает. Я проверял список.

Случайно или нет, но как-то винду бекапить тоже нужно, не городить же свой огород для каждой ОС.

т.е. видимо на каком-то сервере есть подключенный SAN.

На всех :). При чем пропускная очень высока (до 32 гигабит по некоторым направлениям) и полностью не задействована, а вот ethernet дупло расширять тяжеловато уже.

Что бы бекапить виндос достаточно на него поставить fd, делать на нём sd не обязательно. Или это была опечатка?

Единственный вариант, который я вижу, для того что бы не гонять трафик между хостами, это file daemon (клиент) и storage daemon (хранилище) на одном узле.

управлять роботом с одного хоста,

Скрипты RunBeforeJob и RunAfterJob, выполняемые на директоре. Или, при желании ClientRunBeforeJob и ClientRunAfterJob, на клиенте.

а читать/писать со всех остальных,

Да, располагать sd там же, где fd.

Что бы бекапить виндос достаточно на него поставить fd

Вот именно этот fd и не работает. :/

описАлся я - fd конечно, а не sd

Бекаплю бакулой около 70 серверов, багов никаких. Из критичных проблем - нужен достаточно мощный тазик для каталога с мускулем или постгресом, т.к база реально большая при большом обьеме серверов. Каждый забекапленый файл пишется в базу. Реальные цифры:
-rw-rw---- 1 mysql mysql 44G File.ibd
-rw-rw---- 1 mysql mysql 7.2G Filename.ibd
-rw-rw---- 1 mysql mysql 12G Path.ibd
и куча таблиц помельче.
А так все вообще достаточно просто.

для этого лучше сделать реплику раз в сутки ;)

На всех :). При чем пропускная очень высока (до 32 гигабит по некоторым направлениям) и полностью не задействована, а вот ethernet дупло расширять тяжеловато уже.

Ну вот выше сказали про Director, FD,SD на одной машине. Это по идее будет работать, но имхо, не лучший вариант.

в смысле? при чем тут реплика? я говорю что желательно при больших обьемах бекапируемой инфы иметь достаточно мощный тазик именно под каталог бакулы, чтобы обьем ОЗУ был соизмерим с обьемами БД.

Director, FD,SD на одной машине.

Что бы не сбивать человека с толку: директор всё таки должен быть отдельно, и один на всех.

Когда у каждого оркестранта свой дирижёр - хорошего выйдет мало.

Что бы не сбивать человека с толку: директор всё таки должен быть отдельно, и один на всех.

ну лучше так, если человеку это будет нужно. Тут жеж SAN.

Короче буду испытывать, когда новая библиотека приедет. Только так выводы можно сделать. Всем спасибо.

У него вроде надо что бы они по очереди работали, одновременно нельзя. Ну и плюс вообще, управлять из одного места проще. Хотя конфиги, да, раздуются.

Бекаплю бакулой около 70 серверов

Только linux? win серверы с win32-fd есть?

нету, зато есть freebsd. на ней тоже никаких проблем.

нету, зато есть freebsd. на ней тоже никаких проблем.

Круто. Раз уж все равно обсуждаем и есть фря - у тебя нигде коннекты от fd к sd через pf / nat не проходят?

нет, у меня датацентр - поэтому чуть другая ситуация. айпишки везде честные.

Если у тебя задача - снять нагрузку с сети, то nat между fd и sd уже не совсем уместен. Или это уже другой случай?

Если у тебя задача - снять нагрузку с сети

У меня задача заставить работать без глюков.

Ой, я тебя перепутал с ТС. Это у него трафик.