Обновление 1С-Битрикс и переезд на BitrixVM 9 без простоя

Обновления Битрикс копятся годами — и в один день сайт либо перестаёт обновляться, либо открывает дыру, о которой знают все, кроме вас. Разбираем, как обновить коробочный Битрикс и переехать на BitrixVM 9 так, чтобы это заметили только логи.

Зачем обновлять

• Безопасность. Старое ядро — это известные и уже описанные дыры: уязвимости PHP и самого Битрикс находят публично, и эксплойты появляются быстро. Недавний пример — PHP2Shell: две критические уязвимости PHP и как проверить версию.
• PHP. Битрикс новых версий требует свежий PHP, а свежий PHP — поддержку на сервере. Замкнутый круг: пока не обновите серверное окружение, не встанет ни актуальная версия CMS, ни новые модули.
• Marketplace и поддержка. Обновления модулей, платежных и доставочных интеграций выходят для актуальных релизов; на старой версии вы получаете отказ или «не поддерживается».

Что проверить заранее

Обновление меняет файлы ядра и структуру базы. Несовпадение версий ядра и базы после обновления делает сайт неработоспособным — поэтому список ниже не «на всякий случай», а обязательный минимум:

1. Резервная копия файлов и базы — штатный инструмент: Настройки → Инструменты → Резервное копирование. Копию нужно не просто сделать, а проверить восстановимой.
2. PHP и серверное окружение — версия PHP, БД и расширений под требования целевого релиза. В BitrixVM системные компоненты не всегда обновляются вместе с пакетами окружения — это отдельная операция.
3. Модули и интеграции — совместимость сторонних модулей, платёжек, доставки, обменов с 1С.
4. Изменённый код — кастомные правки ядра, компонентов и шаблонов: сверяете на копии, а не на боевом сайте.
5. Ресурсы — место на диске под архив, память и время выполнения на бэкап и миграции базы.

Обновление «наживую» без проверенной копии — это не скорость, а ставка. Обычно проигрывают.

Как проходит обновление

1. Поднимаем тестовую копию сайта — на ней проверяется всё, что боится владелец.
2. Обновления ставятся из админки: Marketplace → Обновление платформы. Описания обновлений читаем: модули связаны зависимостями, выборочное обновление без них ломает соседей.
3. Прогон критических сценариев: вход, формы, поиск, оформление и оплата заказа, обмен с 1С, отправка писем, фоновые задачи.
4. Перенос на боевой сайт в согласованное окно, контрольная точка и мониторинг после.

Переезд на BitrixVM 9

BitrixVM 9 (релиз — август 2024) построен на новом поколении ОС: CentOS Stream 9 по умолчанию, из «длинных» дистрибутивов официально поддерживаются также AlmaLinux 9, Rocky Linux 9 и Oracle Linux 9. В комплекте — PHP 8.1 по умолчанию с возможностью перейти на 8.2/8.3.

Важно: со старых BitrixVM 7 на CentOS 7 «пакетным обновлением» не переезжают — там другая основа ОС. Это отдельный проект: новое окружение + перенос сайта. Куда переезжать с CentOS 7 в целом — разобрали в статье про переезд с CentOS.

Как переносим:

1. Готовим новый сервер: PHP, веб-сервер, базы, места хватает.
2. Переносим данные: штатный бэкап Битрикс + восстановление через restore.php, а для крупных проектов с SSH — rsync + mysqldump. Старый сайт продолжает работать.
3. Проверяем новый сайт до переключения — на временном адресе: база, сертификат, почта, формы, обмены, фоновые задачи.
4. В согласованное окно — финальная синхронизация изменений и переключение трафика (IP/DNS). После — проверка и логи; старый сервер держим про запас.

Честно про «без простоя»: бэкап сам по себе его не даёт — изменения, сделанные после копии, в неё сами не попадут. Ноль простоя даёт именно финальная синхронизация и короткое окно переключения: покупатели видят минуты, а не часы.

Сроки

Официальных «нормативов» у Битрикса нет. Ориентиры из материалов интеграторов: установка обновлений как отдельная операция — от 30 минут; полный цикл обновления с тестовой копией, настройкой окружения и правками — порядка 10 часов; переезд на новое окружение — от нескольких часов до 1–2 рабочих дней. На сильно кастомизированных и давно не обновлявшихся проектах объём растёт. Точную оценку даём после аудита и тестового переноса — до старта, а не по факту.

Частые ошибки

1. Обновление наживую без проверенной копии — откатить нечего.
2. Обновили ядро, оставили старый PHP — сломался кастомный шаблон.
3. Работы днём в боевое окно без остановки заявок — клиенты ловят ошибки.
4. Снесли старый сервер в день переезда — потеряли единственный откат.
5. Забыли cron, сертификаты и обмены с 1С — сайт жив, а письма и остатки врут.

Если после обновления что-то поехало впервые за долгое время — сначала не «откатывайте всё», а зафиксируйте симптомы и изолируйте проблему. А чтобы подобное не повторилось, начинают с аудита безопасности.