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

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

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

просмотр истории страницы
...
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}
cd /app/asr_billing/mnt/backup/
{code}
Далее, на всякий случай, выполните эту команду чтобы удалить старые неудачные копии БД:
{code}
...
{code}

На всякий случай, проверяем, что БД трафика на месте {{buff_traf.gdb}}. Если её нет, берём пустую из скелета:
На всякий случай, проверяем, что БД трафика {{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 )
mv "/var/db/buff_traf.gdb" "/var/db/buff_traf.gdb.stop"
exit
{code}

...

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

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

Выходим из контейнера командой
{code}exit{code}
Запускаем биллинг
...
{code}
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/{code}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
# Копируем в рабочий каталог демо БД
...
{code}
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/{code}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
# Копируем в рабочий каталог пустую БД
...
{excerpt}

h1. Создание резервной копии БД с последующим восстановлением
{tip}{*}Время выполнения инструкции*: до 60 минут, в зависимости от производительности сервера.{tip}
В процессе работы БД могут возникать ошибки, которые невозможно испрвить средствами СУБД. В таком случае неоходимо сделать резервную копию БД и воостановить её. Мы автоматизировали этот процесс. Для создания резервной копии БД с последующим восстановлением выполните команды:
# Создайте флаг для запуска процедуры при запуске контейнера биллинга:
{code}
touch /app/asr_billing/need_bkrestore
{code}
# Перезапустите контейнер биллинга:
{code}
/app/asr_billing/service restart
{code}

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

*1.* # Зайтите в чрут биллинга
{code}chroot /app/asr_billing{code}
{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}
# На всякий случай, проверяем, что БД трафика {{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
...
Очистив место по инструкции выше, выполните перезапуск контейнера биллинга:
{code}/app/asr_billing/service restart{code}

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

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

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

Процесс восстановления данных из бекапов можно разбить на два шага:

h2. ШАГ 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/ достаточно места.

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

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.fdb.gbk
{code}
Потом извлеките резервную копию БД из архива:
{code}
tar xzf backup_daily_2016-30-21_02-53_asr_billing.tar.gz /app/asr_billing/var/backup_data/billing.fdb.gbk -O > /mnt/backup/app/asr_billing/backup/billing.fdb.gbk
{code}
{info}
Утилита *tar* напишет сообщение:
{code}tar: Удаляется начальный `/' из имен объектов{code}
Это нормально, переходите к следующему шагу инструкции.
{info}

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

При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.fdb.gbk, тогда сделать нужно следующее:
{code}
chroot /app/asr_billing/
gbk2gdb.sh /mnt/backup/billing.fdb.gbk /var/db/billing_prepare.fdb
exit
{code}
{note}Если в процессе распаковки БД возникло сообщение об ошибке "*ERROR:database /var/db/billing_prepare.fdb already exists*", значит файл с таким названием уже существует - он мог появится при предыдущих попытках восстановить БД. Старый файл billing_prepare.fdb удалите или переместите в другое место (например, на раздел /mnt/backup)
{code}gbak:opened file /mnt/backup/billing.fdb.gbk
gbak: ERROR:database /var/db/billing_prepare.fdb already exists. To replace it, use the -REP switch
gbak:Exiting before completion due to errors{code}{note}

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

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

gbak:opened file /mnt/backup/billing.fdb.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.fdb
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:

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}

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

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

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

Превращаем восстановленный бэкап в полноценную БД
{code}
chroot /app/asr_billing/
cd /var/db
mv ./billing_prepare.fdb ./billing.fdb.stop
chown firebird:firebird ./billing.fdb.stop
exit
{code}

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

exit
{code}

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

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

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

Запускаем биллинг
{code}
echo 'stop OK' > /app/asr_billing/var/lib/app.state
/app/asr_billing/service restart
{code}

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

Проверяем что все демоны стартовали и не растут ошибки
Для этого 2 раза подряд запускаем проверку сервера:
{code}
server_check
{code}
При этом могут быть записи вида:
{code}
- Критические ошибки в логе worker за последний час: 3 [СБОЙ]
{code}
или
{code}
- Ошибки в логе traf-reporter за последний час: 4 [СБОЙ]
{code}
Если в течение двух запусков проверки значения не меняются - все в порядке.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].
Если растут значения "Ошибки в логе 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 stop
convert2to5.sh /var/db/buff_traf.gdb /var/db/buff_traf.fdb
/etc/init.d/radiusd_traf restart
{code}