ISPmanager 6 має вбудовану систему резервного копіювання. Можна налаштувати щоденні автоматичні бекапи сайтів, баз даних і пошти зі зберіганням на локальному диску, FTP або S3.

Налаштування розкладу бекапів

Інструменти → Резервне копіювання → Розклад → Створити.

Параметр	Опис
Період	Щодня / Щотижня / Щомісяця
Час	Рекомендується 02:00–04:00 ночі
Що включити	Файли, БД, пошта, конфіги
Зберігати копій	7 (тиждень) або 14 (два тижні)

Час бекапу варто обирати за мінімальним навантаженням сайту, а не довільно: якщо нічний трафік все одно суттєвий (наприклад, аудиторія в інших часових поясах), повне копіювання великих баз може помітно сповільнити сайт саме в це вікно.

Що не входить до бекапу за замовчуванням

Системні налаштування самої ОС поза директоріями сайтів (наприклад, кастомні конфіги Nginx, відредаговані вручну повз панель)
Cron-завдання, додані напряму через crontab -e в обхід інтерфейсу ISPmanager
Дані сторонніх сервісів, запущених окремо від панелі (Docker-контейнери, окремі бази поза MySQL/PostgreSQL панелі)

Налаштування віддаленого сховища

FTP-сервер

Інструменти → Сховища → Додати → FTP. Вкажіть IP/хост, логін, пароль і папку.

Amazon S3 / Сумісне сховище

Інструменти → Сховища → Додати → S3. Вкажіть endpoint, access key, secret key і bucket.

✅ Зберігайте бекапи на окремому сервері або S3. Бекап на тому ж диску не захистить від збою HDD чи злому.

Ручне створення бекапу

Інструменти → Резервне копіювання → Створити. Оберіть користувачів і дані для бекапу.

Відновлення з бекапу

Інструменти → Резервне копіювання → оберіть архів → Відновити.

Відновити все — повне відновлення
Вибірково — обрати конкретні файли або БД

⚠️ При відновленні з бекапу поточні дані буде перезаписано. Якщо потрібно зберегти поточний стан, спочатку зробіть бекап вручну.

Перевірка бекапів

Регулярно перевіряйте працездатність бекапів — запускайте тестове відновлення раз на місяць. Бекап, який неможливо відновити, не є бекапом.

Розбір типових помилок резервного копіювання

Повідомлення / симптом	Що означає
Завдання бекапу висить у статусі «Виконується» годинами	Зазвичай означає проблему з мережею до віддаленого сховища або блокування файлу базою даних під час дампу
`mysqldump: Got error: 1044: Access denied`	У користувача MySQL, від імені якого працює бекап, недостатньо прав на конкретну базу
Розмір архіву бекапу зростає щоразу на десятки відсотків	До бекапу випадково потрапляють тимчасові файли або логи, що ростуть без ротації — варто виключити їх зі списку директорій, що копіюються
Сповіщення про бекап надходить, але самого архіву немає у сховищі	Сповіщення надсилається за фактом завершення завдання, а не за фактом успішного запису у сховище — варто перевіряти обидві події окремо

Локальне, FTP і S3 сховище: порівняння

Критерій	Локальний диск	FTP	S3-сумісне
Захист від відмови сервера	Немає	Так	Так
Швидкість запису	Висока	Залежить від каналу	Залежить від каналу і регіону
Вартість	Включена в тариф VPS	Зазвичай нижча за S3	Оплата за обсяг і запити
Зручність ротації версій	Ручна	Ручна або за розкладом панелі	Часто є вбудоване версіювання бакета

Коли вбудованого розкладу недостатньо

Потрібен бекап перед кожним релізом, а не за фіксованим розкладом — для цього зручніше вбудувати ручний запуск бекапу в CI/CD пайплайн через API, а не покладатися лише на панель
Потрібне зберігання в кількох географічно рознесених сховищах одночасно (стратегія 3-2-1) — штатний розклад ISPmanager налаштовується на одне сховище за завданням, для кількох копій потрібно створювати окремі завдання або скрипт поверх API
Обсяг даних настільки великий, що повний бекап не вкладається у нічне вікно — потрібна інкрементальна схема або реплікація замість періодичних знімків

Перевірка результату

Формальне завершення завдання бекапу без помилок — не доказ, що дані відновлювані. Раз на місяць виконуйте тестове відновлення на окремому тестовому сервері або контейнері.

# Перевірити список доступних архівів та їх розмір
ls -lh /var/mgr5/backup/

# Розгорнути архів у тимчасову директорію для перевірки вмісту
tar -tzf mysite_20240101.tar.gz | head -20

Якщо архів відкривається, але всередині немає очікуваних файлів або дамп бази даних порожній — завдання бекапу завершувалося «успішно» лише формально, а реальні дані не потрапляли до копії. Таку перевірку варто автоматизувати окремим скриптом, а не покладатися на пам'ять. Пов'язані теми: налаштування резервного копіювання та відновлення та робота з базами даних в ISPmanager 6.