ISPmanager 6 має вбудований модуль резервного копіювання: розклад, локальне або віддалене сховище, відновлення з веб-інтерфейсу та через CLI. Розділ збирає робочу конфігурацію для VPS і виділених серверів на панелі — від первинного налаштування розкладу до розбору реальних помилок підключення до віддаленого сховища та перевірки, що бекап дійсно придатний для відновлення.

Налаштування бекапів в ISPmanager 6

Розділ розташований у Налаштування → Резервні копії. Тут задається розклад, тип сховища та перелік даних для копіювання. Розклад працює через системний планувальник — завдання додається до crontab користувача root, тому час бекапу не залежить від того, чи відкрита в цей момент панель у браузері.

Параметр	Рекомендація
Тип сховища	FTP або S3-сумісне
Розклад	Щодня о 3:00
Зберігати копій	7 (тиждень)
Увімкнути компресію	Так (gzip)

Що потрапляє до резервної копії

Файли сайтів з директорій користувачів
Дампи баз даних MySQL/PostgreSQL
Поштові скриньки та їхній вміст
Конфігурація самої панелі: перелік користувачів, доменів, правил

Підключення S3-сховища

Віддалене сховище захищає від втрати даних при апаратному збої сервера: копія фізично лежить в іншому дата-центрі. Для S3-сумісного сховища підходить будь-який провайдер, що підтримує стандартний S3 API — не лише Amazon, а й сторонні об'єктні сховища, якщо в них є endpoint, ключі доступу та bucket.

# Налаштування → Резервні копії → Додати сховище
Тип: S3
Endpoint: https://s3.yourstorage.com
Access Key: YOUR_KEY
Secret Key: YOUR_SECRET
Bucket: mybackups

Розрахунок обсягу сховища для бекапів

Перед вибором тарифу сховища оцініть реальний обсяг, який займуть копії з урахуванням ротації. Формула проста: розмір однієї повної копії помножити на кількість збережених копій, плюс запас 15–20% на зростання даних між бекапами.

Компонент	Типовий розмір	Приклад для сайту на 3 ГБ
Файли сайту	Залежить від медіатеки та аплоадів	2,5 ГБ
Дамп бази даних (стиснений)	10–20% від розміру БД на диску	0,4 ГБ
Поштові скриньки	Залежить від історії листування	0,1 ГБ

# Оцінити поточний розмір даних користувача перед налаштуванням сховища
du -sh /var/www/user1/data/

Відновлення через CLI

# Перегляд списку бекапів
ls /var/mgr5/backup/

# Відновлення сайту
ispmanager backup.restore --name mysite_20240101.tar.gz

Типові помилки під час бекапу та відновлення

Повідомлення	Що означає
`Error: no space left on device`	На розділі з бекапами скінчилося місце — найчастіше при локальному зберіганні на тому ж диску, де лежать сайти
`Connection timed out` під час підключення до S3	Endpoint недоступний або вихідний порт 443 закритий файрволом сервера
`Access Denied`	Невірний Access Key або Secret Key, або в ключа немає прав на запис у bucket
`backup.restore: archive not found`	Вказано невірне ім'я архіву, або файл вже видалено після завершення строку зберігання

Інкрементальні та повні бекапи: порівняння

Критерій	Повний бекап	Інкрементальний
Місце на диску	Більше — копіюються всі дані повністю	Менше — лише зміни з попередньої копії
Швидкість створення	Повільніше при великому обсязі даних	Швидше після першої повної копії
Швидкість відновлення	Швидка — потрібен один архів	Повільніше — потрібен ланцюжок архівів
Доступність в ISPmanager	Штатна функція панелі	Потребує окремий модуль BackupManager

Коли вбудованого бекапу не вистачає

Потрібна гранулярність на рівні одного файлу без розгортання всього архіву цілком — таке вміє лише BackupManager або ручний скрипт на rsync з версіюванням через жорсткі посилання
Копії потрібно зберігати довше 30 днів з дедуплікацією — обсяг на звичайному FTP без дедуплікації швидко стане дорогим і повільним для передавання
База даних більша за 20 ГБ, і дамп mysqldump триває годинами, блокуючи таблиці, — варто розглянути бінарну реплікацію або mysqldump --single-transaction окремо від штатного розкладу
Потрібна копія в реальному часі з мінімальним RPO (Recovery Point Objective) — розклад з інтервалом раз на добу такого не дає, тут потрібна реплікація, а не бекап

Перевірка результату відновлення

Після відновлення переконайтеся, що сайт і база даних дійсно працюють, а не лише що архів розпакувався без помилок. Формальна ознака «Restore completed» у журналі панелі не гарантує, що застосунок підніметься — якщо відновлювався неповний набір таблиць або застарілий дамп, сайт може відкриватися з помилками вже на рівні PHP.

# Перевірити дату останньої зміни файлів сайту
stat /var/www/user1/data/www/example.com/www/index.php

# Перевірити, що таблиці БД на місці та містять дані
mysql -u user1 -p -e "SHOW TABLES; SELECT COUNT(*) FROM wp_posts;" mydb

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