Миграция коробочного Битрикс24 на PHP 8.4 и MySQL 8.4: перенос на современный стек без остановки работы

Переход коробочного Битрикс24 на актуальные версии PHP и MySQL. Разбираем реальный подход к миграции портала с устаревшего стека (CentOS 7, PHP 7.x, MySQL 5.7) на современный (AlmaLinux 9, PHP 8.4, MySQL 8.4) с настройкой Push-сервера и минимальным простоем.

Проблемы, с которыми столкнулись

• Операционная система CentOS 7 не получает обновлений безопасности (EOL с 30.06.2024).
• PHP 7.x и MySQL 5.7 официально не поддерживаются современными версиями Битрикс24, что блокирует обновление портала и создает риски для целостности БД.
• Push-сервер не работал из-за отсутствия валидного SSL-сертификата и устаревших зависимостей Node.js.
• Низкая производительность: старый стек не справлялся с нагрузкой, а диск был переполнен кешем, логами и старыми бэкапами.

План миграции

1. Резервные копии: Полный бекап файлов, БД и конфигураций сервера перед началом любых работ.
2. Подготовка нового окружения: Заказ и настройка сервера на AlmaLinux 9, установка BitrixEnv 9.x, PHP 8.4, MySQL 8.4, Nginx, Redis.
3. Фоновый перенос: Перенос файлов и базы данных на новый сервер через rsync без остановки работы пользователей на старом сервере.
4. Финальная синхронизация: Кратковременная пауза (15–30 минут) для переноса инкрементальных изменений и переключения DNS.
5. Постмиграционная поддержка: Мониторинг, настройка регулярных бэкапов в облако (Selectel), отключение старого сервера через 5–7 дней.

Ход работ

Первый шаг — создание полной резервной копии текущего состояния и аудит узких мест.

Мы выявили, что основной объем занимают файлы в /upload и разросшиеся системные логи.

Развернули новый сервер на AlmaLinux 9.

Настроили сетевой экран (открыты только порты 22, 80, 443), установили свежий BitrixEnv и необходимый стек: PHP 8.4, MySQL 8.4, Nginx и Redis для оптимизации кеширования.

Настройка Push-сервера

Старый Push-сервер не запускался. Мы установили актуальную версию Node.js, корректно настроили RTC/Push-модуль Битрикс24 и выпустили валидный SSL-сертификат Let's Encrypt.

Это критично для работы современных браузеров с WebSocket-соединениями.

Перенос данных

• Выполнили первоначальный rsync файлов сайта и директории /upload в фоновом режиме.
• Сделали дамп базы данных и перенесли его на новый сервер.
• Скорректировали конфигурационные файлы (.settings.php, dbconn.php, виртуальные хосты Nginx) под новые пути и версии ПО.

Финальное переключение

В согласованное время (вне рабочих часов) остановили активность на старом сервере:

1. Сделали финальный инкрементальный дамп БД и rsync файлов.
2. Проверили целостность данных и работу основных функций (CRM, задачи, чаты) через локальную правку /etc/hosts.
3. Переключили A-запись DNS на новый IP-адрес.

Время простоя составило 22 минуты.

Оценка результатов работы

Миграция прошла без потери данных. Пользователи продолжили работу на новом сервере сразу после смены DNS. Старый сервер был сохранен в качестве «страховки» на 7 дней.

Решенные задачи:

• Безопасность: Переход на поддерживаемую ОС AlmaLinux 9 (поддержка до 2032 года) и актуальные версии PHP/MySQL.
• Производительность: Ускорение отклика портала за счет PHP 8.4, современных SSD NVMe и настройки Redis.
• Функциональность: Полностью восстановлена работа Push-уведомлений и чатов благодаря валидному SSL и корректной настройке Node.js.
• Надежность: Настроено автоматическое резервное копирование файлов и БД в облако Selectel.

Выводы

1. Подготовка важнее скорости. Тщательный аудит и фоновый перенос данных позволяют избежать простоя бизнеса.
2. Постепенность и проверка. Использование /etc/hosts для тестирования нового сервера перед переключением DNS страхует от критических ошибок.
3. Комплексный подход. Миграция — это не просто «скопировать файлы». Это обновление всего стека, включая SSL, Push-сервер и систему бэкапов, что дает долгосрочную стабильность.