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

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

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