{toc}
h2. Отказоустойчивость БД биллинга
В 99% случаев БД повреждается при отключении питания. Поэтому, в [системных требованиях|http://docs.carbonsoft.ru/48693408] прописано обязательное наличие настроенного [UPS|http://docs.carbonsoft.ru/51380480] для штатного завершения работы сервера.
Если UPS настроить в ближайшее время нет возможности воспользуйтесь [Как повысить выживаемость БД при сбоях питания|http://docs.carbonsoft.ru/68845609]
h2. Система бэкапов
# Бекап биллинга происходит раз в сутки с помощью команды /app/base/usr/local/bin/cron_backup.sh.
Вручную. Вы можете выполнить данную операцию следующей командой
{code}/etc/init.d/apps backup{code}
# Лог бекапа лежит в файле {code}/app/base/var/log/cron_backup.sh.log{code}
# Сам бекап состоит из последовательного вызова */app/* {color:red}*<имя app>*{color}*/service backup*, который создает бекап и */app/* {color:red}*<имя app>*{color}*/service backup_upload*, который занимается выгрузкой бекапа на ftp.
Следовательно, если проблема с бекапом была во время создания бекапа, отлаживать можно именно /app/<имя app>/service backup. А если была проблема с выгрузкой бекапа, можно отлаживать /app/<имя app>/service backup_upload. Не выполняя полную процедуру бекапа всего.
# На биллинге хранится только последний бекап. На Ftp старые бекапы не удаляются.
# В процедуре backup_upload происходит не только выгрузка, но и чтение файлов с ftp, обновление файлов и создание директорий. Все эти действия должны быть разрешены на ftp-сервере.
h2. Создание бэкапа вручную
Запустить вручную создание бэкапа можно через консоль:
{code}
/app/asr_billing/service backup
{code}
Выгрузить на фтп:
{code}
/app/asr_billing/service backup_upload
{code}
h2. Настройка автоматического резервного копирования и выгрузки по FTP
Настройка бэкпов производится меню Настройки платформы \-> Настройки резервного копирования...
!0.png|border=1!
!backupnew.png|border=1!
Заполняете все нужные поля и сохраняете изменения.
*IP-адрес FTP-сервера* \- адрес удаленнго FTP-сервера. На него будут копироваться копии БД.
{info}
Если порт на FTP сервере используется не стандартный (не 21й), то указывать его нужно через двоеточие. Например порт 1555
{code}
1.1.1.1:1555
{code}
{info}
*Бэкапить на FTP* \- выключает выгрузку на FTP.
*Имя пользователя* \- логин для авторизации на FTP-сервере.
*Пароль* \- пароль для авторизации на FTP-сервере.
*Каталог на FTP-сервере* \- непосредственно в этот каталог будут записываться копии БД.
*Ежедневная запись* \- включает резервное копирование. {color:#ff0000}Настоятельно рекомендуется активировать Ежедневную запись, без этой опции резервное копирование не будет происходить.{color}
h3. Структура каталогов на ftp-сервере:
# В каталоге, который вы указали для выгрузки на ftp будет содержать подкаталоги для каждого app.
# В этом каталоге будут лежать архивы с бекапом этого аппа и файл с md5 суммой этого файла. Например, бекап asr_billing:
\\
\\
#- backup_daily_2016-05-26_02-51_asr_billing.tar.gz
backup_daily_2016-05-26_02-51_asr_billing.tar.gz.md5
#- backup_weekly_2016-05-20_02-51_asr_billing.tar.gz
backup_weekly_2016-05-20_02-51_asr_billing.tar.gz.md5
\\
\\
# В asr_billing также есть директория static, там хранятся неизменяемые бекапы БД, но в которые происходит дозапись. Например, аудит и история фин.проводок по абонентам. В основной архив класть их слишком накладно по памяти, да и изменяются они редко. Так что эти файлы выгружаются отдельно от архива и обновляются, после того в биллинге в эти базы произошла запись (во время бекапа).
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}
h2. Свободного места на диске критично мало
Если после выполнения команды
{code}/app/asr_billing/service start {code}
Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания:
{code}Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode.
Освободите свободное место на диске и запустите команду /app/asr_billing/service start {code}
Порядок действий по восстановлению будет иной. В таком случае БД биллинга не повреждена, а остановлена для сохранности. Произведите следующие действия:
*ШАГ 1. Очистка свободного пространства*
*ШАГ 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 в консоль для отладки.
h2. Отказоустойчивость БД биллинга
В 99% случаев БД повреждается при отключении питания. Поэтому, в [системных требованиях|http://docs.carbonsoft.ru/48693408] прописано обязательное наличие настроенного [UPS|http://docs.carbonsoft.ru/51380480] для штатного завершения работы сервера.
Если UPS настроить в ближайшее время нет возможности воспользуйтесь [Как повысить выживаемость БД при сбоях питания|http://docs.carbonsoft.ru/68845609]
h2. Система бэкапов
# Бекап биллинга происходит раз в сутки с помощью команды /app/base/usr/local/bin/cron_backup.sh.
Вручную. Вы можете выполнить данную операцию следующей командой
{code}/etc/init.d/apps backup{code}
# Лог бекапа лежит в файле {code}/app/base/var/log/cron_backup.sh.log{code}
# Сам бекап состоит из последовательного вызова */app/* {color:red}*<имя app>*{color}*/service backup*, который создает бекап и */app/* {color:red}*<имя app>*{color}*/service backup_upload*, который занимается выгрузкой бекапа на ftp.
Следовательно, если проблема с бекапом была во время создания бекапа, отлаживать можно именно /app/<имя app>/service backup. А если была проблема с выгрузкой бекапа, можно отлаживать /app/<имя app>/service backup_upload. Не выполняя полную процедуру бекапа всего.
# На биллинге хранится только последний бекап. На Ftp старые бекапы не удаляются.
# В процедуре backup_upload происходит не только выгрузка, но и чтение файлов с ftp, обновление файлов и создание директорий. Все эти действия должны быть разрешены на ftp-сервере.
h2. Создание бэкапа вручную
Запустить вручную создание бэкапа можно через консоль:
{code}
/app/asr_billing/service backup
{code}
Выгрузить на фтп:
{code}
/app/asr_billing/service backup_upload
{code}
h2. Настройка автоматического резервного копирования и выгрузки по FTP
Настройка бэкпов производится меню Настройки платформы \-> Настройки резервного копирования...
!0.png|border=1!
!backupnew.png|border=1!
Заполняете все нужные поля и сохраняете изменения.
*IP-адрес FTP-сервера* \- адрес удаленнго FTP-сервера. На него будут копироваться копии БД.
{info}
Если порт на FTP сервере используется не стандартный (не 21й), то указывать его нужно через двоеточие. Например порт 1555
{code}
1.1.1.1:1555
{code}
{info}
*Бэкапить на FTP* \- выключает выгрузку на FTP.
*Имя пользователя* \- логин для авторизации на FTP-сервере.
*Пароль* \- пароль для авторизации на FTP-сервере.
*Каталог на FTP-сервере* \- непосредственно в этот каталог будут записываться копии БД.
*Ежедневная запись* \- включает резервное копирование. {color:#ff0000}Настоятельно рекомендуется активировать Ежедневную запись, без этой опции резервное копирование не будет происходить.{color}
h3. Структура каталогов на ftp-сервере:
# В каталоге, который вы указали для выгрузки на ftp будет содержать подкаталоги для каждого app.
# В этом каталоге будут лежать архивы с бекапом этого аппа и файл с md5 суммой этого файла. Например, бекап asr_billing:
\\
\\
#- backup_daily_2016-05-26_02-51_asr_billing.tar.gz
backup_daily_2016-05-26_02-51_asr_billing.tar.gz.md5
#- backup_weekly_2016-05-20_02-51_asr_billing.tar.gz
backup_weekly_2016-05-20_02-51_asr_billing.tar.gz.md5
\\
\\
# В asr_billing также есть директория static, там хранятся неизменяемые бекапы БД, но в которые происходит дозапись. Например, аудит и история фин.проводок по абонентам. В основной архив класть их слишком накладно по памяти, да и изменяются они редко. Так что эти файлы выгружаются отдельно от архива и обновляются, после того в биллинге в эти базы произошла запись (во время бекапа).
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}
h2. Свободного места на диске критично мало
Если после выполнения команды
{code}/app/asr_billing/service start {code}
Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания:
{code}Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode.
Освободите свободное место на диске и запустите команду /app/asr_billing/service start {code}
Порядок действий по восстановлению будет иной. В таком случае БД биллинга не повреждена, а остановлена для сохранности. Произведите следующие действия:
*ШАГ 1. Очистка свободного пространства*
*ШАГ 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 в консоль для отладки.