Восстановление БД биллинга из резервной копии.

{toc}

{anchor:failover}

h1. Отказоустойчивость БД биллинга

В 99% случаев БД повреждается при отключении питания. Поэтому, в [системных требованиях|http://docs.carbonsoft.ru/48693408] прописано обязательное наличие настроенного [UPS|http://docs.carbonsoft.ru/51380480] для штатного завершения работы сервера.

h1. Возможные причины повреждения БД и остановки работы биллинга.

Работа биллинга может быть остановлена по двум причинам:
# Повреждение БД. В данном случае требуется восстановить БД из последней успешной резервной копии. Возможные причины:
#* Некорректная перезагрузка сервера, в процессе которой работа сервера была остановлена до остановки работы СУБД: *shutdown* или *reboot* без предварительной остановки платформы */etc/init.d/apps stop*
#* Внезапное завершение работы по причине прекращения электропитания; жесткая перезагрузка сервера - эти действия могут привести к повреждению файловой системы, остановке сервера во время записи в файл БД
#* Заполнение раздела с БД до 100%, невозможность завершить запись в файл БД.
#* Результат некорректных действий технического персонала с БД или при проведении технических работ на сервере.
# Остановка работы без повреждения БД. Безопасная остановка работы сервера, база не повреждается и может быть восстановлена в работу после устранения всех проблем. Возможные причины:
#* Нехватка свободного места на одном из разделов, в результате чего система мониторинга останавливает работу биллинга до момента очистки места ([инструкция|#emptyspace]).

h1. Восстановление БД в web-интерфейсе

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

!backup_web_1.png|border=1,width=1000!

В открывшемся меню, доступные экземпляры БД будут разделены на три категории:

# {color:#000000}{*}Список баз в safemode (не поврежденных)*{color}{color:#000000}:{color} базы остановленные системой мониторинга состояния сервера. Такие базы не повреждены, однако перед восстановлением следует освободить место по [инструкции|#emptyspace].
# {color:#000000}{*}Список повреждённых баз{*}{color}{color:#000000}:{color} такие базы невозможно восстановить автоматический и требует ручного анализа проблемы. Рекомендуется восстанавливаться из резервной копии.
# {color:#000000}{*}Список резервных копий{*}{color}{color:#000000}:{color} резервные копии, хранящиеся непосредственно на сервере в директории */app/asr_billing/mnt/backup*. Копии, выгруженные на ftp в данный список не входят.

Для восстановление нужного экземпляра БД, нажмите кнопку "Восстановить" в соответствующей строке.

!backup_web_2.png|border=1,width=1000!

При нажатии кнопки "Восстановить", автоматический Вы будете перенаправлены на страницу, в которой отображается лог выполнения операции восстановления

!backup_web_3.png|border=1,width=1000!

Следующая строка в логе соответствует завершению процесса восстановления:
{code}# /app/asr_billing/service restart: [ OK ]{code}
После окончания процесса, нажмите на пиктограмму в виде стрелки в верхнем левом углу страницы, чтобы вернуться в интерфейс базовой системы.

!backup_web_4.png|border=1,width=1000!

h1. Восстановление БД из консоли

{color:#000000}{*}Резервное копирование и восстановление из бекапов при помощи WinSCP{*}{color}

В случае переноса данных системы на другой компьютер или переустановки системы с последующим восстановлением конфигурации и базы пользователей, необходимо сначала сделать полный бекап данных с работающей системы. Для того чтобы сделать полный бекап системы необходимо скопировать резервные копии самой базы пользователей и бекап конфигурационного файла системы. Это делается с помощью программы winscp, дистрибутив которой вы всегда можете найти в Интернете по адресу: [http://winscp.net/|http://winscp.net/+] Программа бесплатна.

Подключаемся к серверу на 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/ достаточно места.

h2. ШАГ 2: Восстановление из бэкапа

{code}cd /app/asr_billing/mnt/backup/{code}
Далее, извлеките резервную копию БД из архива:
{code}

chroot /app/asr_billing/
gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb
exit
{code}
{note}Если в процессе распаковки БД возникло сообщение об ошибке "*ERROR:database /var/db/billing_prepare.gdb already exists*", значит файл с таким названием уже существует - он мог появится при предыдущих попытках восстановить БД. Старый файл billing_prepare.gdb удалите или переместите в другое место (например, на раздел /mnt/backup)
{code}gbak:opened file /mnt/backup/billing.gdb.gbk

/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}

{code}
cd /app/asr_billing/var/db/
mv billing.gdb.stop blling.2016-08-03.gdb.stop
{code}

chroot /app/asr_billing/
cd /var/db
mv ./billing_prepare.gdb ./billing.gdb.stop
chown firebird:firebird ./billing.gdb.stop

{code}
chroot /app/asr_billing/
service xinetd restart
service admin_web_server restart
service billing_db restart
service nginx restart
/usr/local/bin/restore_pays.sh /var/db/raw.tmp/201609/pay/

{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}

h1. Восстановление демонстрационной или пустой БД

*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}

h1. Свободного места на диске критично мало {anchor:emptyspace}

Если после выполнения команды

*ШАГ 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*. Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 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
chown firebird:firebird /var/db/billing.gdb.stop{code}
*4.* Выйдите из чрута и снова выполните запуск биллинга
{code}exit
echo 'stop OK' >/app/asr_billing/var/lib/app.state
/app/asr_billing/service restart{code}