Автоматическое резервное копирование базы данных

Этот перевод выполнен автоматически и ещё не вычитан. Читать английскую версию

Коммутатор может создавать резервные копии своей базы данных по расписанию, не прекращая обработку звонков. В этом руководстве вы включаете ежедневное резервное копирование, разбираетесь с форматами и настраиваете копирование на удалённый сервер, чтобы восстановить коммутатор даже при потере его диска. Рассчитывайте примерно на 15 минут, плюс время, которое нужно поддержке для настройки удалённого копирования.

Перед началом

У вас есть доступ Administrator (администратор) к панели. Настройки резервного копирования применяются к среде, в которую вы вошли.
Вы знаете час с наименьшим трафиком. Резервное копирование выполняется онлайн, но сильно нагружает диск и базу данных, что может повлиять на обработку звонков.
Для удалённого копирования: сервер, который принимает файлы (FTP, TFTP, SFTP или аналогичный), а также его адрес, учётные данные и папка.

Шаг 1: Настройте расписание резервного копирования

Откройте System Management → System Parameters (системные параметры).
Нажмите Backup, Data Retention (резервное копирование, хранение данных).

В разделе Backup (резервное копирование) заполните поля:

Поле	Значение	Примечания
Schedule (расписание)	`Daily`	`Never` (по умолчанию) отключает резервное копирование. Также доступны `Weekly` и `Monthly`
Start Time (время начала)	Время вне пиковой нагрузки, например `04:30`	Шаг - полчаса, в часовом поясе сервера
Dump Format (формат дампа)	`SQL Dump (Text)`	См. форматы ниже
Generations (поколения)	`7`	Сколько резервных копий хранится на коммутаторе, от `1` до `15`. Более старые удаляются
Compression (сжатие)	`gzip`	`bzip2` даёт файлы меньшего размера, но работает дольше; также доступно `no compression`

Отметьте Notify on Success (уведомлять об успехе), если хотите получать письмо после каждого успешного резервного копирования. Этот параметр показывается только в корневой среде.
Нажмите Save (сохранить).

Screenshot "tutorials/backup-data-retention" has not been generated yet — see scripts/screenshots/screens.yml.

Результат: резервное копирование начинается в течение получаса после Start Time. Еженедельное или ежемесячное копирование запускается, когда последней копии не меньше недели или месяца, поэтому оно сохраняет день недели или день месяца первого запуска. Если вы включаете еженедельное копирование в пятницу днём со Start Time 04:30, оно запускается каждую субботу в 04:30.

Форматы различаются тем, как быстро и где их можно восстановить:

Dump Format	Скорость восстановления	Восстановление на другой версии базы данных	Размер
SQL Dump (Text)	Умеренная	Да, на любой версии. Самый безопасный выбор	Средний
SQL Dump (Binary)	Хорошая	Только на той же основной версии	Маленький
SQL Dump (TAR)	Хорошая; можно выбрать, какие таблицы и данные восстанавливать	Только на той же основной версии	Средний
DB Snapshot	Самая высокая	Только на точно такой же версии	Большой

DB Snapshot доступен только в корневой среде и копирует базы данных всех сред одновременно.

Шаг 2: Проверьте файлы резервных копий

Каждый запуск записывает в /var/backups/env<N>/ на коммутаторе, где <N> - номер среды:

по одному файлу на каждую базу данных (основная база, балансы и CDR) с именем env<N>-backup-<database>-<YYYYMMDD> и расширением, соответствующим формату и сжатию, например .sql.gz;
архив файлов среды с именем var_env<N>-<YYYYMMDD>.tar.gz.

Вся работа резервного копирования записывается в журнал /var/log/backup.log. Неудачное резервное копирование отправляет письмо-уведомление на адрес корневого клиента.

Шаг 3: Копируйте каждую резервную копию на удалённый сервер

После записи каждого файла резервное копирование запускает скрипт /var/db/pgsql/ecopy, если он существует, с полным путём к файлу в качестве единственного аргумента. Код выхода 0 означает, что копирование удалось; любой другой код записывается в журнал как сбой и отправляет письмо External copy failed. Пример скрипта, который выгружает файлы на TFTP-сервер, находится в /home/ssp/scripts/ecopy_tftp.sh.

Скрипт выполняется на самом коммутаторе, поэтому его устанавливает поддержка FlySIP:

Подготовьте удалённый сервер и папку для резервных копий.
Отправьте в поддержку FlySIP адрес, протокол, учётные данные и папку.
Дождитесь, пока поддержка подтвердит, что скрипт установлен.

Коммутатор удаляет старые резервные копии только со своего диска, в соответствии с Generations. Ротацию копий на удалённом сервере настройте самостоятельно, например заданием очистки, которое хранит последние 30 дней.

Шаг 4: Проверьте

Дождитесь первого запуска по расписанию или попросите поддержку запустить его.
Найдите в /var/log/backup.log или в письме об успехе строку backup procedure has been finished successfully.
Убедитесь, что файлы поступили на удалённый сервер и их размер правдоподобен.

Восстановление после полной потери

Если коммутатор потерян, а резервного сервера нет:

Установите коммутатор с нуля с установочного образа FlySIP.
Обратитесь в поддержку FlySIP, чтобы активировать новый сервер, и сообщите расположение последних файлов резервных копий на вашем удалённом сервере.
Поддержка восстанавливает базу данных из резервной копии.

Что дальше

Архивация и удаление старых CDR: половина Data Retention (хранение данных) того же экрана.
Системные параметры: все настройки среды.
Требования к оборудованию: отдельные диски, рекомендуемые для резервных копий и журналов.