Резервное копирование Битрикс24 — обязательная часть администрирования коробочной версии и осознанного управления облачным порталом. Потеря базы данных или повреждение файлов сайта без актуального бэкапа означает дни простоя и невосстановимую потерю истории сделок и документов.
Облако vs коробка: в чём принципиальная разница
Подход к резервному копированию кардинально отличается в зависимости от того, на какой версии работает портал.
Облачный Битрикс24
Вендор хранит данные на своих серверах и самостоятельно выполняет резервное копирование инфраструктуры. Администратор портала не имеет прямого доступа к файловой системе и базе данных. Тем не менее облако не снимает с компании ответственность за сохранность данных:
- Историю сделок, контактов и документов можно выгрузить вручную через стандартный экспорт CRM в CSV/Excel.
- Файлы с Диска Битрикс24 выгружаются через штатный интерфейс или REST API.
- Настройки воронок, роботов, полей — не экспортируются автоматически; их восстановление при потере потребует ручной перенастройки.
Коробочный Битрикс24
Здесь вся ответственность за бэкап лежит на администраторе сервера. Резервная копия должна покрывать два компонента:
| Компонент | Что входит | Критичность |
|---|---|---|
| База данных (MySQL/Percona) | Все сущности CRM, задачи, чаты, настройки | Критично |
| Файловая система | Загруженные файлы, шаблоны, кастомные компоненты | Высокая |
По нашему опыту, именно отсутствие настроенных бэкапов обнаруживается при первичном аудите коробочных порталов — наряду с устаревшим веб-окружением и ошибками структуры базы данных.
Если вы ещё не проходили аудит своего портала, полезно понять сколько часов реально занимает аудит Битрикс24 — это поможет оценить объём работ.
Что резервируется в коробочной версии
База данных
База данных — ключевой объект резервирования. По данным из наших аудитов, размер базы среднего портала составляет порядка 20–30 ГБ (например, в одном из проверенных порталов база занимала ~28 ГБ при 47 ГБ ОЗУ на сервере). При большой активности в CRM, чатах и на диске размер растёт быстрее.
Стандартная СУБД для коробки — MySQL или Percona Server. Резервная копия базы делается одним из способов:
mysqldump— полный дамп, удобен для небольших баз;- Percona XtraBackup — горячее копирование без остановки сервиса, предпочтительно для баз от 10 ГБ;
- снимок (snapshot) виртуальной машины — самый быстрый способ, если инфраструктура позволяет.
Файловая система
Резервируется директория веб-приложения (как правило /home/bitrix/www). Особое внимание стоит уделить:
- загруженным пользователями файлам (
/upload); - кастомным компонентам и шаблонам (
/local,/bitrix/components); - конфигурационным файлам (
.settings.php,dbconn.php, конфигурация SMTP).
Изменённых файлов в среднем портале единицы (по данным аудита — из 109 000+ проверенных файлов модифицированы только 23, т.е. ~0,02%). Тем не менее именно их потеря после сбоя может привести к неработоспособности кастомных доработок.
Конфигурация веб-окружения
Дополнительно рекомендуется сохранять конфигурации nginx, Apache и PHP — это ускорит восстановление на новом сервере. При переходе с облачного Битрикс24 на коробку или миграции между серверами конфигурационные файлы веб-окружения часто оказываются первым, что приходится восстанавливать вручную.
Схема резервного копирования для коробки
На схеме показано, как организован типовой процесс резервного копирования коробочного Битрикс24: данные с сервера портала попадают в локальное хранилище и параллельно — во внешнее (облачное или удалённое) хранилище, откуда при необходимости производится восстановление.
flowchart LR
B24[Коробочный Битрикс24\nфайлы + БД] --> LOCAL[Локальный бэкап\nна том же сервере]
B24 --> REMOTE[Внешнее хранилище\nS3 / NFS / другой сервер]
LOCAL -->|Ротация| ARCHIVE[Архив копий\n7-30 дней]
REMOTE -->|Ротация| ARCHIVE
ARCHIVE -->|Восстановление| RESTORE[Развёртывание\nна новом сервере]
Рекомендуемая частота резервного копирования:
| Тип копии | Частота | Хранение |
|---|---|---|
| Полная (БД + файлы) | Ежедневно, в нерабочее время | 7–14 копий |
| Только БД | Каждые 4–6 часов | 2–3 дня |
| Снимок виртуальной машины | Перед обновлениями / миграциями | 2–3 последних |
Копии на том же физическом сервере, где работает Битрикс24, не являются полноценной защитой — при выходе диска из строя теряются одновременно и данные, и бэкапы. Внешнее хранилище обязательно.
Встроенные инструменты бэкапа Битрикс24
В коробочной версии предусмотрен штатный модуль резервного копирования, доступный из административной панели (Настройки → Инструменты → Резервное копирование). Он позволяет:
- создавать полную архивную копию портала (файлы + база);
- настраивать автоматическое расписание;
- скачивать архив или отправлять его на внешний FTP/SFTP.
Ограничения штатного модуля:
- При больших базах (от 10–20 ГБ) процесс может занимать значительное время и нагружать сервер в рабочие часы.
- Архив хранится на том же диске — нужна дополнительная настройка выгрузки во внешнее хранилище.
- Не заменяет снимки виртуальной машины перед серьёзными обновлениями.
При первоначальном развёртывании коробки в типовом проекте настройка бэкапов включается как обязательный пункт — наравне с установкой SSL, настройкой почты и конфигурацией Push & Pull.
Бэкап перед обновлениями и миграцией
Резервная копия перед обновлением ядра или миграцией на новый сервер — не опция, а обязательное условие. По нашей практике, схема работ при переезде коробки выглядит так:
- Создание бэкапа существующего портала (БД + файлы).
- Подготовка нового сервера (разворот веб-окружения, настройка).
- Перенос данных на новый сервер.
- Создание бэкапа уже нового портала после переноса — до открытия пользователям.
- Тестирование работы интеграций и функционала.
- Переключение DNS и открытие доступа.
Гарантийная поддержка после такой миграции обычно длится около недели — в течение этого времени старый сервер остаётся доступным как резервный вариант отката.
Если у вас настроена интеграция Битрикс24 и 1С, перед обновлением особенно важно убедиться, что бэкап сделан: несовместимость версий модуля обмена с 1С после обновления — одна из наиболее частых причин обращений в техподдержку.
Среда для разработки как элемент стратегии бэкапа
Один из проверенных подходов — развернуть вторую копию Битрикс24 в режиме «для разработки» на отдельной виртуальной машине. Это решает сразу несколько задач:
- Тестирование обновлений и доработок перед применением на боевом портале.
- Возможность быстро проверить, как поведёт себя портал после изменений.
- Наличие актуальной копии данных в случае экстренного восстановления.
Для развёртывания такой среды потребуется:
- Отдельная виртуальная машина (или полная копия существующей ВМ — предпочтительный вариант).
- SSH-доступ к новому серверу.
- Новое доменное имя (поддомен), настроенное в DNS.
- Доступ к реверс-прокси (nginx) для маршрутизации.
Работы по разворачиванию dev-среды на основе копии ВМ занимают, по нашему опыту, около 11 часов (без учёта интеграции с Active Directory).
Восстановление портала: пошаговый алгоритм
Сценарий 1: восстановление на том же сервере
Применяется, если проблема — повреждение данных или ошибочные изменения настроек.
- Остановить веб-сервер или перевести портал в режим обслуживания.
- Восстановить базу данных из дампа:
mysql -u bitrix0 -p sitemanager < backup.sql. - Распаковать архив файлов поверх текущей директории.
- Проверить права доступа к файлам (
chown -R bitrix:bitrix /home/bitrix/www). - Запустить веб-сервер, проверить работу портала.
- Запустить встроенный тест системы в административной панели — убедиться в отсутствии ошибок структуры базы данных.
Сценарий 2: восстановление на новый сервер
Применяется при выходе сервера из строя или плановой миграции.
- Развернуть веб-окружение Битрикс24 на новом сервере (рекомендуется использовать готовую виртуальную машину от разработчика).
- Восстановить базу данных из резервной копии.
- Перенести файлы с бэкапа.
- Восстановить конфигурацию (
/etc/nginx,php.ini, SMTP-настройки). - Обновить DNS-запись на новый IP-адрес сервера.
- Проверить работу всех интеграций (телефония, 1С, сайт).
- После стабилизации — настроить автоматические бэкапы на новом сервере.
После восстановления обязательно проверьте состояние безопасности: структуру базы данных, уровень проактивной защиты, наличие HSTS-заголовков и корректность редиректа HTTP → HTTPS.
Безопасность резервных копий
Резервная копия содержит всю базу данных портала, включая пароли (хэши), данные клиентов и переписки. Требования к её хранению:
- Шифрование архивов — особенно при хранении во внешних облачных хранилищах.
- Ограничение доступа — к директории с бэкапами должны иметь доступ только уполномоченные администраторы.
- Ротация копий — не хранить бэкапы бесконечно; типовая схема: 7 ежедневных + 4 еженедельных + 3 ежемесячных.
- Проверка восстановления — не реже раза в квартал выполнять тестовое восстановление, чтобы убедиться в целостности архивов.
Игнорирование безопасности бэкапов — одна из критичных уязвимостей, которую мы выявляем при аудите коробочных порталов наряду с устаревшим веб-окружением и отключённой двухэтапной авторизацией.
Если вам нужна регулярная проверка состояния портала и своевременное реагирование на проблемы с бэкапами, стоит рассмотреть техническую поддержку Битрикс24 — в рамках пакетов часов администраторы отслеживают работу резервного копирования в том числе.