Резервное копирование Битрикс24: схемы, частота и восстановление портала

Резервное копирование Битрикс24 - обязательная часть администрирования коробочной версии и осознанного управления облачным порталом. Потеря базы данных или повреждение файлов сайта без актуального бэкапа означает дни простоя и невосстановимую потерю истории сделок и документов.

Облако vs коробка: в чём принципиальная разница

Подход к резервному копированию кардинально отличается в зависимости от того, на какой версии работает портал.

Облачный Битрикс24

Вендор хранит данные на своих серверах и самостоятельно выполняет резервное копирование инфраструктуры. Администратор портала не имеет прямого доступа к файловой системе и базе данных. Тем не менее облако не снимает с компании ответственность за сохранность данных:

• Историю сделок, контактов и документов можно выгрузить вручную через стандартный экспорт CRM в CSV/Excel.
• Файлы с Диска Битрикс24 выгружаются через штатный интерфейс или REST API.
• Настройки воронок, роботов, полей - не экспортируются автоматически; их восстановление при потере потребует ручной перенастройки.

Коробочный Битрикс24

Здесь вся ответственность за бэкап лежит на администраторе сервера. Резервная копия должна покрывать два компонента:

По нашему опыту, именно отсутствие настроенных бэкапов обнаруживается при первичном аудите коробочных порталов - наряду с устаревшим веб-окружением и ошибками структуры базы данных.

Если вы ещё не проходили аудит своего портала, полезно понять сколько часов реально занимает аудит Битрикс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на новом сервере]

Рекомендуемая частота резервного копирования:

Копии на том же физическом сервере, где работает Битрикс24, не являются полноценной защитой - при выходе диска из строя теряются одновременно и данные, и бэкапы. Внешнее хранилище обязательно.

Встроенные инструменты бэкапа Битрикс24

В коробочной версии предусмотрен штатный модуль резервного копирования, доступный из административной панели (Настройки → Инструменты → Резервное копирование). Он позволяет:

• создавать полную архивную копию портала (файлы + база);
• настраивать автоматическое расписание;
• скачивать архив или отправлять его на внешний FTP/SFTP.

Ограничения штатного модуля:

• При больших базах (от 10-20 ГБ) процесс может занимать значительное время и нагружать сервер в рабочие часы.
• Архив хранится на том же диске - нужна дополнительная настройка выгрузки во внешнее хранилище.
• Не заменяет снимки виртуальной машины перед серьёзными обновлениями.

При первоначальном развёртывании коробки в типовом проекте настройка бэкапов включается как обязательный пункт - наравне с установкой SSL, настройкой почты и конфигурацией Push & Pull.

Бэкап перед обновлениями и миграцией

Резервная копия перед обновлением ядра или миграцией на новый сервер - не опция, а обязательное условие. По нашей практике, схема работ при переезде коробки выглядит так:

1. Создание бэкапа существующего портала (БД + файлы).
2. Подготовка нового сервера (разворот веб-окружения, настройка).
3. Перенос данных на новый сервер.
4. Создание бэкапа уже нового портала после переноса - до открытия пользователям.
5. Тестирование работы интеграций и функционала.
6. Переключение DNS и открытие доступа.

Гарантийная поддержка после такой миграции обычно длится около недели - в течение этого времени старый сервер остаётся доступным как резервный вариант отката.

Если у вас настроена интеграция Битрикс24 и 1С, перед обновлением особенно важно убедиться, что бэкап сделан: несовместимость версий модуля обмена с 1С после обновления - одна из наиболее частых причин обращений в техподдержку.

Среда для разработки как элемент стратегии бэкапа

Один из проверенных подходов - развернуть вторую копию Битрикс24 в режиме «для разработки» на отдельной виртуальной машине. Это решает сразу несколько задач:

• Тестирование обновлений и доработок перед применением на боевом портале.
• Возможность быстро проверить, как поведёт себя портал после изменений.
• Наличие актуальной копии данных в случае экстренного восстановления.

Для развёртывания такой среды потребуется:

• Отдельная виртуальная машина (или полная копия существующей ВМ - предпочтительный вариант).
• SSH-доступ к новому серверу.
• Новое доменное имя (поддомен), настроенное в DNS.
• Доступ к реверс-прокси (nginx) для маршрутизации.

Работы по разворачиванию dev-среды на основе копии ВМ занимают, по нашему опыту, около 11 часов (без учёта интеграции с Active Directory).

Восстановление портала: пошаговый алгоритм

Сценарий 1: восстановление на том же сервере

Применяется, если проблема - повреждение данных или ошибочные изменения настроек.

1. Остановить веб-сервер или перевести портал в режим обслуживания.
2. Восстановить базу данных из дампа: mysql -u bitrix0 -p sitemanager < backup.sql.
3. Распаковать архив файлов поверх текущей директории.
4. Проверить права доступа к файлам (chown -R bitrix:bitrix /home/bitrix/www).
5. Запустить веб-сервер, проверить работу портала.
6. Запустить встроенный тест системы в административной панели - убедиться в отсутствии ошибок структуры базы данных.

Сценарий 2: восстановление на новый сервер

Применяется при выходе сервера из строя или плановой миграции.

1. Развернуть веб-окружение Битрикс24 на новом сервере (рекомендуется использовать готовую виртуальную машину от разработчика).
2. Восстановить базу данных из резервной копии.
3. Перенести файлы с бэкапа.
4. Восстановить конфигурацию (/etc/nginx, php.ini, SMTP-настройки).
5. Обновить DNS-запись на новый IP-адрес сервера.
6. Проверить работу всех интеграций (телефония, 1С, сайт).
7. После стабилизации - настроить автоматические бэкапы на новом сервере.

После восстановления обязательно проверьте состояние безопасности: структуру базы данных, уровень проактивной защиты, наличие HSTS-заголовков и корректность редиректа HTTP → HTTPS.

Безопасность резервных копий

Резервная копия содержит всю базу данных портала, включая пароли (хэши), данные клиентов и переписки. Требования к её хранению:

• Шифрование архивов - особенно при хранении во внешних облачных хранилищах.
• Ограничение доступа - к директории с бэкапами должны иметь доступ только уполномоченные администраторы.
• Ротация копий - не хранить бэкапы бесконечно; типовая схема: 7 ежедневных + 4 еженедельных + 3 ежемесячных.
• Проверка восстановления - не реже раза в квартал выполнять тестовое восстановление, чтобы убедиться в целостности архивов.

Игнорирование безопасности бэкапов - одна из критичных уязвимостей, которую мы выявляем при аудите коробочных порталов наряду с устаревшим веб-окружением и отключённой двухэтапной авторизацией.

Если вам нужна регулярная проверка состояния портала и своевременное реагирование на проблемы с бэкапами, стоит рассмотреть техническую поддержку Битрикс24 - в рамках пакетов часов администраторы отслеживают работу резервного копирования в том числе.

Частые вопросы