Не делаются бекапы freepbx

Question

Перестали делаться бекапы, asterisk 1.8 freepbx 2.9, система достаточно нагруженая, 2000 пользователей. Бекап настроен ежедневно в полночь, зависает вот этот процесс, и висит пока его руками не снимешь. Занимает 100% одного из ядер, если процесс не снимать, накапливаются.

14786 asterisk  20   0 40812 15180  5504 R 97.0  0.2 11h27:23 php /var/lib/asterisk/bin/dumpastdb.php 20130517.00.00.01

сама база

-rw-rw-r--  1 asterisk asterisk 3604480 Май 17 11:53 astdb

Подскажите, где посмотреть причину, как починить.

Accepted Answer

2

уберите из бекапа astdb и сделайте бекап базы ручками. ну или пофиксите бекап скрипт. или наймите когто кто пофиксит.

вы же понимаете что 2000 абонентов на freepbx это не совсем то на что freepbx расчитана, правда?

ссылка удалить спам редактировать

ответил May 20 '13

meral

23347 ● 24 ● 20 ● 177
http://pro-sip.net/

Comments

Спасибо попробуем. Вполне понимаю, надо переходить на реалтайм, только gui пока не подберу к нему, редактирование частое в конфиги лезть не совсем удобно.

gwein (May 20 '13)edit

можем сделать gui назаказ. обращайтесь. freepbx расчитано на офис до 100 екстеншенов. ну во всяком случае так было при его проектировании. и проектировал его не експерт в воип.

meral (May 20 '13)edit

Да, практически уперлись в производительность, точнее сервер без проблем держит нагрузку, Load Average не больше 0.7. Возникает другая проблема, что астериск не может перечитать конфигурацию и валится при нажатии оранжевой кнопки.

gwein (May 21 '13)edit

там есть ограничение на макс длину extensions.conf.а freepbx делает копию почти всего диалплана для каждого extension.

meral (May 21 '13)edit

Поправили скрипт, заменив дамп базы копированием. Всё корректно восстанавливается, всем спасибо.

gwein (May 22 '13)edit

Answer 2

2

Делайте бакап вручную, штатный freepbx делали рукожопые.

ссылка удалить спам редактировать

ответил May 20 '13

switch
8334 ● 11 ● 7 ● 92
http://lynks.ru/

Comments

это вариант, но, freepbx делал удобные архивы, которые можно восстановить на резервной машине, при возникновении проблем с существующей.

gwein (May 20 '13)edit

Я просто скажу что в нашей системе trixbox (рекламу которой вы можете увидеть на баннере вверху страницы) полный бакап занимает 5..7 секунд, делается ежечасно и с него полностью восстанавливается состояние системы. Просто архивируются нужные файлы и все.

switch (May 20 '13)edit

Спасибо, в сторону копирования нужных файлов посмотрю. У Вас максимальное решение на 300 абонентов, если я правильно понял, боюсь нам будет маловато.

gwein (May 20 '13)edit

на сайте нет, но максимальное решение 2000 абонентов потянет вполне. Просто сервер мощнее. Ну и зависит от характера нагрузки.

switch (May 20 '13)edit

Хорошо, буду иметь ввиду. Пока хотелось бы разобраться с существующей проблемой.

gwein (May 20 '13)edit

Тут трудно определить в чем проблема. Эта система бакапов зачем-то дампит базу данных в текстовый формат, в то время когда быстрее и эффективнее бакапить файлы целиком. Вероятно то же самое касается и astdb, от чего скрипт встает враскоряку.

switch (May 20 '13)edit

Бэкап в текстовый формат - штатный бэкап mysql. Проблема врядли в нем. Если делать бэкап самих бинарных файлов mysqld, то будут проблемы с их использованием на другом сервере с другими настройками или версиях, а так же возможно скипировать нецелостныю базу с частично записанными данными. Или Вы останавливаете mysqld перед бэкапом?

Aven (May 20 '13)edit

Нет, не останавливаю, а копирую файлы как есть. Недописаные транзакции не страшны: важная информация не меняется в 99.99% времени работы сервера, а CDR не так важны, потеряется 2..3 записи - не страшно. При старте конфиг восстанавливается и БД "чинит таблицы"

switch (May 20 '13)edit

за одного битого 2 небитых дают. оно у вас просто не падало чтоб так аптимистично бекапы делать. У вас же вроде внутри тот же FreePBX, чем его перформанс отличается от штатного ?

komrad123 (May 20 '13)edit

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

switch (May 20 '13)edit

меня не за что клиентам бить, они довольны и знают, что если чтото сломается то все данные можно восстановить. А относиться так к данным клиента ( 3 CDR просрали ну и фиг с ними ) есть не уважение клиентов :)

komrad123 (May 20 '13)edit

завернусь в белую простыню и буду думать о том как я не уважаю данные клиента которыми он не пользуется. Беда...

switch (May 20 '13)edit

Answer 3

0

плюс жирный один к бекапу файлами баз данных, если таблицы не для биллинга.. для вебгуев их писали еще и не сисадмины )) От себя:

бекапьте на отдельный физический диск. Лучше, если на него в этот момент никто не пишет. Еще лучше - на рейд, хотя бы программный, или SSD (всё равно ж одним файлом);
разбейте таблицу(ы) на партиции (см. mysql partitioning). Кроме уменьшения времени копирования должно ускорить запись самого mysqld;
совсем брутально: в выходной отформатить и перемаунтить нужные разделы в btrfs (см. ext3 to btrfs). Некритичное вполне себе снапшотит, за секунды (на критичное кажется еще не ставят)). Сам не пробовал еще: откат на сделанный ранее снапшот, рейд, инкриментальное бекапирование снапшотов средствами самой btrfs. Но хотя бы снапшоты - рекомендую. Запилите всё - хороший довесок в резюмешку ))

ссылка удалить спам редактировать

ответил May 20 '13

viktorkho

434 ● 5 ● 4 ● 9

обновил May 21 '13

Comments

ИМХО рейды всякие и прочие btrfs слишком сложно для АТС, у которой главная функция - работать с наименьшим количеством сбоев. А всякие навороты надежности не добавляют: если рассыпался рейд, то данные уже не восстановить быстро. Восстанавливать систему тоже дело не 5 минут...

switch (May 20 '13)edit

софтовый линуксовый 1 рейд вполне себе решает проблемму резервирования без большого гемороя.

komrad123 (May 20 '13)edit

ну решает так решает, мне то что.

switch (May 20 '13)edit

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

viktorkho (May 21 '13)edit

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

gwein (May 21 '13)edit

Просто так не выйдет балансировка. Представьте, у вас абонент 101 зарегался на прокси, тот его перенаправляет на сервер1, Абонент пытается позвонить на транк с сервера2 и что вы будете делать? Если надо такое решение - обращайтесь. Дорого.

switch (May 21 '13)edit

Прокси пока не изучен, четкой схемы работы в данный момент нет, да и тема эта отдельного топика. Как я себе представляю, регистрация на прокси. Аутентифицированный звонок перенаправляется на астериск, там обрабатывается, если номер онлайн - возвращается обратно на прокси, после чего прокси его переадресует конкретно на ip абонента. Если требуется выпустить звонок в pstn, тут пробел. Либо напрямую, на астерисках интерфейсные карты, либо через прокси, который возвратит звонок астериску в dahdi транк. Повторюсь, белых пятен много, необходимо ещё детально изучть rfc по sip, знание протокола, достаточное для дебага транков астериска, маловато для настройки прокси.

gwein (May 21 '13)edit

Будем надеяться что у Вас будет достаточно времени и упорства чтобы решить эту задачу.

switch (May 21 '13)edit

спасибо за ответы, всё постепенно, пока нужно добиться стабильности, для запаса времени с прокси )

gwein (May 21 '13)edit

А началось всё с нехитрого "Перестали делаться бекапы..."

viktorkho (May 21 '13)edit

freepbx с балансиногом это утопия. там внутри куча блокировок которые ВСЕ прийдется переписать. балансинг возможен, но надо отказываться от очередей и callwaiting а таекже конкретно переписывать всю логику.

meral (May 21 '13)edit

От freepbx придется отказаться, в любом случае. Он достался в наследство и прижился, из-за удобства добавления/удаления абонентов, сделать переадресацию, многоканальный номеритд. Балансировка в планах на будущее, если будет развитие. Думаю, 2000 вполне потянет и одна машина с realtime архитектурой. Единственное, найти удобный способ редактирование базы.

gwein (May 21 '13)edit

способ редактирования можно создать или купить. В зависимости от баланса время/деньги. Не sql командами же конфигурировать систему ;)

switch (May 21 '13)edit

есть вроде всяке простые штуки вроде: http://sourceforge.net/projects/acami/ http://asteriskforum.ru/viewtopic.php?t=3489 который переносят один в один все настройки в реалтайм

есть другие более серьезные платные штуки вроде меры с ее РТУ или менее серьезные/платные но без лицензий вроде virtual-pbx.ru с доп плюшками в виде всяких ДВО.

или другой путь - нанять фрилансера/контору, но будет дольше чем что то готовое и не факт что дешевле.

komrad123 (May 21 '13)edit

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

gwein (May 21 '13)edit

Не делаются бекапы freepbx

3 Ответа

Comments

Comments

Comments

Ваш ответ

Закладки и информация

Статистика

Похожие вопросы: