С CentOS 7 на EL9: пошаговый переезд с BitrixVM 7 на BitrixVM 9

CentOS 7 не получает обновлений с 30 июня 2024 года, и Remi больше не собирает под неё PHP. Когда 21 октября вышли исправления критических уязвимостей PHP, на серверах с EL9 их поставила одна команда dnf upgrade, а на CentOS 7 PHP пришлось собирать из исходников. Как это делается, рассказывал в статье об уязвимостях PHP от 21 октября. С каждым следующим патчем такая сборка будет даваться тяжелее, поэтому свои серверы с CentOS 7 мы перевезли. Инструкция ниже собрана по этому переезду.

Обновить систему на месте не получится: установщик BitrixVM 9 (он же BitrixEnv 9) ставится только на чистую систему версии 9. Поэтому новый сервер ставится рядом, а старый работает до переключения DNS, и вернуться на него можно в любой момент.

Перенос баз с MySQL 5.7 или 8.0 на 8.4 описан в шаге 5. Подробный разбор того, что ломается в базе при переходе на 8.4, выйдет отдельной статьёй.

Какую ОС поставить на новый сервер

Установщик BitrixVM 9 проверяет систему и принимает только четыре: CentOS Stream, Rocky Linux, AlmaLinux и Oracle Linux, все версии 9. На RHEL и на десятых версиях он останавливается, а отдельного установщика под EL10 у Битрикса пока нет. Выбирать приходится из девятых версий, и главное различие между ними — сколько система будет получать обновления:

Ставьте Rocky Linux 9 или AlmaLinux 9. Обе получают исправления безопасности до 31 мая 2032 года, и для BitrixVM между ними нет разницы: берите ту, для которой у вашего хостинга есть готовый образ. Команды из этой статьи проверены на CentOS Stream 9 и на Rocky Linux 9.

CentOS Stream 9 на новый сервер я бы не ставил: до конца её поддержки остаётся около семи месяцев, а потом сервер снова окажется в положении CentOS 7, без исправлений. Oracle Linux 9 работает, но своё ядро и свои репозитории — лишние отличия от трёх других систем, а выигрыша для сайта на Битриксе они не дают.

Что понадобится

• Старый сервер с CentOS 7 и BitrixVM 7, доступ по SSH под root.
• Новый сервер с чистой Rocky Linux 9 или AlmaLinux 9, доступ под root или под пользователем с sudo. Сколько места нужно на диске, станет понятно в шаге 0.
• Доступ к DNS-записям доменов.

Копирование файлов и баз занимает меньше всего времени. Дольше всего искать то, что на старом сервере когда-то настроили руками: меню BitrixVM 9 об этом не знает и предупредить не может. Если в проекте есть свой Node, проксирование в .htaccess или свои модули Apache, закладывайте на перенос рабочий день, а не час, и не переезжайте в день релиза.

В примерах старый сервер — 203.0.113.10, новый — 203.0.113.20, на новый заходим пользователем user1 с sudo, сайт — corp.example.ru. Подставьте свои.

Шаг 0. Опись старого сервера

Всё, что настроили руками мимо меню BitrixVM, на новый сервер само не переедет. Пройдите по старому серверу и запишите в файл то, что найдёте: в шаге 6 вы пойдёте по этому списку.

Сайты и базы. Список сайтов с папками и базами есть в меню старого сервера, пункт Configure pool sites. Основной сайт BitrixVM лежит в /home/bitrix/www, дополнительные — в /home/bitrix/ext_www/<домен>. Имя базы и пользователя каждого сайта записаны в bitrix/.settings.php, в блоке connections → default, строки database и login. Откройте файл через SFTP.

Там же откройте bitrix/php_interface/dbconn.php и найдите строку define("BX_CRONTAB_SUPPORT", true);. Если она есть и не закомментирована, агенты сайта выполняются по cron, и в шаге 3 на вопрос про cron нужно ответить y.

Домены. У каждого дополнительного сайта есть конфиг nginx /etc/nginx/bx/site_enabled/bx_ext_<домен>.conf и конфиг Apache /etc/httpd/bx/conf/bx_ext_<домен>.conf. Откройте их и выпишите строки server_name и ServerAlias. Меню BitrixVM 9 само пропишет только <домен> и www.<домен>. Остальные имена, например региональные поддомены, кто-то вписал руками, и на новом сервере их тоже придётся вписать руками. Основному сайту это не нужно: он отвечает на любое имя, которое не занято другим сайтом.

Место на диске. Посмотрите, сколько занимают файлы:

        du -sh /home/bitrix

    

Теперь то же самое, но с подсчётом каждой жёсткой ссылки отдельно:

        du -shl /home/bitrix

    

Если вторая цифра заметно больше первой, на сервере есть жёсткие ссылки: один и тот же файл лежит в нескольких папках, а место на диске занимает один раз. Так бывает, когда сайты делят общие файлы upload. В шаге 4 их сохранит ключ -H, и новому серверу хватит места по первой цифре. Ещё нужно место под базы и их дампы: размер баз покажет du -sh /var/lib/mysql. Свободное место на новом диске должно быть больше суммы с запасом.

Расширения PHP. Сохраните список расширений старого сервера в файл, в шаге 6 его нужно будет сравнить с новым:

        mkdir -p /root/mig
php -m > /root/mig/php-modules-old.txt

    

Модули Apache. Откройте папку /etc/httpd/conf.modules.d/. В BitrixVM 7 там лежат 00-base.conf, 00-dav.conf, 00-lua.conf, 00-mpm.conf, 00-proxy.conf, 00-ssl.conf, 00-systemd.conf, 01-cgi.conf, 10-geoip.conf, 20-php.conf и их копии с .disabled. Любой другой файл добавили руками. Откройте его и выпишите, какие модули он загружает. Чаще всего это mod_proxy, без которого не работают правила .htaccess с флагом [P].

Программы кроме BitrixVM. Посмотрите, что слушает порты:

        ss -ltnp

    

sshd, nginx, httpd, mysqld, rpcbind, stunnel и то, что вы включали в меню (memcached, Sphinx, push-сервер), ставит BitrixVM. Всё остальное поставили руками: Node-фронтенд, Redis, Elasticsearch. Каждую такую программу на новом сервере придётся поставить заново.

Остальное:

• задания cron: crontab -l -u bitrix и crontab -l под root;
• пароли на сайт (basic auth): строка AuthUserFile в .htaccess показывает путь к файлу паролей. Если файл лежит вне папки сайта, его нужно скопировать отдельно;
• почта: если отправку писем настраивали в меню, пункт Configure pool sites → Change a site's email settings, запишите сервер, порт и логин. Пароль тоже понадобится;
• сертификаты переносить не нужно, после переключения DNS выпустите новые через меню.

Шаг 1. Установка BitrixVM 9

Обновляем систему и скачиваем установщик:

        dnf clean all
dnf -y update
curl -O http://repo.bitrix24.tech/dnf/bitrix-env-9.sh

    

Установщику нужен пароль root для MySQL. Сгенерируйте его прямо на сервере:

        openssl rand -hex 16

    

Команда напечатает 32 случайных символа. Сохраните их в менеджер паролей и подставьте в команду установки вместо ПАРОЛЬ:

        bash bitrix-env-9.sh -s -p -H bx9 -M 'ПАРОЛЬ' -m 8.4

    

Установщик сам положит пароль в /root/.my.cnf, так что под root mysql будет пускать без пароля. Ключ -m 8.4 ставит Percona Server 8.4 вместо 8.0 по умолчанию. Поддержка 8.0 закончилась в апреле 2026 года, ставить её на новый сервер незачем.

Строка log_to_file: command not found — ошибка в самом установщике 9.0-10, на результат она не влияет. После второго запуска на сервере стоят nginx, Apache с PHP 8.2 (эту версию установщик ставит по умолчанию, что с ней делать — в шаге 2), Percona Server 8.4 и Node 22. Файрвол пропускает только 80, 443, SSH и порты push-сервера. MySQL слушает порт 3306 на всех адресах, но снаружи он закрыт файрволом.

Шаг 2. Версия PHP

PHP 8.2 — версия, которую BitrixVM 9 ставит по умолчанию, и она же минимальная: ниже меню не опускает, только обновляет до 8.3, 8.4 или 8.5. Поддержка 8.2 заканчивается 31 декабря 2026 года, поэтому целиться лучше сразу в 8.4.

Какую версию ставить, зависит от того, на какой версии сайт работает сейчас:

• 8.2, 8.3 или 8.4 — ставьте ту же. Менять PHP одновременно с переездом не стоит: если что-то сломается, будет непонятно, из-за чего. Если это 8.2, после переезда переведите сайт на 8.4 до конца декабря.
• 8.1 или ниже — сначала подготовьте сайт к 8.4 на локальной копии или на dev-сервере Омута, а переезжайте уже на 8.4. Переезжать на 8.2, чтобы через пару месяцев снова менять версию, смысла нет.

Версия меняется в меню: 1. Manage servers in the pool → 6. Update PHP, MySQL, PostgreSQL → имя сервера → нужная версия.

Задача выполняется в фоне. Через пару минут проверьте:

        php -v

    

В первой строке должна быть выбранная версия. Когда перенесёте сайты, то же самое покажет админка: «Настройки → Инструменты → Диагностика → Настройки PHP».

Шаг 3. Сайты создаём через меню

Конфиги nginx и Apache в BitrixVM 7 и 9 разные. Старые конфиги, скопированные на новый сервер, может, и заработают, но меню их не увидит, а следующая же операция через меню их перезапишет. Поэтому сайты создаём заново.

Основной сайт уже есть: BitrixVM при установке создаёт его в /home/bitrix/www вместе с базой sitemanager и пользователем bitrix0. Для него в этом шаге ничего делать не нужно.

Каждый дополнительный сайт создайте в меню: 8. Configure pool sites → 1. Create a site. На вопросы отвечайте так:

• тип сайта kernel: своё ядро и своя база;
• база mysql;
• cron — как на старом сервере, по строке BX_CRONTAB_SUPPORT из шага 0;
• customize → y: корень оставьте по умолчанию, /home/bitrix/ext_www/<домен>, а имя базы и пользователя возьмите из старого .settings.php.

Пароль пользователя базы меню спрашивает дважды. Вводить сюда настоящий пароль из .settings.php не нужно, введите любой новый. При переносе резервной копией он так и останется паролем базы, при переносе rsync скрипт в шаге 5 выставит старый.

Меню создаёт папку-заглушку и пустую базу. В шагах 4 и 5 их заменит перенесённый сайт.

Шаг 4. Файлы

Перенести сайт можно двумя способами:

• резервной копией из админки. Это самый простой способ: файлы и база уезжают одним архивом, в консоли почти ничего набирать не нужно. Подходит, если на старом сервере есть место ещё на одну копию сайта;
• rsync и дампом базы. Это способ для больших сайтов и для случая, когда на старом сервере мало места. Копирует быстрее, сохраняет жёсткие ссылки, а при переключении передаёт только то, что изменилось.

Резервная копия Битрикса не знает о жёстких ссылках: каждая ссылка попадёт в архив отдельным файлом. Если в шаге 0 du -shl показал заметно больше, чем du -sh, берите rsync.

Способ 1. Резервная копия из админки

Копия создаётся и восстанавливается для каждого сайта отдельно. Перед созданием копии проверьте базы на старом сервере скриптом из пункта 1 шага 5.

На старом сервере:

1. Проверьте свободное место командой df -h /home. Архив ляжет в папку сайта bitrix/backup и займёт до размера самого сайта.
2. В админке сайта откройте «Настройки → Инструменты → Резервное копирование → Создание резервной копии», место хранения — «в папке сайта». Нажмите «Создать резервную копию» и не закрывайте вкладку, пока не появится «Создание резервной копии завершено». Папки кэша Битрикс в архив не кладёт.
3. Откройте «Список резервных копий», в меню действий у нового архива выберите «Получить ссылку для переноса» и скопируйте ссылку.

На новом сервере под root:

4. Верните базе сайта кодировку старого сервера, запросом ALTER DATABASE из пункта 4 шага 5. Сделайте это до восстановления: таблицы из архива создадутся в своей кодировке, а всё, что Битрикс создаст потом, получит кодировку базы.
5. Скачайте скрипт восстановления в папку сайта и отдайте его пользователю bitrix:

        cd /home/bitrix/ext_www/corp.example.ru
curl -O https://www.1c-bitrix.ru/download/scripts/restore.php
chown bitrix:bitrix restore.php

    

Для основного сайта папка — /home/bitrix/www. chown нужен потому, что при первом открытии скрипт записывает в себя ваш IP и время. После этого он работает 7 дней и только с этого IP.

6. DNS пока смотрит на старый сервер, поэтому пропишите домен в файле hosts на своём компьютере, как в шаге 7, и откройте https://corp.example.ru/restore.php. Браузер предупредит о самоподписанном сертификате, так и должно быть.
7. Выберите «Скачать резервную копию с другого сайта», вставьте ссылку в поле «Ссылка на архив» и нажмите «Далее». Скрипт скачает все части архива и распакует их.
8. В «Параметрах подключения к базе данных» поля уже заполнены: скрипт взял их из .settings.php папки-заглушки, то есть это база и пользователь, которых меню создало в шаге 3. Ничего не меняйте и нажмите «Восстановить». Предупреждение, что база текущего сайта будет переписана, относится к этой новой пустой базе.
9. В конце выберите «Удалить локальную резервную копию и служебные скрипты».

Если сайт закрыт паролем (basic auth), restore.php не сможет скачать архив по ссылке. Тогда заберите части архива на новый сервер прямо в папку сайта:

        rsync -a --include='*.tar*' --include='*.enc*' --exclude='*' root@203.0.113.10:/home/bitrix/ext_www/corp.example.ru/bitrix/backup/ /home/bitrix/ext_www/corp.example.ru/

    

Как подключиться к старому серверу по SSH, описано в способе 2. В restore.php выберите «Архив загружен в корневую папку сервера», дальше всё так же.

После восстановления переходите к шагу 5: из него остаются пункты 6 и 7.

Способ 2. rsync и дамп базы

Копировать файлы через свой компьютер медленно: они пойдут со старого сервера к вам и от вас на новый. Быстрее забрать их напрямую: зайти на новый сервер и скачать файлы со старого. Новый сервер подключается к старому по SSH под root или bitrix, с паролем или по ключу.

Все команды этого шага выполняются на новом сервере под root. Если вы заходите на него пользователем bitrix, станьте root командой su и паролем root: прав на sudo у bitrix в BitrixVM нет.

Если на старый сервер вас пускают только по ключу, а вход по паролю выключен, сделайте на новом сервере ключ для переезда:

        ssh-keygen -t ed25519

    

На все вопросы ответьте Enter. Команда создаст ключ /root/.ssh/id_ed25519, и SSH будет пользоваться им сам. Теперь старому серверу нужно разрешить вход по этому ключу. Выведите на новом сервере открытую часть ключа:

        cat /root/.ssh/id_ed25519.pub

    

Команда напечатает одну строку вида ssh-ed25519 AAAAC3Nza... root@bx9, в конце — имя нового сервера. Скопируйте её целиком.

Зайдите на старый сервер так, как заходите обычно, и откройте файл с ключами, которым разрешён вход под root:

        nano /root/.ssh/authorized_keys

    

Перейдите в конец файла стрелками, с новой строки вставьте скопированную строку, сохраните файл (Ctrl+O, затем Enter) и выйдите из nano (Ctrl+X). Затем выставьте файлу права:

        chmod 600 /root/.ssh/authorized_keys

    

Зачем: если файл могут читать другие пользователи, SSH не принимает ключи из него. После переезда уберите этот ключ со старого сервера: откройте файл той же командой nano, встаньте на строку, которая заканчивается на root@bx9, удалите её сочетанием Ctrl+K и сохраните файл. Если на старый сервер вы заходите по паролю, ключ не нужен.

Теперь забираем оба каталога сайтов разом, во временную папку, без кэша:

        mkdir -p /home/bitrix/mig
rsync -aH --info=stats2 --exclude='bitrix/cache/' --exclude='bitrix/managed_cache/' --exclude='bitrix/stack_cache/' --exclude='bitrix/html_pages/' root@203.0.113.10:/home/bitrix/www root@203.0.113.10:/home/bitrix/ext_www /home/bitrix/mig/

    

При первом подключении SSH спросит, доверять ли старому серверу. Проверьте, что в команде IP именно старого сервера, и ответьте yes. Затем rsync один раз спросит пароль root старого сервера, если вход по паролю. Что здесь что:

• -a сохраняет права, владельцев и даты файлов;
• -H сохраняет жёсткие ссылки;
• --exclude пропускает папки кэша Битрикса, на новом сервере кэш соберётся заново;
• root@203.0.113.10:/home/bitrix/www — основной сайт. Если на старом сервере он не используется и там только заглушка BitrixVM, уберите его из команды;
• /home/bitrix/mig/ — временная папка на новом сервере, из неё сайты встанут на место ниже.

В конце rsync печатает итог: сколько файлов передано и какой объём. Если копирование оборвалось, запустите ту же команду ещё раз: rsync докопирует только то, чего на новом сервере ещё нет.

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

        mkdir -p /root/mig/placeholders
mv /home/bitrix/ext_www/corp.example.ru /root/mig/placeholders/
mv /home/bitrix/mig/ext_www/corp.example.ru /home/bitrix/ext_www/

    

Последние две команды повторите для каждого дополнительного сайта. Основной сайт переставляется так же:

        mv /home/bitrix/www /root/mig/placeholders/www
mv /home/bitrix/mig/www /home/bitrix/www

    

Перенос внутри одного диска выполняется мгновенно. Если в /home/bitrix/mig/ext_www после этого остались файлы, а не папки сайтов (например, файлы паролей для basic auth), перенесите их в /home/bitrix/ext_www/ тоже. Пустую /home/bitrix/mig можно удалить.

Шаг 5. Базы

Если переносили резервной копией из админки, база уже восстановлена, а restore.php записал её пароль в .settings.php. Из этого шага выполните пункты 6 и 7.

При переносе rsync базы переносятся дампом: снять на старом сервере, загрузить на новом. Старая база при этом остаётся нетронутой.

1. Узнайте версию MySQL на старом сервере: в админке «Настройки → Инструменты → SQL запрос» выполните SELECT VERSION();. BitrixVM 7 ставит 5.7, но через меню её могли обновить до 8.0. Затем проверьте базы скриптом mysql57-precheck.sql, он работает и на 5.7, и на 8.0 и только читает. Скачайте его командой curl -O https://bxmax.ru/files/bitrix-migration/mysql57-precheck.sql, откройте в nano и в первой строке впишите свои базы через запятую, например SET @dbs = 'corp_db,next_db';, и запустите:

        mysql -t < mysql57-precheck.sql

    

В выводе важны два раздела. collations — кодировки таблиц, основная понадобится в пункте 4. reserved words — колонки, имена которых в MySQL 8 стали зарезервированными словами, например RANK в b_search_custom_rank. Ядро берёт такие имена в обратные кавычки, а свой SQL без кавычек на 8.4 упадёт: поищите эти имена в коде в local/ поиском по проекту в редакторе. Если на старом сервере уже 8.0, RANK и SYSTEM ваш код уже пережил, новые зарезервированные слова в 8.4 только QUALIFY и TABLESAMPLE.

2. На старом сервере снимите дамп каждой базы в папку /root/mig, где уже лежит список расширений PHP из шага 0:

        mysqldump --single-transaction --quick --hex-blob --no-tablespaces --default-character-set=utf8mb4 --routines --triggers --events --result-file=/root/mig/corp_db.sql corp_db

    

3. На новом сервере под root заберите эту папку целиком, так же как файлы в шаге 4:

        rsync -a root@203.0.113.10:/root/mig/ /root/mig/old/

    

Дампы и список расширений окажутся в /root/mig/old на новом сервере.

4. На новом сервере верните базе кодировку старого сервера и загрузите дамп. Меню создаёт базы в utf8mb4_0900_ai_ci, а на старых установках Битрикса таблицы обычно в utf8 (utf8mb3). Какая кодировка у ваших таблиц, покажет проверка из пункта 1. Для utf8_unicode_ci зайдите в консоль MySQL командой mysql (под root пароль она не спросит) и выполните:

        ALTER DATABASE corp_db CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci;

    

Ответ Query OK значит, что всё в порядке. Выйдите из консоли MySQL командой exit и загрузите дамп:

        mysql corp_db < /root/mig/old/corp_db.sql

    

Импорт работает молча. Если в конце нет строк с ERROR, он прошёл.

5. Выставьте пользователям баз настоящие пароли из .settings.php. Скрипт set-db-pass.sh читает пароль из файла, на экран его не выводит, меняет пароль в MySQL и пробует войти:

        bash set-db-pass.sh /home/bitrix/ext_www/corp.example.ru
# corp_user@localhost   NULL   732

    

В ответ скрипт печатает пользователя, под которым вошёл, и число таблиц в базе. Запустите его для каждого сайта, включая основной: bash set-db-pass.sh /home/bitrix/www.

У основного сайта база sitemanager и пользователь bitrix0 на новом сервере уже есть. Если в старом .settings.php основного сайта такие же имена, загружайте дамп в sitemanager. Если другие, проще всего поменять в bitrix/.settings.php основного сайта database на sitemanager, а login на bitrix0. Пароль не трогайте, его выставит скрипт. Если в bitrix/php_interface/dbconn.php есть $DBName и $DBLogin, поменяйте их тоже.

6. Откройте у каждого сайта bitrix/php_interface/after_connect_d7.php и after_connect.php. Если там есть SET innodb_strict_mode=0, закомментируйте эту строку: поставьте в её начале //. Зачем: в MySQL 8 такой запрос требует привилегию SESSION_VARIABLES_ADMIN, которой у пользователя сайта нет, и сайт падает на первом же запросе с SqlQueryException. Сама строка не нужна: BitrixVM 9 и так держит innodb_strict_mode=0 на сервере.
7. Верните старую кодировку соединения. BitrixVM 9 прописывает в /etc/my.cnf соединение в utf8mb4_0900_ai_ci. Сайт, у которого в after_connect_d7.php нет SET NAMES, начинает работать с базой не в той кодировке, что раньше. Индексы по колонкам в utf8 при таком поиске не используются, а запросы, где сравниваются колонки с разными правилами сравнения, падают с Illegal mix of collations. Откройте в nano или через SFTP файл /etc/mysql/conf.d/z_bx_custom.cnf, MySQL читает его после /etc/my.cnf. Для таблиц в utf8_unicode_ci запишите (готовый файл: z_bx_custom.cnf):

Файл: /etc/mysql/conf.d/z_bx_custom.cnf

        [mysqld]
character-set-server = utf8mb3
collation-server = utf8mb3_unicode_ci
init-connect = "SET NAMES utf8mb3 COLLATE utf8mb3_unicode_ci"

    

Для другой основной кодировки подставьте её во все три строки. Перезапустите MySQL:

        systemctl restart mysqld

    

Проверьте в админке сайта: «Настройки → Инструменты → SQL запрос», запрос SELECT @@character_set_connection, @@collation_connection;. Ответ должен совпасть с тем, что этот же запрос возвращает на старом сервере.

Шаг 6. Что BitrixVM 9 выключает по умолчанию

BitrixVM 9 выключает больше, чем BitrixVM 7. Меню об этом не предупреждает, а сайт падает только на тех страницах, которым нужно выключенное. Пройдите по списку из шага 0.

Расширения PHP

BitrixVM выключает расширение так: оставляет в /etc/php.d/ пустой файл, например 20-curl.ini, а оригинал переименовывает в 20-curl.ini.disabled. По сравнению с BitrixVM 7 девятка дополнительно выключает curl, phar, xmlreader и xmlwriter. Без phar не подключаются файлы из .phar-архивов, а без xmlreader и xmlwriter не работают, например, выгрузки в XLSX через PhpSpreadsheet. pdo, pdo_mysql и posix выключены в обеих версиях: если сайт работал с ними, их на старом сервере включали руками.

Сохраните список расширений нового сервера и сравните его со списком старого, который вы скопировали в шаге 5:

        php -m > /root/php-modules-new.txt
diff /root/mig/old/php-modules-old.txt /root/php-modules-new.txt

    

Строки с < — расширения, которые были на старом сервере и которых нет на новом. Строки с > — новые, например igbinary, intl, msgpack, pgsql и redis. Сайтам они не мешают.

curl и phar включаются в меню: 9. Manage pool web servers → 1. Manage PHP extensions.

Для остальных пунктов в меню нет. Скопируйте содержимое .disabled в пустой файл и перезапустите Apache. Для xmlreader и xmlwriter:

        cp /etc/php.d/20-xmlwriter.ini.disabled /etc/php.d/20-xmlwriter.ini
cp /etc/php.d/30-xmlreader.ini.disabled /etc/php.d/30-xmlreader.ini
systemctl restart httpd

    

Проверьте в админке на странице «Настройки PHP»: включённые расширения должны появиться в ней отдельными разделами.

Модули Apache

Модули Apache BitrixVM 9 выключает так же: пустой файл в /etc/httpd/conf.modules.d/ и оригинал с .disabled. Выключены proxy, ssl, cgi, dav, lua, brotli, h2 и proxy_h2. mod_proxy был выключен и в BitrixVM 7. Если правила .htaccess с флагом [P] работали на старом сервере, модуль, скорее всего, подключал лишний файл, найденный в шаге 0. Создайте такой же на новом сервере в nano или через SFTP. Для [P] нужны два модуля:

Файл: /etc/httpd/conf.modules.d/zz-proxy.conf

        LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

    

Отдельный файл лучше, чем правка пустого 00-proxy.conf: сразу видно, что модуль включили вы, а не BitrixVM. Проверьте конфигурацию Apache:

        httpd -t

    

Должно быть Syntax OK. Тогда примените:

        systemctl reload httpd

    

Откройте страницу, которую .htaccess отдаёт через [P]: она должна открываться, а не отвечать ошибкой 500.

Дополнительные домены

Если в шаге 0 нашлись имена сайта, кроме <домен> и www.<домен>, их нужно прописать в nginx и в Apache.

В nginx BitrixVM 9 подключает внутри блока server все файлы из /etc/nginx/bx/site_settings/<домен>/, а server_name можно писать в одном блоке несколько раз. Поэтому дополнительные имена кладите в отдельный файл, его меню не перезапишет:

Файл: /etc/nginx/bx/site_settings/corp.example.ru/z_aliases.conf

        server_name spb.corp.example.ru kazan.corp.example.ru ekb.corp.example.ru;

    

Проверьте конфигурацию командой nginx -t и примените: systemctl reload nginx.

В Apache такого места нет: конфиг сайта ничего не подключает внутри VirtualHost. Откройте /etc/httpd/bx/conf/bx_ext_corp.example.ru.conf в nano и допишите имена в строку ServerAlias после www.corp.example.ru. Над строкой оставьте комментарий, что имена добавлены руками: если меню перегенерирует этот файл, например при смене настроек HTTPS, их придётся дописать снова.

Cron и почта

• Агенты на cron, если при создании сайта ответили иначе: 8. Configure pool sites → 3. Change a site's cron settings.
• Свои задания cron перенесите вручную: crontab -e -u bitrix на новом сервере и вставьте строки со старого.
• Отправку писем настройте заново: 8. Configure pool sites → 4. Change a site's email settings.

Шаг 7. Проверка до переключения DNS

DNS ещё смотрит на старый сервер. Чтобы открыть сайт на новом, пропишите его домен в файле hosts на своём компьютере. В Windows это C:\Windows\System32\drivers\etc\hosts, в macOS и Linux — /etc/hosts. Добавьте строку:

        203.0.113.20 corp.example.ru www.corp.example.ru

    

Теперь браузер откроет сайт с нового сервера. Сертификат пока самоподписанный от BitrixVM, браузер об этом предупредит: так и должно быть до шага 8.

Что проверить:

• главную, основные разделы, личный кабинет, корзину и формы;
• админку: «Настройки → Инструменты → Проверка системы». Запустите её на старом и на новом сервере и сравните результаты. Новые ошибки — то, что нужно исправить до переключения;
• версию PHP и расширения: «Настройки → Инструменты → Диагностика → Настройки PHP».

Если страниц много, их удобнее проверить из консоли нового сервера скриптом http-check.sh. Он отправляет запросы через nginx этого сервера без правки hosts и для каждого адреса печатает код ответа, размер, время и есть ли в ответе ошибки PHP. Список адресов скрипт берёт из urls.txt, по одному на строку:

        bash http-check.sh 127.0.0.1 < urls.txt

    

Если сайт закрыт паролем (basic auth), передайте логин и пароль вторым параметром: bash http-check.sh 127.0.0.1 'логин:пароль' < urls.txt.

Сравнить ядро старого и нового сервера одной строкой можно скриптом bx-cli-check.php. Он подключает ядро сайта и печатает версию main, PHP и MySQL, кодировку соединения и sql_mode. Запустите его на обоих серверах, строки должны совпасть везде, кроме версий PHP и MySQL:

        sudo -u bitrix php bx-cli-check.php /home/bitrix/ext_www/corp.example.ru
# main 26.0.0 | php 8.3.36 | mysql 8.4.11-11 | conn utf8mb3/utf8mb3_unicode_ci | sql_mode '' | strict 0

    

При проверке учтите:

• Первый заход на страницу может идти десятки секунд. Кэш Битрикса не копировали, и сайт собирает его заново. Повторные заходы будут быстрыми. Перед переключением DNS такие страницы стоит прогреть, например пройти по адресам из sitemap.xml.
• Ошибки, которые были на старом сервере, переезжают как есть. Прежде чем чинить ошибку на новом сервере, откройте ту же страницу на старом.

Когда закончите, удалите строку из hosts.

Шаг 8. Переключение

1. За сутки снизьте TTL DNS-записей до 300 секунд, чтобы переключение разошлось быстро.
2. Закройте сайты на старом сервере на время переноса, чтобы в базу ничего не записалось. Публичную часть можно временно закрыть в настройках главного модуля.
3. Снимите финальные дампы и загрузите их на новый сервер, как в шаге 5. Проверку баз и правки после импорта повторять не нужно.
4. Запустите rsync на новом сервере второй раз. Теперь он кладёт файлы прямо на место, удаляет на новом сервере то, что удалили на старом, и не трогает исправленные в шаге 5 файлы after_connect:

        rsync -aH --delete --info=stats2 --exclude='bitrix/cache/' --exclude='bitrix/managed_cache/' --exclude='bitrix/stack_cache/' --exclude='bitrix/html_pages/' --exclude='bitrix/php_interface/after_connect*.php' root@203.0.113.10:/home/bitrix/www root@203.0.113.10:/home/bitrix/ext_www /home/bitrix/

    

Если переносили резервной копией, вместо пунктов 3 и 4 сделайте новую копию на старом сервере и восстановите её поверх сайта на новом, как в способе 1 шага 4. После этого снова закомментируйте SET innodb_strict_mode=0 в after_connect: восстановление вернёт старый файл. Сайт будет закрыт всё это время, на больших сайтах это часы. Тогда финальный перенос удобнее сделать rsync и дампом.

5. Переключите DNS на новый сервер.
6. Выпустите сертификаты: 8. Configure pool sites → 5. Change a site's https settings. Let’s Encrypt выдаёт сертификат, только когда домен уже указывает на новый сервер. Проверьте, что http:// перенаправляет на https://.
7. Прогрейте кэш.
8. Не выключайте старый сервер, пока новый не проработает несколько дней.

Если после переключения что-то пошло не так, верните DNS на старый сервер и откройте на нём сайты. Всё, что пользователи успели записать на новом сервере (заказы, заявки, регистрации), останется только там, поэтому решать, откатываться или чинить на месте, лучше в первые часы.