... При остановке работы биллинга по одной из вышеуказанных причин, Вы можете воспользоваться интерфейсом восстановления биллинга в web-интерфейсе. Для этого, нажмите на пиктограмму интерфейса управления абонентами. !backup_web_1.png|border=1,width=1000! В открывшемся меню, доступные экземпляры БД будут разделены на три категории: # *{color:green}Список баз в safemode (не поврежденных){color}*: базы остановленные системой мониторинга состояния сервера. Такие базы не повреждены, однако перед восстановление следует # *{color:red}Список повреждённых баз{color}* # *{color}Список резервных копий{color}* !backup_web_2.png|border=1,width=1000! !backup_web_3.png|border=1,width=1000! !backup_web_4.png|border=1,width=1000! h2. Восстановление БД из бэкапа из консоли {color:#000000}{*}Резервное копирование и восстановление из бекапов при помощи WinSCP{*}{color} В случае переноса данных системы на другой компьютер или переустановки системы с последующим восстановлением конфигурации и базы пользователей, необходимо сначала сделать полный бекап данных с работающей системы. Для того чтобы сделать полный бекап системы необходимо скопировать резервные копии самой базы пользователей и бекап конфигурационного файла системы. Это делается с помощью программы winscp, дистрибутив которой вы всегда можете найти в Интернете по адресу: [http://winscp.net/|http://winscp.net/+] Программа бесплатна. Процесс восстановления данных из бекапов можно разбить на два шага: *ШАГ 1: Копирование данных с сервера.* Подключаемся к серверу на 33 или 22 порт, либо иной порт, в зависимости от Ваших настроек !рез1.JPG|border=1! Убедитесь что данные введены верно и нажимайте "Login", после подключения вы увидите окно, похожее на обычный файловый менеджер с двумя панелями, слева будет ваш локальный компьютер, справа - файловая система Carbon Billing, вас интересует каталог BACKUP на ней. Путь такой: /app/asr_billing/mnt/backup/ Здесь хранятся ежедневные, ежемесячные и еженедельные бэкапы. Вы можете выбрать те, которые нужны Вам. *Примечание*: Статистика копируется отдельно из папки: /app/collector/var/stat/raw/ *Примечание*: Восстановиться можно из локальных бэкапов, которые хранятся в /mnt/backup/app/asr_billing/backup/ Эти бэкапы не архивированные, поэтому при восстановлении из бэкапа пункт 1 ШАГа 2 нужно пропустить. Данные бэкапы делаются автоматически каждый день, если в разделе /mnt/backup/ достаточно места. *ШАГ 2: Восстановление из бэкапа.* *1.* Подготовка Восстанавливать БД можно из локального бэкапа (Дневной, Недельный, Месячный) либо из бэкапа, который копируется на FTP сервер. На FTP сервере бэкапы хранятся в архиве, поэтому после копирования на сервер с биллингом их нужно распаковать. Например имя бэкапа backup_daily_2016-30-21_02-53_asr_billing.tar.gz, тогда команда распаковки будет выглядеть вот так: {code} tar xzf backup_daily_2016-30-21_02-53_asr_billing.tar.gz /app/asr_billing/var/backup_data/billing.gdb.gbk -O > /mnt/backup/app/asr_billing/backup/billing.gdb.gbk {code} *2.* Восстанавливаем БД из бэкапа. При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.gdb.gbk, тогда сделать нужно следующее: {code} chroot /app/asr_billing/ gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb exit {code} *3.* Останавливаем биллинг {code} /app/asr_billing/service stop {code} {note} При появлении сообщения о переходе базы в safemode такого содержания: {code}error: asr_billing in safe mode. Check logs. /app/base/var/log/watchdog.log and other log You must fix the problem or get support from developer! status: safemode from chroot /app/asr_billing /sbin/init start prevstate=stop OK echo 'stop OK' >/app/asr_billing/var/lib/app.state {code} Переходите к пункту 4. В данном случае, биллинг уже является остановленным. {note} *4.* Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop (это файл текущей БД) Если он есть, то перемещаем его рядом (в этот же каталог) с указанием даты, например 2016-08-03 (позже можно будет удалить): {code} cd /app/asr_billing/var/db/ mv billing.gdb.stop blling.2016-08-03.gdb.stop {code} {note}Если же файла нет, то приступайте к пункту 5 Если произошел reset сервера (например по причине сбоя электропитания), то с высокой вероятностью база данных испортится, и файл БД переместится в /app/asr_billing/var/db/bad/billing.corrupt\*{note} *5.* Превращаем восстановленный бэкап в полноценную БД {code} chroot /app/asr_billing/ cd /var/db mv ./billing_prepare.gdb ./billing.gdb.stop chown firebird:firebird ./billing.gdb.stop exit {code} *6.* Запускаем биллинг {code} echo 'stop OK' > /app/asr_billing/var/lib/app.state /app/asr_billing/service restart {code} *7.* Проверяем что все демоны стартовали и не растут ошибки Для этого 2 раза подряд запускаем проверку сервера: {code} server_check {code} При этом могут быть записи вида: {code} - Критические ошибки в логе worker за последний час: 3 [СБОЙ] {code} или {code} - Ошибки в логе traf-reporter за последний час: 4 [СБОЙ] {code} Если в течение двух запусков проверки значения не меняются - все в порядке. Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку. Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды {code} chroot /app/asr_billing/ yes | cp /skelet/var/db/buff_traf.gdb /var/db/ chown firebird:firebird /var/db/buff_traf.gdb chmod g+w /var/db/buff_traf.gdb /etc/init.d/radiusd_traf restart {code} *8.* Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.\* Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день. {code} chroot /app/asr_billing/ /usr/local/bin/restore_pays.sh /var/db/raw.tmp/201609/pay/ {code} *9.* После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду {code} python /usr/lib/python2.6/site-packages/python_tools/client_fix_scripts/fix_generators2.py {code} h2. Восстановление демонстрационной или пустой БД *1.* Останавливаем биллинг {code} /app/asr_billing/service stop {code} *2.* При необходимости сохраняем текущую БД {code} mv /app/asr_billing/var/db/billing.gdb.stop /root/ {code} *3.* Копируем в рабочий каталог: *a)* демо БД {code} yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop {code} *b)* Или пустую БД {code} yes | cp -p /app/asr_billing/skelet/var/db/billing_system.gdb /app/asr_billing/var/db/billing.gdb.stop {code} А также обязательно пустую БД трафика {code} yes | cp -p /app/asr_billing/skelet/var/db/buff_traf.gdb /app/asr_billing/var/db/buff_traf.gdb.stop {code} *4.* Запускаем биллинг {code} /app/asr_billing/service start
|
... {code}/app/asr_billing/service start {code} Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания: {code}Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode. Освободите свободное место на диске и запустите команду /app/asr_billing/service start {code} Порядок действий по восстановлению будет иной. В таком случае БД биллинга не повреждена, а остановлена для сохранности. Произведите следующие действия: *ШАГ 1. Очистка свободного пространства* Для определения проблемного разела, Вы можете использовать утилиту *df*, отфильтровава вывод утилитой *grep*, чтобы видеть только физические разделы {code}[root@devel185 ~]# df -h | grep -wE '/|/mnt' /dev/vda1 9,5G 3,5G 5,6G 39% / /dev/vda9 71G 1,2G 67G 2% /mnt/backup /dev/vda3 96G 4,0G 88G 5% /mnt/db /dev/vda8 3,8G 46M 3,6G 2% /mnt/etc /dev/vda7 96G 827M 91G 1% /mnt/log /dev/vda2 711G 2,7G 673G 1% /mnt/var{code} Определив проблемный раздел (занято олее 85%), необходимо найти что занимает более всего пространства. Сделать это можно утилитой *du*, например: {code}du -sch /mnt/var/app/* 915M /mnt/var/app/asr_billing 478M /mnt/var/app/asr_cabinet 80M /mnt/var/app/asr_fiscal 77M /mnt/var/app/auth 68M /mnt/var/app/base 206M /mnt/var/app/collector 214M /mnt/var/app/monitoring 104M /mnt/var/app/xge 2,1G итого{code} Определив пробленые каталоги и/или файлы, дальнейшие действия - по ситуации: - */mnt/vat*, */mnt/stat*. Наиболее частой проблемой является заполнение раздела */mnt/var* (либо */mnt/stat*), а именно каталога */mnt/var/app/collector/var/stat/binstat/*. Решение описано в [следующей статье|CarbonBilling:Добавление диска под статистику]. - */mnt/log*. При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону. Если явно больших файлов лога не обнаружено, вероятно у Вас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи]. - */mnt/backup*. Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой *du*. В случае если проблема с разделом восникает часто, вероятно Вам следует [добавить места под логи|CarbonBilling:Добавление диска под бэкапы] - */mnt/etc*. В случае заполнения раздела */mnt/etc* обратитесь в техподдержку. - */mnt/db*. Если Ваша аппаратная платформа соответствует нашим [системным требованиям|CarbonBilling:Системные требования к биллингу], вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более). - */ (корневой раздел ОС)*. Убедитесь что раздел не занят результатом Ваших собственных действия, например при выполнении заданий добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home). Удалить файлы Вы можете утилитой rm: {code}rm -f /mnt/log/app/collector/log/nf_collector.log{code} Заполнение дискового пространства вляется обычным процессом работы ОС и ситуация при которой один из разделов запоняется до предела, в результате чего watchdog для сохранности останавливает биллинг является абсолютно нормальной. Тем не менее, работы по диагностике и решению проблемы требуют определенного уровня знаний от технического специалиста. Объем работы выполняемой теподдержкой Carbon Soft по диагностике и решению проблемы напрямую зависит от выбранного Вами [уровня технической поддержки|http://www.carbonsoft.ru/support/]. *ШАГ 2. Восстановление БД в работу* *1.* Зайтите в чрут биллинга {code}chroot /app/asr_billing{code} *2.* Найдите последний по времени создания файл в папке /var/db/safemode, для этого выполните команду {code}ls -1trhd /var/db/safemode/* | tail -n 1 /var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb{code} *3.* Скопируйте данный файл в папку, где он должен располагаться для запуска биллинга и выставьте правильные права доступа к файлу {code}mv /var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb /var/db/billing.gdb.stop chmod firebird:firebird /var/db/billing.gdb.stop{code} *4.* Выйдите из чрута и снова выполните запуск биллинга {code}exit /app/asr_billing/service restart{code} h2. Решение проблем с бекапами Если в биллинге и интерфейсе администрирования платформы появился баннер, оповещающий об ошибке ежедневного бекапа, Вы можете изучить причину по логу, он находится по следующему пути: {code}/app/base/var/log/cron_backup.sh.log{code} h3. Самые распространенные причины # Не смог создаться бекап *asr_billing*. Скорее всего, выявились ошибки БД. Об этом напишет в логе, и в этом случае лучше сразу обратиться в техподдержку. Дополнительные логи утилиты *gbak*, которая не смогла снять бекап доступны в файле {code}/app/asr_billing/var/log/backup_db_v2.sh.log{code} # Бекап не смог выложиться на ftp. В случае ошибок curl, он выполняется повторно с флагом \-v и в логе пишется строка с аргументами, которые передаются в curl. Вы можете напрямую скопировать команду с curl в консоль для отладки.
|