Недавно мне потребовалось перенести корпоративный портал 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 -y
reboot

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

cat /etc/redhat-release

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

php -v
nginx -v
httpd -v
mysql --version

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

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

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

Сервис	Команда	Ожидаемый результат
nginx	`systemctl status nginx`	active (running)
Apache	`systemctl status httpd`	active (running)
MySQL	`systemctl status mysql`	active (running)
Memcached	`systemctl status memcached`	active (running)
Push Server	`systemctl status push-server`	active (running)

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

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

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

RuntimeException
Could not start session by PHP

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

проблема в PHP.

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

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

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

grep -A20 "'cache'" /home/bitrix/www/bitrix/.settings.php
grep -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 memcached
systemctl 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.js

code: 'MODULE_NOT_FOUND'

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

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

ls -la /etc/push-server

Получаем:

push-server-pub-1005PORT.json
push-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 nginx
systemctl status httpd
systemctl status mysql
systemctl status memcached
systemctl status push-server

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

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

grep -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;
журналы системных сервисов.

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

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