Вы просматриваете старую версию данной страницы. Смотрите текущую версию.
Сравнить с текущим |
просмотр истории страницы
Создание бэкапа
Запустить вручную создание бэкапа можно через консоль:
chroot /app/asr_billing /usr/local/bin/db_backup.sh
Настройка бэкапов по FTP
Настройка бэкпов производится меню Настройки платформы -> Настройки резервного копирования...
Unable to render embedded object: File (0.png) not found.
Unable to render embedded object: File (backupnew.png) not found.
Заполняете все нужные поля и сохраняете изменения.
IP-адрес FTP-сервера - адрес удаленнго FTP-сервера. На него будут копироваться копии БД.
 | Если порт на FTP сервере используется не стандартный (не 21й), то указывать его нужно через двоеточие. Например порт 1555
1.1.1.1:1555 |
Имя пользователя - логин для авторизации на FTP-сервере.
Пароль - пароль для авторизации на FTP-сервере.
Каталог на FTP-сервере - непосредственно в этот каталог будут записываться копии БД.
Ежедневная/Еженедельная/Ежемесячная запись - временные интервалы за которые будет производится резервное копирование БД пользователей. Можно выбрать все 3 пункта одновременно.
Настоятельно рекомендуется активировать Ежедневную запись
Восстановление БД из бэкапа
Резервное копирование и восстановление из бекапов при помощи WinSCP
В случае переноса данных системы на другой компьютер или переустановки системы с последующим восстановлением конфигурации и базы пользователей, необходимо сначала сделать полный бекап данных с работающей системы. Для того чтобы сделать полный бекап системы необходимо скопировать резервные копии самой базы пользователей и бекап конфигурационного файла системы. Это делается с помощью программы winscp, дистрибутив которой вы всегда можете найти в Интернете по адресу: http://winscp.net/ Программа бесплатна.
Процесс восстановления данных из бекапов можно разбить на два шага:
ШАГ 1: Копирование данных с сервера.
Подключаемся к серверу на 33 или 22 порт, либо иной порт, в зависимости от Ваших настроек
Убедитесь что данные введены верно и нажимайте "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, тогда команда распаковки будет выглядеть вот так:
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
2. Восстанавливаем БД из бэкапа. При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.gdb.gbk, тогда сделать нужно следующее:
chroot /app/asr_billing/
gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb
exit
3. Останавливаем биллинг
/app/asr_billing/service stop
 | При появлении сообщения о переходе базы в safemode такого содержания:
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 Переходите к пункту 4. В данном случае, биллинг уже является остановленным. |
4. Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop (это файл текущей БД)
Если он есть, то перемещаем его рядом (в этот же каталог) с указанием даты, например 2016-08-03 (позже можно будет удалить):
cd /app/asr_billing/var/db/
mv billing.gdb.stop blling.2016-08-03.gdb.stop
| Если же файла нет, то приступайте к пункту 5 Если произошел reset сервера (например по причине сбоя электропитания), то с высокой вероятностью база данных испортится, и файл БД переместится в /app/asr_billing/var/db/bad/billing.corrupt* |
5. Превращаем восстановленный бэкап в полноценную БД
chroot /app/asr_billing/
cd /var/db
mv ./billing_prepare.gdb ./billing.gdb.stop
chown firebird:firebird ./billing.gdb.stop
exit
6. Запускаем биллинг
echo 'stop OK' > /app/asr_billing/var/lib/app.state
/app/asr_billing/service restart
7. Проверяем что все демоны стартовали и не растут ошибки
Для этого 2 раза подряд запускаем проверку сервера:
server_check
При этом могут быть записи вида:
- Критические ошибки в логе worker за последний час: 3 [СБОЙ]
или
- Ошибки в логе traf-reporter за последний час: 4 [СБОЙ]
Если в течение двух запусков проверки значения не меняются - все в порядке.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку.
Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды
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
8. Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.*
Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день.
chroot /app/asr_billing/
/usr/local/bin/restore_pays.sh /var/db/raw.tmp/201609/pay/
9. После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду
python /usr/lib/python2.6/site-packages/python_tools/client_fix_scripts/fix_generators2.py
Как повысить выживаемость БД при сбоях питания
В 99% случаев БД повреждается при отключении питания. Поэтому, у нас в системных требованиях прописано обязательное наличие настроенного UPS для штатного завершения работы сервера.
Для значительного повышения выживаемости БД нужно:
- Настроить UPS.
Если у Вас нет такой возможности возможности, можно настроить параметры монтирования раздела БД, чтобы снизить вероятность поломки, для этого:
- Проверьте, что на вашей установке был создан спец. раздел для БД (в ранних версиях установки доп.раздел не создавался). Например:
Раздела нет: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 180G 0 disk ├─vda1 252:1 0 3,7G 0 part / ├─vda2 252:2 0 14G 0 part /app ├─vda3 252:3 0 15,5G 0 part /mnt/backup ├─vda4 252:4 0 1,9G 0 part /mnt/etc ├─vda5 252:5 0 100G 0 part /mnt/var ├─vda6 252:6 0 39,1G 0 part /mnt/log └─vda7 252:7 0 5,9G 0 part [SWAP] Раздел есть: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 9,8G 0 part / ├─sda2 8:2 0 641,8G 0 part /mnt/var ├─sda3 8:3 0 97,7G 0 part /mnt/db <-- нужный раздел ├─sda4 8:5 0 14,7G 0 part /app ├─sda5 8:6 0 97,7G 0 part /mnt/log ├─sda6 8:7 0 3,9G 0 part /mnt/etc ├─sda7 8:8 0 64,2G 0 part /mnt/backup └─sda8 8:9 0 2G 0 part [SWAP]
Если раздела нет, то нужно будет с нуля выполнить установку биллинга.
- Настроить файл /etc/fstab. Добавить для раздела /mnt/db параметр data=journal. Например:
UUID=xxxxxxxxxxxxxx /mnt/db ext4 nodiratime,noatime,async 1 1 заменить на UUID=xxxxxxxxxxxxxx /mnt/db ext4 nodiratime,noatime,async,data=journal 1 1
Восстановление демонстрационной или пустой БД
1. Останавливаем биллинг
/app/asr_billing/service stop
2. При необходимости сохраняем текущую БД
mv /app/asr_billing/var/db/billing.gdb.stop /root/
3. Копируем в рабочий каталог:
a) демо БД
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
b) Или пустую БД
yes | cp -p /app/asr_billing/skelet/var/db/billing_system.gdb /app/asr_billing/var/db/billing.gdb.stop
А также обязательно пустую БД трафика
yes | cp -p /app/asr_billing/skelet/var/db/buff_traf.gdb /app/asr_billing/var/db/buff_traf.gdb.stop
4. Запускаем биллинг
/app/asr_billing/service start
Свободного места на диске критично мало
Если после выполнения команды
/app/asr_billing/service start
Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания:
Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode. Освободите свободное место на диске и запустите команду /app/asr_billing/service start
Порядок действий по восстановлению будет иной. В таком случае БД биллинга не повреждена, а остановлена для сохранности. Произведите следующие действия:
ШАГ 1. Очистка свободного пространства
ШАГ 2. Восстановление БД в работу
1. Зайтите в чрут биллинга
chroot /app/asr_billing
2. Найдите последний по времени создания файл в папке /var/db/safemode, для этого выполните команду
# ls -1trhd /var/db/safemode/* | tail -n 1 /var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb
3. Скопируйте данный файл в папку, где он должен располагаться для запуска биллинга и выставьте правильные права доступа к файлу
# 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
4. Выйдите из чрута и снова выполните запуск биллинга
# exit # /app/asr_billing/service restart