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 и разбор логов при диагностике сбоев.