Автоматичне резервне копіювання бази даних

Цей переклад зроблено автоматично і ще не вичитано. Читати англійську версію

Комутатор може створювати резервні копії своєї бази даних за розкладом, не припиняючи обробку дзвінків. У цьому посібнику ви вмикаєте щоденне резервне копіювання, розбираєтеся з форматами й налаштовуєте копіювання на віддалений сервер, щоб відновити комутатор навіть у разі втрати його диска. Розраховуйте приблизно на 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 (зберігання даних) того самого екрана.
Системні параметри: усі налаштування середовища.
Вимоги до обладнання: окремі диски, рекомендовані для резервних копій і журналів.