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.