Почему после восстановления Bitrix24 через restore.php перестают работать сессии, Push и WebSocket

Недавно мне потребовалось перенести корпоративный портал Bitrix24 на новую BitrixVM. По документации всё выглядело достаточно просто:

• развернуть новую виртуальную машину;

• обновить систему;

• восстановить резервную копию через restore.php;

• дождаться окончания восстановления.

Казалось бы, что может пойти не так? Практически всё.

После восстановления портал встретил меня сразу несколькими ошибками:

• Could not start session by PHP;

• не запускался Push Server;

• появилось сообщение «Отсутствует соединение с сервером»;

• браузер показывал ошибки WebSocket;

• часть пользователей вообще не могла войти в портал.

На поиск причины ушло несколько дней. Самое интересное оказалось в том, что виноват был вовсе не restore.php.

restore.php      │      ▼Восстановление файлов      │      ▼Восстановление базы данных      │      ▼Копирование .settings.php      │      ▼Старые параметры инфраструктуры(Memcached, Push, DNS)      │      ▼Ошибки после восстановления

В статье покажу последовательность диагностики и объясню, почему возникают такие проблемы.

Подготовка новой BitrixVM

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

dnf update -yreboot

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

cat /etc/redhat-release

Затем убеждаемся, что используются ожидаемые версии компонентов.

php -vnginx -vhttpd -vmysql --version

Это позволяет сразу убедиться, что восстановление выполняется в корректном окружении.

Проверяем сервисы

Перед запуском restore.php рекомендую проверить основные службы.

Важно

restore.php восстанавливает файлы сайта, базу данных и настройки приложения. Однако он не проверяет состояние инфраструктуры нового сервера.

Проблема №1. Could not start session by PHP

После завершения восстановления портал открылся,н о вместо страницы авторизации появилась ошибка.

RuntimeExceptionCould not start session by PHP

Первая мысль была очевидной:

проблема в PHP.

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

Проверяем настройки Bitrix

Открываем файл .settings.php.

grep -A20 "'cache'" /home/bitrix/www/bitrix/.settings.phpgrep -A20 "'session'" /home/bitrix/www/bitrix/.settings.php

В моём случае настройки выглядели следующим образом.

'cache' => [    'type' => 'memcache',    'memcache' => [        'host' => 'bitrix_test',        'port' => '11211',    ],];

Аналогичная конфигурация использовалась для хранения сессий.

'session' => [    'handlers' => [        'general' => [            'type' => 'memcache',            'host' => 'bitrix_test',        ],    ],];

Именно здесь скрывалась причина.После восстановления Bitrix продолжал использовать настройки старого окружения.

Почему restore.php не виноват

В этот момент стало понятно, что проблема вовсе не в механизме восстановления.restore.php делает именно то, для чего предназначен:

• восстанавливает файлы сайта;

• восстанавливает базу данных;

• переносит настройки приложения.

Но он не адаптирует эти настройки под новую инфраструктуру.Если старый сервер использовал:

• Memcached;

• Redis;

• Push Server;

• внутренние DNS-имена,

то все эти параметры будут восстановлены без изменений.В моём случае Bitrix пытался подключиться к серверу

bitrix_test

которого на новой виртуальной машине уже не существовало.

Исправляем проблему

Если Memcached должен работать локально, меняем

'host' => 'bitrix_test'

на

'host' => '127.0.0.1'

После этого запускаем сервис.

systemctl enable memcachedsystemctl start memcached

Проверяем, что порт прослушивается.

ss -lntp | grep 11211

Получаем:

127.0.0.1:11211

После этого ошибка PHP-сессий исчезла.

Проблема №2. Push Server

После успешного входа в портал появилось сообщение:

Отсутствует соединение с сервером

В консоли браузера отображалась ошибка.

WebSocket connection failed

Первым делом проверяем Push Server.

systemctl status push-server

Если сервис не запускается, сразу открываем журнал.

journalctl -u push-server -n 100

В журнале обнаружилась ошибка.

Error: Cannot find module'/etc/push-server/push-server-sub-8015.json'Require stack:- /opt/push-server/config/index.js- /opt/push-server/lib/application.js- /opt/push-server/server.jscode: 'MODULE_NOT_FOUND'

Из сообщения видно, что Push Server не смог найти конфигурационный файл одного из экземпляров.

Проверяем содержимое каталога.

ls -la /etc/push-server

Получаем:

push-server-pub-1005PORT.jsonpush-server-sub-1006PORT.json

Оказалось, что присутствуют только шаблоны конфигурации.

Рабочие файлы отсутствовали.

Пересоздаём конфигурацию.

/usr/bin/push-server-multi configs

После этого Push Server успешно запускается.

Однако сообщение «Отсутствует соединение с сервером» никуда не исчезает.

Проверяем WebSocket

Проверяем обработчик WebSocket.

curl https://server/bitrix/subws/

Вместо ответа Push Server сервер возвращает страницу авторизации Bitrix.

Это означает, что запрос вообще не попадает в обработчик WebSocket и обрабатывается PHP.

Настоящая причина

Проверяем конфигурацию nginx.

location ^~ /bitrix/subws/ {    #push_stream_subscriber websocket;}

Все директивы оказались закомментированы.При этом установленный nginx уже не содержал старый модуль nginx-push-stream.Получилась следующая ситуация.

Push Server работает        │        ▼WebSocket-запрос приходит в nginx        │        ▼location /bitrix/subws/ не обрабатывается        │        ▼Запрос передаётся в PHP        │        ▼Bitrix возвращает страницу авторизации        │        ▼WebSocket connection failed

Что стоит проверить после любого восстановления

После этой миграции я составил для себя небольшой чек-лист.Проверить сервисы.

systemctl status nginxsystemctl status httpdsystemctl status mysqlsystemctl status memcachedsystemctl status push-server

Проверить настройки Bitrix.

grep -A20 "'cache'" bitrix/.settings.phpgrep -A20 "'session'" bitrix/.settings.php

Проверить открытые порты.

ss -lntp

Проверить WebSocket. Открыть инструменты разработчика (F12 → Console) и убедиться, что отсутствуют ошибки вида:

WebSocket connection failed

Выводы

Главный вывод этой миграции оказался неожиданным. Проблемы были вызваны не restore.php, а тем, что вместе с приложением восстановились настройки старого окружения:

• Memcached;

• Push Server;

• параметры WebSocket;

• внутренние DNS-имена.

Поэтому после каждого восстановления Bitrix24 рекомендую проверять не только успешность запуска сайта, но и соответствие инфраструктурных настроек новой виртуальной машине.

В первую очередь стоит проверить:

• .settings.php;

• Memcached или Redis;

• Push Server;

• маршрутизацию WebSocket;

• журналы системных сервисов.

Это занимает всего несколько минут, но позволяет избежать долгого поиска причин уже после запуска портала.