Как обновить сервер коробочного Битрикс24: перенос с CentOS 7, BitrixVM, PHP и базы данных

Как безопасно обновить сервер коробочного Битрикс24 на CentOS 7: перенос на новое окружение, BitrixVM, PHP, база данных, синхронизация, сроки и стоимость.

Если коробочный Битрикс24 работает на старом сервере, например на CentOS 7, и уже требует обновления PHP, базы данных или BitrixVM, обычно речь идет не об одном обновлении, а о миграции всей рабочей среды.

Коротко

• Что нужно сделать: проверить текущий сервер, подготовить новое поддерживаемое окружение, перенести копию Битрикс24, последовательно обновить компоненты, проверить портал, синхронизировать актуальные данные и переключить пользователей.
• Основные риски: несовместимость PHP и модулей, ошибки базы данных и восстановления, старый собственный код, приложения и интеграции, cron и агенты, а также потеря изменений между первой копией и финальным переключением.
• Как снижаем риск: не обновляем рабочий сервер вслепую, используем отдельную площадку, двигаемся через проверяемые промежуточные состояния и сохраняем возможность возврата к старому серверу.
• Срок: типовой проект такого класса занимает около 5-7 дней.
• Простой: 5-7 дней проекта не означают 5-7 дней недоступности. Основная работа идет параллельно с действующим сервером. Для финальной синхронизации и переключения обычно требуется отдельное технологическое окно.
• Стоимость: типовой проект такого класса в CRM4 сейчас стоит 77 000-97 000 ₽. Точная оценка зависит от состояния сервера, объема данных, приложений, интеграций и собственных доработок.

Ниже разберем, почему такая задача быстро выходит за рамки обычного обновления Битрикс24, из каких этапов состоит миграция и где чаще всего возникают проблемы.

Почему предупреждение об обновлении PHP или MySQL может означать гораздо большую задачу

Типовая ситуация выглядит довольно спокойно. Компания несколько лет использует коробочный Битрикс24.

Сервер работает, сотрудники работают, и без необходимости никто инфраструктуру не меняет.

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

Если при этом портал работает на CentOS 7, задача становится шире.
CentOS Linux 7 завершил жизненный цикл 30 июня 2024 года. После этой даты штатные обновления для CentOS Linux 7 больше не публикуются. Источник: CentOS Project.

Для актуальной коробочной версии Битрикс24 минимальная версия PHP - 8.2 и выше, а для MySQL разработчик рекомендует ветку 8.x. Источник: технические требования Битрикс24.

В результате появляется связанная система:
старая ОС -> старое серверное окружение -> старые PHP и СУБД -> ограничения на обновление Битрикс24

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

Можно обновить PHP и получить несовместимость со старым кодом.
Можно обновить СУБД и столкнуться с ошибками базы.
Можно обновить сам Битрикс24, но упереться в ограничения серверного окружения.

Поэтому исходная задача “обновить коробку” постепенно превращается в проект миграции инфраструктуры.

Коробочный Битрикс24 - это не одна программа

У коробочной версии есть несколько связанных уровней.
Внизу находится операционная система.
На ней работает серверное окружение, веб-сервер, PHP, база данных и фоновые сервисы.

Выше находятся ядро Битрикс24 и его модули.

Еще выше - приложения, интеграции, собственный код и конкретные бизнес-процессы компании.

Поэтому фраза “сервер работает” сама по себе ничего не говорит о результате миграции.
Linux может работать корректно, nginx может отвечать, база может запускаться, главная страница Битрикс24 может открываться.
А потом выясняется, что не работает агент.
Или перестал выполняться старый PHP-код.
Или не запускается интеграция.
Или робот в CRM не делает то, что делал раньше.
Или почта принимает письма, но дальнейший сценарий не выполняется.

Для бизнеса результат миграции - не работающий Linux.
Результат - работающая система Битрикс24 со всеми необходимыми процессами.

Именно поэтому мы рассматриваем такую работу как перенос инфраструктуры, а не как набор отдельных обновлений.

Почему нельзя просто сделать резервную копию и восстановить ее на новом сервере

Логика кажется очевидной:
создали backup -> развернули новый сервер -> восстановили backup -> готово

Резервная копия действительно нужна. Но она решает только часть задачи.
Backup сохраняет данные и позволяет восстановить определенное состояние портала.
Он не делает старую систему автоматически совместимой с новой версией PHP, СУБД или серверного окружения.
Внутри портала может находиться код, написанный под старую версию PHP.
Отдельные модули могут иметь собственные требования.
Интеграции могут зависеть от настроек старого сервера.
Cron, агенты, локальные сервисы и фоновые процессы могут быть настроены отдельно от самой резервной копии Битрикс24.

Поэтому успешное восстановление файлов и базы - это только промежуточная точка.
После нее еще нужно получить рабочий Битрикс24 и проверить прикладные процессы.
Универсальной кнопки “перенести старую коробку на современный сервер и автоматически исправить все несовместимости” здесь нет.

Как мы выстраиваем миграцию

Главный принцип - не пытаться одним прыжком попасть из старой системы в конечную.
Нам нужны промежуточные состояния, в которых понятно, что именно изменилось и работает ли система после этого изменения.

Сначала проверяем текущий сервер

До любых изменений нужно зафиксировать исходную точку.
Какая установлена ОС.
Какие версии PHP и СУБД используются.
Какая версия BitrixEnv или BitrixVM.
В каком состоянии сам Битрикс24.
Какие установлены приложения и модули.
Есть ли собственный PHP-код.
Какие работают интеграции.
Как настроены cron и агенты.
Какой объем занимает база данных и файловое хранилище.
Без этого нельзя надежно построить маршрут обновления.

Затем приводим исходную систему в стабильное состояние

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

Мы не пытаемся сразу превратить старую систему в современную.
Проверяем базу данных, состояние портала, резервирование и доступные обновления.
Если какие-то компоненты можно безопасно актуализировать еще до переноса, это снижает количество переменных на следующих этапах.
Нам нужна понятная рабочая точка, из которой начинается миграция.

Проверяем резервирование

Фраза “backup у нас есть” недостаточна.
Нужно понимать, что именно входит в резервную копию, где она хранится и каким способом система будет восстановлена, если один из следующих этапов закончится нештатно.
Резервирование в таком проекте - не формальность.
Это часть архитектуры миграции.

Подготавливаем новый сервер

После этого отдельно готовится целевая площадка.
На нее устанавливается поддерживаемая операционная система и необходимое серверное окружение.

Ключевое преимущество такого подхода в том, что пользователи пока продолжают работать на старом сервере.
На новом можно восстанавливать данные, менять конфигурацию, проверять версии и исправлять ошибки без постоянного воздействия на рабочую систему.

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

Здесь есть принципиальный момент.
Не нужно сразу после переноса обновлять все компоненты до максимальных версий.
Сначала желательно понять, можно ли вообще воспроизвести исходное состояние портала на новой площадке и какие проблемы возникают уже на этом переходе.
Если система не запускается на первом этапе, мы исправляем именно первый переход.
Так проще понять причину ошибки.

После этого начинаются последовательные обновления

Рабочая схема выглядит так:
изменение -> запуск -> проверка -> исправление -> следующее изменение

Конкретная последовательность зависит от исходных версий.

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

Поэтому универсальная инструкция “сначала всегда обновите PHP, потом MySQL, потом Битрикс24” была бы слишком грубой.
Правильный порядок определяется после обследования конкретной системы.
Битрикс24 отдельно рекомендует выполнять переход на новые версии PHP поэтапно. Источник: Битрикс24, переход на PHP 8.x.

Почему последовательность здесь настолько важна

Представим другой подход.

Одновременно меняем операционную систему, PHP, СУБД, BitrixEnv и версию Битрикс24.
После этого портал не запускается.
Что стало причиной?
PHP.
База.
Серверная конфигурация.
Модуль.
Старый код.
Интеграция.

Мы получаем сразу несколько направлений поиска.
Если изменения делаются последовательно, после каждого этапа остается значительно меньше неизвестных.
Именно в этом состоит одна из главных практических ценностей опыта подобных миграций.
Не в знании одной команды Linux.
А в понимании, в каком порядке менять систему и где искать причину, если очередной переход не прошел штатно.

Что обязательно проверять после переноса

Факт открытия портала еще не означает, что работа закончена.
Нужно проверить именно те процессы, которыми пользуется компания.
CRM должна сохранять и изменять данные.
Роботы и бизнес-процессы должны запускаться.
Задачи должны создаваться и закрываться.
Почта должна работать в обе стороны там, где она используется.
Телефония должна продолжать передавать события.
Интеграции должны обмениваться данными.
REST и вебхуки должны отвечать ожидаемым образом.
Агенты и cron должны запускаться.
Приложения и собственные доработки должны пройти отдельную проверку.

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

Откуда появляется финальная синхронизация

Есть еще одна проблема, которую легко не заметить при планировании.
Допустим, в понедельник мы сделали копию рабочего Битрикс24 и начали переносить ее на новый сервер.

Во вторник сотрудники продолжили работать.

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

К моменту, когда новая площадка полностью проверена, первоначальная копия уже устарела.
Поэтому между тестовой миграцией и реальным переключением должен быть предусмотрен способ переноса накопившихся изменений.
Как именно будет организована эта синхронизация, зависит от архитектуры конкретной системы, объема данных и того, что менялось во время проекта.
Но игнорировать этот этап нельзя.
Иначе технически исправный новый сервер будет содержать неактуальные данные.

Почему финальное переключение часто делаем ночью

Когда новая система подготовлена и проверена, остается финальный переход.
На определенный период нужно прекратить появление новых изменений на старой площадке, выполнить необходимую синхронизацию, переключить систему и провести контрольную проверку.

В нашей практике примерно в 80% подобных проектов этот этап удобнее выполнять ночью.
Это не отраслевой норматив, а наше практическое наблюдение.

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

5-7 дней проекта не означают 5-7 дней простоя

Для типового проекта такого класса наш ориентир - около 5-7 дней.
Эти дни нужны не потому, что Битрикс24 все это время выключен.
Пока сотрудники продолжают работать на старом сервере, на новой площадке идет восстановление, обновление компонентов, проверка, поиск несовместимостей и тестирование.
Ограничение работы требуется только на финальном этапе, когда необходимо зафиксировать данные и выполнить переключение.
Поэтому корректнее говорить не “перенос вообще без простоя”, а “миграция с минимальным заранее спланированным технологическим окном”.

Обещать полное отсутствие недоступности до обследования системы было бы неправильно.

Почему лучше использовать второй сервер

Обновлять единственный production-сервер на месте можно только тогда, когда риски этого решения понятны, приемлемы и Операционная система не меняется.

Для старой коробки Битрикс24 обычно безопаснее другая схема.
Старый сервер продолжает обслуживать пользователей.
Новый используется как площадка миграции.

Если на новом что-то пошло не так, это не означает автоматическую остановку рабочего Битрикс24.
Кроме того, старый сервер остается точкой возврата до тех пор, пока новая система не прошла приемку.

Если свободной машины внутри инфраструктуры нет, можно использовать временно арендованный сервер.
На него переносится система, выполняются обновления и проверки.

Если по архитектуре нужно сохранить старое физическое оборудование, после этого основной сервер можно переустановить и вернуть уже обновленную систему обратно.

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

Почему здесь недостаточно только системного администратора

Сильный Linux-администратор может подготовить операционную систему, сеть, веб-сервер, PHP, СУБД, резервирование и другие инфраструктурные компоненты.
Но результат проекта находится выше уровня Linux.

Нужно еще понимать, как должен вести себя коробочный Битрикс24 после изменения окружения.
Почему не выполняется агент.
Почему приложение работает не так, как раньше.
Что произошло с роботом.
Почему REST-запрос проходит, но бизнес-сценарий не завершается.
Почему перестал работать старый модуль.

Поэтому миграция находится на стыке нескольких компетенций: Linux и серверной инфраструктуры, BitrixEnv или BitrixVM, базы данных, резервирования и самого коробочного Битрикс24.

Отдельная компетенция - управление всей последовательностью перехода.

Когда инфраструктуру меняет один специалист, Битрикс24 проверяет второй, интеграцию поддерживает третий, а единого ответственного за миграцию нет, любая ошибка быстро превращается в спор о том, на чьей она стороне.

За что клиент платит в таком проекте

Некоторые отдельные технические действия действительно занимают немного времени.
Создать виртуальную машину.
Установить компонент.
Скопировать данные.
Изменить конфигурационный файл.

Но стоимость миграции определяется не количеством команд в терминале.

Главная работа - правильно обследовать исходную систему, построить маршрут перехода, сохранить возможность отката, провести несколько контролируемых изменений, распознать ошибки и проверить результат на уровне самого Битрикс24.

Мы обслуживаем несколько десятков серверов и регулярно сталкиваемся с ситуациями, когда похожие исходные конфигурации дают разные проблемы во время обновления.

Часть ценности здесь - накопленный опыт предыдущих миграций, включая понимание того, какие действия лучше не выполнять и где обычно проявляются ошибки.

Поэтому клиент покупает не несколько часов работы одного технического специалиста.
Он покупает управляемый переход из текущего рабочего состояния в новое рабочее состояние и одного ответственного за этот результат.

Сколько стоит обновление и перенос сервера коробочного Битрикс24

Сейчас типовой проект такого класса в CRM4 стоит 77 000-97 000 ₽.

Финальная стоимость зависит от исходного состояния системы, объема базы и файлов, количества приложений и интеграций, собственных доработок и сложности финальной синхронизации.
Типовой ориентир по сроку - 5-7 дней проекта.

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

Нужно ли обязательно переходить с CentOS 7 на CentOS Stream 9

Да с CentOS 7 нужно перейти на актульную операционную систему.
На момент подготовки этой статьи BitrixEnv 9 поддерживает CentOS Stream 9, Rocky Linux 9, Alma Linux 9 и Oracle Linux 9. Источник: документация BitrixEnv.

Но поддерживаемая операционная система не обязательно является оптимальной целевой системой для нового сервера.
У CentOS Stream 9 жизненный цикл заканчивается 31 мая 2027 года. Если новый сервер проектируется в сентябре 2026 года, этот срок уже имеет прямое значение для архитектурного решения. Источник: CentOS Project.

Поэтому формулировать задачу как “переносим CentOS 7 на CentOS Stream 9” только потому, что Stream 9 поддерживается BitrixEnv, мы бы не стали.
Сначала имеет смысл определить требования к целевой инфраструктуре и ожидаемый срок ее эксплуатации. После этого выбирать ОС.

Что делать с PHP и MySQL

Здесь действует тот же принцип.
Новые версии Битрикс24 требуют современного серверного окружения.
Но из этого не следует, что на старом production-сервере нужно сразу устанавливать максимально доступную версию PHP или СУБД.
Нужно учитывать исходную версию портала, серверное окружение, модули, приложения и собственный код.

Чем старше система и чем больше в ней доработок, тем важнее промежуточные проверки.
Цель проекта не в том, чтобы получить максимальные номера версий.
Цель - получить поддерживаемую инфраструктуру, на которой корректно работает конкретный Битрикс24.

Что делать, если ваш Битрикс24 уже показывает такие предупреждения

Первое действие - не начинать обновлять боевой сервер и Битрикс24.
Сначала нужно зафиксировать исходное состояние.
Какая ОС установлена.
Какие версии PHP и СУБД используются.
Какая версия BitrixEnv или BitrixVM.
Какой размер базы и файлов.
Какие есть приложения, интеграции и собственные доработки.
Есть ли актуальная и проверяемая резервная копия.

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

Если у вас похожая ситуация, можно прислать нам текущие версии ОС, PHP, базы данных и BitrixEnv или BitrixVM. Мы посмотрим исходную конфигурацию и определим возможную схему миграции, технологическое окно и ориентир по стоимости.