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

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (115)

просмотр истории страницы
{toc}

h2. Отказоустойчивость БД биллинга
{anchor:failover}

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

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

Если UPS настроить в ближайшее время нет возможности воспользуйтесь статьёй [Как повысить выживаемость БД при сбоях питания|http://docs.carbonsoft.ru/68845609]

h2. Система бэкапов
{info}Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании.{info}

# Бекап биллинга происходит раз в сутки с помощью команды /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-сервере.
h1. Возможные причины повреждения БД и остановки работы биллинга.

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

Запустить вручную создание бэкапа можно через консоль:
{code}
/app/asr_billing/service backup
{code}
Выгрузить на фтп:
{code}
/app/asr_billing/service backup_upload
{code}
h1. Восстановление БД в web-интерфейсе

h2. Настройка автоматического резервного копирования и выгрузки по FTP
{tip}{*}Время выполнения инструкции*: 1-15 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

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

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

!backupnew.png|border=1!
В открывшемся меню, доступные экземпляры БД будут разделены на три категории:

Заполняете все нужные поля и сохраняете изменения.
# {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 в данный список не входят.

*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-сервере:
!backup_web_2.png|border=1,width=1000!

# В каталоге, который вы указали для выгрузки на 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. Восстановление БД из бэкапа
!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. Восстановление БД из консоли (автоматический)

{tip}{*}Время выполнения инструкции*: 5-20 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

# Посмотрите список доступных резервных копий
{code}/app/asr_billing/service backup_local_list{code}
Приблизительный вывод команды:
{code}/app/asr_billing backup_local_list
backup_monthly_2019-03-31_02-50_asr_billing.tar.gz
backup_weekly_2019-03-27_02-50_asr_billing.tar.gz
backup_daily_2019-04-04_02-50_asr_billing.tar.gz

# /app/asr_billing/service backup_local_list: [ OK ]{code}
{info}Восстановление биллинга автоматический возможно только с резервных копий находящихся на локальном сервере. Если нужная резервная копия находится на FTP, Вы можете посмотреть список всех выгруженных копий и загрузить на локальный сервер:
{code}/app/asr_billing/service backup_ftp_list
/app/asr_billing/service backup_download backup_2019-03-22_2019-03-22_16-19_asr_billing.tar.gz{code}{info}
# Запустите восстановление нужной копии. Начнется процесс остановки контейнера (если он запущен), распаковки архива, наложения на архивную базу патчей и тд:
{code}/app/asr_billing/service backup_restore backup_daily_2019-04-04_02-50_asr_billing.tar.gz{code}
Приблизительный вывод:
{code}/app/asr_billing backup_restore backup_daily_2019-04-04_02-50_asr_billing.tar.gz
/app/asr_billing stop
Stopping Felicitation Daemon: [ OK ]
Stopping Jobs Daemon: [ OK ]
...
Stopping app firewall: [ OK ]

# /app/asr_billing/service stop: [ OK ]


Запускаем restore хук /usr/local/bin/restore_hook.sh
Starting xinetd: [ OK ]
Создаем бекап
gbak -b -v -ig -g -e 169.254.30.50:/var/db/billing.gdb.stop /mnt/backup/billing.gdb.stop_2019-04-04_14-01.gbk.3960.tmp -user SYSDBA -password servicem
...
Starting Message Daemon: [ OK ]
Starting Paysystems Daemon: [ OK ]
Reloading Base Web Server: [ OK ]

# /app/asr_billing/service start: [ OK ]



# /app/asr_billing/service backup_restore backup_daily_2019[ OK ]2-50_asr_billing.tar.gz:
{code}
В зависимости от размера Вашей базы, восстановление может продолжаться 10-30 минут.

h1. Восстановление БД из консоли (вручную)
{tip}{*}Время выполнения инструкции*: 15-30 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

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

...

Процесс восстановления данных из бекапов можно разбить на два шага:
*ШАГ 1: Копирование данных с сервера.*

h2. ШАГ 1: Копирование данных с сервера

Подключаемся к серверу на 33 или 22 порт, либо иной порт, в зависимости от Ваших настроек

...
*Примечание*: Восстановиться можно из локальных бэкапов, которые хранятся в /mnt/backup/app/asr_billing/backup/ Эти бэкапы не архивированные, поэтому при восстановлении из бэкапа пункт 1 ШАГа 2 нужно пропустить. Данные бэкапы делаются автоматически каждый день, если в разделе /mnt/backup/ достаточно места.

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

*1.* Подготовка
h3. 1. Подготовка

{note}
Перед процедурой восстановления во избежание срабатывания автоматических тестов нужно отключить cron:
{code}
service crond stop
{code}
{note}
Восстанавливать БД можно из локального бэкапа (Дневной, Недельный, Месячный) либо из бэкапа, который копируется на FTP сервер. На FTP сервере бэкапы хранятся в архиве, поэтому после копирования на сервер с биллингом их нужно распаковать. Например имя бэкапа backup_daily_2016-30-21_02-53_asr_billing.tar.gz, тогда команда распаковки будет выглядеть вот так:
Перед выполнением операции, перейдите в директорию где лежит требуемая резервная копия. Допустим, требуется восстановить одну из локальных резервных копий. В таком, случае выполните следующую команду:
{code}cd /app/asr_billing/mnt/backup/{code}
Далее, на всякий случай, выполните эту команду чтобы удалить старые неудачные копии БД:
{code}
rm -f /mnt/backup/app/asr_billing/backup/billing.gdb.gbk
{code}
Потом извлеките резервную копию БД из архива:
{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}
{info}
Утилита *tar* напишет сообщение:
{code}tar: Удаляется начальный `/' из имен объектов{code}
Это нормально, переходите к следующему шагу инструкции.
{info}

h3. 2. Распаковка БД

*2.* Восстанавливаем БД из бэкапа. При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.gdb.gbk, тогда сделать нужно следующее:
{code}
chroot /app/asr_billing/
...
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
gbak: ERROR:database /var/db/billing_prepare.gdb already exists. To replace it, use the -REP switch
gbak:Exiting before completion due to errors{code}{note}

*3.* Останавливаем биллинг
{note}Также в процессе распаковки может возникнуть следующая ошибка:

{code}
[root@carbon (asr_billing) /]# gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb

gbak:opened file /mnt/backup/billing.gdb.gbk
gbak:transportable backup -- data in XDR format
gbak: ERROR:cannot attach to password database
gbak: ERROR:failed to create database /var/db/billing_prepare.gdb
gbak:Exiting before completion due to errors
{code}

Возможная причина - отсутствие системных файлов БД Firebird.
Скопируйте их из /app/asr_billing/skelet/
{code}
cp -R /app/asr_billing/skelet/var/lib/firebird/system/ /app/asr_billing/var/lib/firebird/
cp -R /app/asr_billing/skelet/var/lib/firebird/data/ /app/asr_billing/var/lib/firebird/
{code}
{note}


h3. 3. Остановка биллинга
{code}
/app/asr_billing/service stop
{code}
{note}
При появлении сообщения о переходе базы в safemode такого содержания:

{code}error:

...
{note}

h3. 4. Сохранение текущей БД (опционально)

*4.* Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop (это файл текущей БД)
Если он есть, то перемещаем его рядом (в этот же каталог) с указанием даты, например 2016-08-03 (позже можно будет удалить):
{code}
...
Если произошел reset сервера (например по причине сбоя электропитания), то с высокой вероятностью база данных испортится, и файл БД переместится в /app/asr_billing/var/db/bad/billing.corrupt\*{note}

h3. 5. Перемещение файла БД на место остановленной базы

*5.* Превращаем восстановленный бэкап в полноценную БД
{code}
chroot /app/asr_billing/
...
{code}

*6.* Запускаем биллинг
На всякий случай, проверяем, что БД трафика {{buff_traf.gdb}} на месте . Если её нет, берём пустую. Если есть остановленная БД трафика, сохраняем её в той же папке для архива.
{code}
chroot /app/asr_billing/
[ -s /var/db/buff_traf.gdb.stop ] && ( mv /var/db/buff_traf.gdb.stop /var/db/buff_traf.gdb.stop.`date +%s`)
[ ! -s /var/db/buff_traf.gdb ] && ( yes | cp /skelet/var/db/buff_traf.gdb /var/db/buff_traf.gdb && chown firebird:firebird /var/db/buff_traf.gdb && chmod g+w /var/db/buff_traf.gdb )
exit
{code}

h3. 6. Обновление БД до версии биллинга

Запускаем скрипт обновления БД
{code}chroot /app/asr_billing/ update_hook.sh --force{code}
{warning}Обновление БД нужно запускать строго на остановленном биллинге\! Иначе это приведёт к разрушению базы.{warning}

h3. 7. Восстановление платежей

Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.\*
Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день.
{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}
{info} При восстановлении финансовых операций запись в [журнале платежей|http://http://docs.carbonsoft.ru/48693363] не появляется, т. е. в нем не отобразятся данные по платежам с момента сбоя базы данных до момента восстановления. {info}
{warning}Скрипт предназначен для запуска только в процессе восстановления из резервной копии\! Не запускайте на работающей базе для исправления каких-либо ошибок проведения платежей.{warning}


h3. 8. Исправление счетчиков

После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду
{code}
python2.7 /usr/lib/python2.7/site-packages/python_tools/client_fix_scripts/fix_generators2.py
{code}

h3. 9. Запуск биллинга

Выходим из контейнера командой
{code}exit{code}
Запускаем биллинг
{code}
echo 'stop OK' > /app/asr_billing/var/lib/app.state
/app/asr_billing/service restart
{code}

h3. 10. Проверка на наличине ошибок

*7.* Проверяем что все демоны стартовали и не растут ошибки
Для этого 2 раза подряд запускаем проверку сервера:
{code}
...
{code}
Если в течение двух запусков проверки значения не меняются - все в порядке.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].
Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды
{code}
...
{code}

*8.* Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.\*
Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день.
h1. Восстановление демонстрационной БД
{tip}{*}Время выполнения инструкции*: 1-10 минут{tip}

# Останавливаем биллинг
{code}
chroot /app/asr_billing/
/usr/local/bin/restore_pays.sh /var/db/raw.tmp/201609/pay/
/app/asr_billing/service stop
{code}
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
*9.* После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду
# Копируем в рабочий каталог демо БД
{code}
python /usr/lib/python2.6/site-packages/python_tools/client_fix_scripts/fix_generators2.py
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
{code}


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

*1.* Останавливаем биллинг
# Уточняем текущее состояние биллинга для сервисного скрипта
{code}echo 'stop OK' >/app/asr_billing/var/lib/app.state{code}
# Запускаем биллинг
{code}
/app/asr_billing/service stop start
{code}

*2.* При необходимости сохраняем текущую БД
h1. Восстановление пустой БД
{code} {excerpt}
mv /app/asr_billing/var/db/billing.gdb.stop /root/
{code}
{tip}{*}Время выполнения инструкции*: 1-10 минут{tip}

*3.* Копируем в рабочий каталог:
*a)* демо БД
# Останавливаем биллинг
{code}
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
/app/asr_billing/service stop
{code}
*b)* Или пустую БД
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
# Копируем в рабочий каталог пустую БД
{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}


# Уточняем текущее состояние биллинга для сервисного скрипта
{code}echo 'stop OK' >/app/asr_billing/var/lib/app.state{code}
*4.* # Запускаем биллинг
{code}
/app/asr_billing/service start
{code}
{excerpt}

h21. Свободного места на диске критично мало {anchor:emptyspace}
{tip}{*}Время выполнения инструкции*: 15-60 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip}

Если после выполнения команды
Заполнение дискового пространства вляется следствие работы операционной системы и программ, например программы Carbon Billing 5.
Если не ослеживать этот процесс и не реагировать вовремя на предупреждения [системы мониторинга|CarbonBilling:Система мониторинга], она может остановить работу биллинга во избежание повреждения базы данных биллинга.

Определить что причина именно в переполнении раздела можно так:
# Выполните следующую команду:
{code:title=Команда}/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). В случае если проблема не в этом, обратитесь в техподдержку.
h2. Очистка свободного места на диске

*ШАГ 2. Восстановление БД в работу*
{tip}{*}Время выполнения инструкции*: 5-50 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip}

Мы описали это в достаточно объёмной статье [CarbonBilling:Мало места на диске]. Начине с заголовка "*Почему так получилось и как починить*", там описана краткая инструкция на примере раздела */mnt/log*, и дальше рассказано с каким данными что можно сделать.

h2. Восстановление БД в работу

{tip}{*}Время выполнения инструкции*: 5-10 минут, в зависимости от разера БД{tip}

h3. Биллинг в safemode

*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 chown firebird:firebird /var/db/billing.gdb.stop{code}
# На всякий случай, проверяем, что БД трафика {{buff_traf.gdb}} на месте. Если её нет, берём пустую:
{code}
[ ! -s /var/db/buff_traf.gdb ] && ( yes | cp /skelet/var/db/buff_traf.gdb /var/db/buff_traf.gdb && chown firebird:firebird /var/db/buff_traf.gdb && chmod g+w /var/db/buff_traf.gdb )
{code}
*4.* # Выйдите из чрута и снова выполните запуск биллинга
{code}exit
echo 'stop OK' >/app/asr_billing/var/lib/app.state
/app/asr_billing/service restart{code}

h2. Решение проблем с бекапами
h3. Биллинг не в safemode, при открытии абонента - ошибка Feedback

Если в биллинге и интерфейсе администрирования платформы появился баннер, оповещающий об ошибке ежедневного бекапа, Вы можете изучить причину по логу, он находится по следующему пути:
{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 в консоль для отладки.
Биллинг не находится в состоянии safemode, но при открытии карточки абонента выходит ошибка "Feedback", в расширенном описании ошибки написано следующее:
{code}DatabaseError: ('Error while commiting transaction:\n- SQLCODE: -902\n- I/O error for file "/mnt/var/tmp_root/fb_table_IY4dTZ"\n- Error while trying to write to file\n- No space left on device', -902, 335544344){code}
Это означает, место кончилось на разделе */mnt/var*.
Очистив место по инструкции выше, выполните перезапуск контейнера биллинга:
{code}/app/asr_billing/service restart{code}