Просмотр Исходного

h2. Настройка бэкапов FTP

1. Проверьте что на сервере есть утилита ftp командой
{code}which ftp{code}


Если в результате вы получите вывод похожий на: /usr/bin/which: no ftp in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin) значит утилита ftp не установлена и поставить её нужно вручную командой

{code}yum install ftp{code}


2. Настройка бэкпов производится в консольном меню \-> Carbon Billing 5 \-> Настройки резервного копирования...

!backup.png|border=1,width=500,height=250!

Заполняете все нужные поля и сохраняете изменения.

h2. Восстановление БД из бэкапа

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

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

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

Подключаемся к серверу на 33 порт.

!рез1.JPG|border=1!

Убедитесь что данные введены верно и нажимайте "Login", после подключения вы увидите окно, похожее на обычный файловый менеджер с двумя панелями, слева будет ваш локальный компьютер, справа - файловая система Carbon Billing, вас интересует каталог BACKUP на ней.

Путь такой: /app/asr_billing/mnt/backup/

Здесь хранятся ежедневные, ежемесячные и еженедельные бэкапы. Вы можете выбрать те, которые нужны Вам.

*Примечание*: Статистика копируется отдельно из папки: /app/collector/var/stat/raw/


*ШАГ 2: Восстановление из бэкапа (При переезде).*

*1.* Копируем бэкап в каталог /root на сервере.

*2.* Восстанавливаем БД из бэкапа
{code}
chroot /app/asr_billing/
cd /usr/local/bin
gbk2gdb.sh /root/ваш_бекап /var/db/billing_prepare.gdb
exit
{code}

*3.* Останавливаем биллинг

{code}
/app/asr_billing/service stop
{code}

*4.* Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop
Если он есть, то перемещаем его в каталог root на всякий случай или копируем рядом (в этот же каталог) с указанием числа (позже можно будет удалить):

{code}
cd /app/asr_billing/var/db/
mv billing.gdb.stop /root/billing.gdb.stop
или
mv billing.gdb.stop blling<дата>.gdb.stop
{code}
*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}
/app/asr_billing/service start
{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/
{code}
После этого выполните проверку сервера еще 2 раза подряд. Если все-таки растут значения "Ошибки в логе traf-reporter за последний час" - сразу обратитесь в техническую поддержку.