Перенос коробки Битрикс24 на новый сервер: бэкап, PHP, домен и SSL

Эта статья - про перенос уже работающей коробки Битрикс24 с одного сервера на другой (box → box). Если вы переходите с облачного Битрикс24 на коробочный впервые - это другая задача, подробно описанная в статье «Переход с облачного Битрикс24 на коробку».

Когда нужен перенос сервера

Типовые причины, по которым компании переезжают на новый сервер:

• Конец жизни ОС. CentOS 7 достиг EOL - система больше не получает обновления безопасности. Стандартный результат переноса в нашей практике: старый сервер выводится из эксплуатации, на новом с CentOS Stream 9 (или другой актуальной ОС) стоит Битрикс24 в рабочем состоянии - тот же домен, те же пользователи, тот же функционал.
• Рост нагрузки. Портал вырос, текущего железа не хватает - нужна машина мощнее или кластерная конфигурация.
• Смена хостинг-провайдера. Переезд на другую площадку по соображениям надёжности, цены или требований регулятора (152-ФЗ).
• Консолидация инфраструктуры. Несколько серверов объединяются на новой платформе.

Важно понимать: перенос сервера и обновление коробочной версии Битрикс24 - разные операции. Их можно совместить, но только при правильной последовательности.

Подготовка к переносу

Экономить время на подготовке - значит создавать себе проблемы на этапе восстановления. Выполните аудит до старта:

Аудит текущего портала

• Размер данных: объём файлов в /home/bitrix/www (или нестандартный путь), размер базы данных. Это определяет выбор способа переноса.
• Доработки в /local: кастомные модули, компоненты, шаблоны - всё, что разработчики писали отдельно от ядра.
• Cron-задачи: crontab -l для пользователя bitrix и root. Их нужно перенести вручную.
• Сторонние модули из Маркетплейса: проверьте, поддерживают ли они целевую версию PHP. Разработчики сторонних модулей могут отставать от обновлений платформы.
• Текущие версии PHP и MySQL/MariaDB на старом сервере - зафиксируйте их, чтобы понять масштаб апгрейда.
• Версия платформы Битрикс24 - она должна быть актуальной до переезда (см. ниже).

Тестовый контур - обязательно

До боевого переезда поднимите тестовый контур на новом сервере и восстановите туда копию портала. На тесте:

1. Проверьте все критичные сценарии: вход, сделки, задачи, интеграции.
2. Проверьте доработки из /local - они могут сломаться при смене версии PHP.
3. Прогоните тест структуры БД (Настройки → Инструменты → Проверка таблиц).

Не переносите боевой портал, не убедившись, что тест работает корректно.

Два способа переноса данных

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

flowchart TD
    OLD["Старый сервер\nфайлы и БД"] --> WAY1["Способ 1: штатный бэкап"]
    OLD --> WAY2["Способ 2: rsync и mysqldump"]
    WAY1 --> RESTORE["restore.php на новом"]
    WAY2 --> RSYNC[Файлы через rsync]
    WAY2 --> DUMP[Импорт дампа БД]
    RESTORE --> NEW["Новый сервер\nвосстановлен"]
    RSYNC --> NEW
    DUMP --> NEW

Способ 1: штатный бэкап + restore.php

Подходит для небольших порталов (до нескольких десятков гигабайт).

1. В административной панели: Настройки → Инструменты → Резервное копирование → создать полный бэкап.
2. Скачать архив .tar.gz на новый сервер или передать напрямую между серверами.
3. На новом сервере разместить restore.php (скачивается с сайта 1С-Битрикс) в корень сайта.
4. Открыть restore.php в браузере и пройти мастер восстановления - он распакует архив и восстановит базу.
5. После восстановления - удалить restore.php из корня.

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

Способ 2: rsync + mysqldump (для крупных порталов)

Подходит для больших порталов (сотни гигабайт файлов или объёмная база).

Перенос файлов через rsync:

rsync -avz --progress /home/bitrix/www/ user@new-server:/home/bitrix/www/

Можно запустить rsync заранее в режиме синхронизации и повторить перед самым переключением - дельта будет минимальной, простой портала сократится.

Дамп и восстановление базы данных:

# На старом сервере
mysqldump -u root -p --single-transaction --routines --triggers bitrix > bitrix_dump.sql

# Передача на новый сервер
scp bitrix_dump.sql user@new-server:/tmp/

# На новом сервере
mysql -u root -p bitrix < /tmp/bitrix_dump.sql

Плюсы: меньше нагрузки на старый сервер, меньше риск таймаутов, контроль на каждом шаге.
Минусы: требует навыков работы с Linux и MySQL.

Подробнее о регулярных резервных копиях после переноса - в статье «Резервное копирование Битрикс24: схемы, частота и восстановление».

Апгрейд PHP: делать до переезда, поэтапно

Самая частая ошибка - совместить переезд и апгрейд PHP в одном шаге. Если после переноса что-то сломается, вы не будете знать, что причина: переезд или смена PHP.

Правило: обновляйте PHP на тестовом стенде, убедитесь в работоспособности, затем переезжайте.

Требования платформы к PHP

С 01.02.2026 система обновлений Битрикс24 блокирует установку обновлений, если PHP ниже 8.2. Рекомендуемая версия - PHP 8.3 и выше.

Порядок апгрейда PHP

1. Создайте резервную копию портала (и всего сервера, если используете VMBitrix).
2. Обновите ядро и все модули платформы до последних версий: Настройки → Marketplace → Обновление платформы.
3. Обновите сторонние решения из Маркетплейса: Настройки → Marketplace → Обновление решений.
4. Обновите версию PHP на сервере до целевой (8.3+). - Для VMBitrix: меню menu.sh → «1. Manage servers in the pool» → «8. Update PHP and MySQL».
5. Повторно проверьте наличие обновлений платформы и решений - некоторые обновления доступны только после смены версии PHP.

Обновляйте поэтапно: например, 7.4 → 8.0 → 8.1 → 8.2 → 8.3. Не прыгайте через несколько мажорных версий сразу.

Частые проблемы при смене PHP

• mbstring.func_overload=2 - параметр устарел начиная с PHP 7.2, при обновлении нужно удалить его из /etc/php.d/bitrixenv.ini или выставить в 0. Без этого установка обновлений заблокируется.
• Сторонние модули могут не поддерживать новую версию PHP. Обращайтесь к разработчику модуля (контакты - на странице модуля в Маркетплейсе, вкладка «Поддержка»).
• Если после апгрейда появились ошибки - откатитесь на предыдущую версию PHP, обновите компоненты и повторите.
• По стандартным модулям (bitrix.*) ошибки решаются через Поддержку24.

Домен и SSL на новом сервере

После восстановления данных и проверки работы на тестовом контуре - переключайте домен.

Порядок переключения

1. Убедитесь, что портал корректно работает на новом сервере (пусть пока по IP или временному домену).
2. Смените A-запись домена на новый внешний IP-адрес. Учитывайте TTL - изменения могут распространяться от нескольких минут до нескольких часов.
3. Выпустите SSL-сертификат. Стандартный вариант - Let's Encrypt (бесплатный, автопродление). Если у клиента есть коммерческий сертификат - установить его.
4. Настройте редирект HTTP → HTTPS и добавьте HSTS-заголовок. Это же требование проверяет сканер безопасности в модуле «Проактивная защита».
5. Обновите настройки портала - в административной панели укажите правильный URL сайта, если он изменился.
6. Откройте порты на новом сервере: 80 и 443 (обязательны для работы портала), 22 (SSH для администрирования). Если планируются интеграции со сторонними сервисами - внешний доступ к серверу необходим.

При наличии интеграций с 1С, телефонией или сайтами - проверьте все вебхуки и точки входа API после смены домена: они могут ссылаться на старый адрес.

Push-сервер: переустановка после переезда

Push-and-Pull - ключевая служба Битрикс24, обеспечивающая работу чатов, онлайн-уведомлений и синхронизацию. После переезда на новый сервер её нужно перенастроить.

Актуальная версия - Bitrix Push server 2.0 (Node.js). Старые реализации на Nginx-PushStreamModule 0.3.4/0.4.0 и Bitrix Push server 1.0 уже не поддерживаются.

Варианты настройки:

• Облачный сервер очередей 1С-Битрикс - если портал доступен из интернета и нет требований к закрытому контуру, это наиболее простой вариант.
• Локальный Bitrix Push server 2.0 - для закрытых контуров или при требованиях к производительности. В административной панели переключите модуль: «Использовать сервер, установленный локально». Push-сервер (Node.js) проксируется через Nginx по WebSocket.

После настройки Push-сервера проверьте работу чатов и онлайн-статусов в браузере.

После переезда: что настроить и проверить

Переезд завершён - не закрывайте задачу, пока не пройдёт этот чек-лист:

Технические настройки

• Cron-задачи - перенести и проверить (crontab -l для пользователя bitrix). Агенты Битрикс24 должны запускаться по расписанию.
• Структура БД - запустить проверку таблиц: Настройки → Инструменты → Проверка таблиц. Цель: 0 ошибок.
• Настройки СУБД - отключить query_cache и local_infile, увеличить innodb_log_file_size.
• PHP - отключить вывод ошибок в браузер (display_errors = Off, display_startup_errors = Off).
• Почта - проверить отправку системных уведомлений.
• Конфиги для сохранения - /etc/nginx, /etc/httpd, /etc/php.d/*, /etc/php.ini, /etc/mysql/conf.d.

Безопасность

• Проактивная защита - повысить уровень, убедиться, что сканер безопасности не показывает критических уязвимостей.
• HSTS и редирект HTTP → HTTPS - проверить в модуле «Проактивная защита».
• Ограничить доступ к административной панели по IP - пользователи с незарегистрированных IP не должны получать доступ.
• Защита от фреймов - убедиться, что галочка в настройках включена.
• Веб-антивирус - включить в настройках проактивной защиты.

Резервное копирование

Настройте регулярные резервные копии сразу после переезда. Рекомендации по нашему опыту:

• Хранить копии на отдельном сервере, не на том же, где стоит портал.
• Хранить архивы около месяца - глубина позволяет восстановиться при обнаружении проблемы спустя время.
• Сделайте бэкап нового портала сразу после настройки, до передачи пользователям.

Передача и тестирование

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

Типичные ошибки при переносе (ГОЧИ)

Это раздел для тех, кто хочет не наступить на стандартные грабли:

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

Сроки и ресурсы

По нашему опыту переноса коробок, типовая работа по переезду занимает 1-2 рабочих дня (при условии, что клиент предоставил готовый сервер с SSH-доступом к root и все данные для доступов к старому серверу). Если в рамках переноса выполняются дополнительные работы по донастройке - исправление структуры БД, настройка безопасности, обновление окружения - срок увеличивается до недели.

Типовые требования к новому серверу: диск от 80 ГБ, оперативная память от 8 ГБ (для среднего портала). Для высоконагруженных инсталляций - отдельный расчёт.

Если вы хотите передать перенос под ключ - напишите на sales@acp-24.ru с описанием текущего и целевого окружения.

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