Обновления в Битрикс: с чего начать и не уронить сайт

Полный цикл обновления «1С-Битрикс: Управление сайтом» занимает час-два, из которых само скачивание и установка ядра — минут десять-двадцать. Остальное время уходит на резервную копию, проверку окружения и тест витрины после. В конце у вас свежее ядро¹, работающий сайт и бэкап, к которому можно вернуться, если что-то пойдёт не так. Ниже — порядок для современных сборок продукта: ядро D7, каталог /local, ветки 20.x и новее. Точный номер версии главного модуля вы увидите на странице обновлений.

Что нужно иметь до начала

• Учётную запись администратора сайта с правом запускать обновление системы.
• Доступ к файлам (SSH, реже FTP) и доступ к базе данных. Параметры подключения лежат в /bitrix/.settings.php, в старых сборках — в /bitrix/php_interface/dbconn.php.
• Активный период обновлений по лицензии. Без него страница обновлений покажет список, но файлы не скачает.
• Свободное место на диске: два объёма каталога /bitrix плюс дамп базы. Обновление распаковывает архивы рядом, а не вместо.
• Желательно — копию сайта на тестовом домене. Это единственный способ узнать заранее, что обновление сделает с вашими правками.
• Окно низкого трафика. Не вечер пятницы перед акцией.

Версию и состояние лицензии смотрите в административной панели: раздел Marketplace → Обновление системы (адрес страницы — /bitrix/admin/update_system.php). Там же список модулей с номерами версий и дата, до которой обновления доступны.

Пошагово: от проверки лицензии до чистого кеша

1. Запишите текущие версии. Откройте страницу обновления системы и сохраните себе список модулей с номерами версий — скриншотом или текстом. Если после обновления что-то отвалится, вы будете знать, с какой версии уехали. Проверка: видите таблицу модулей и дату доступности обновлений.

2. Прогоните «Проверку системы». Настройки → Инструменты → Проверка системы, вкладка с тестами окружения. Инструмент проверяет версии PHP и базы, права на запись, настройки кодировки и почты. Проверка: в отчёте нет красных пунктов. Жёлтые предупреждения прочитайте, но они обычно не блокируют обновление.

3. Снимите бэкап файлов и базы. Встроенный модуль резервного копирования подойдёт для небольших сайтов, но на магазине с тяжёлым /upload надёжнее консоль или бэкап на уровне хостинга.

   # Дамп базы. Пароль не пишем в команде — mysqldump спросит его отдельно
   mysqldump --single-transaction --routines --events -u DB_USER -p DB_NAME > ~/bitrix_db.sql
   
   # Проверяем, что дамп дописался до конца
   tail -n 1 ~/bitrix_db.sql
   
   # Архив файлов. Запускать из корня сайта
   tar -czf ~/bitrix_files.tar.gz bitrix local upload .htaccess

   Проверка: последняя строка дампа содержит Dump completed, архив не нулевого размера. Если /upload весит десятки гигабайт, архивируйте его отдельно или возьмите снапшот у хостера — но не пропускайте.

4. Найдите свои правки внутри /bitrix. Обновление перезаписывает файлы ядра: /bitrix/modules, /bitrix/js, /bitrix/components/bitrix, стандартные шаблоны. Всё, что доработано прямо там, обновление снесёт. Посмотрите, что лежит в /bitrix/components помимо папки bitrix, что в /bitrix/templates, есть ли код в /bitrix/php_interface/init.php. Проверка: у вас на руках список нестандартных файлов. Кастомизации, перенесённые в /local², обновление не трогает — если успеваете перенести до запуска, перенесите.

5. Выберите окно и прикройте сайт. На время установки лучше отдавать посетителям заглушку на уровне веб-сервера, чем половину обновлённого ядра. Для контентного сайта хватит и ночного часа без заглушки. Проверка: вы знаете, что покажет сайт в момент обновления.

6. Запустите обновление. На странице обновления системы нажмите установку доступных обновлений. Убедитесь, что в параметрах не включено получение бета-версий: на продакшене они не нужны. Обновления приходят порциями, после каждой система может попросить продолжить и отдельно обновить структуру базы. Повторяйте, пока страница не сообщит, что обновлений нет. Проверка: номера версий модулей выросли, сообщений об ошибках нет.

7. Сбросьте кеш. В админке это раздел настроек автокеширования, в консоли — очистка каталогов /bitrix/cache, /bitrix/managed_cache, /bitrix/stack_cache. Если включён композитный кеш, сбросьте и его. Проверка: каталоги пустые, страницы собираются заново (первое открытие заметно медленнее).

8. Прогоните смоук-тест. Главная, карточка товара, поиск, добавление в корзину, оформление заказа, форма обратной связи, вход в личный кабинет, вход в админку. Отдельно посмотрите лог ошибок PHP за время обновления. Проверка: ни одна из этих страниц не отдаёт 500 и не рисует пустой экран.

9. Обновите решения Marketplace отдельно. Ядро и сторонние модули живут по разным циклам: раздел установленных решений в Marketplace обновляется своими кнопками. Делайте это после ядра и по одному решению за раз. Проверка: в списке решений нет пометок о доступных обновлениях, сайт по-прежнему проходит смоук-тест.

Обновление ломает не ядро. Оно ломает ваши правки в ядре — те, о которых забыли через три года после сдачи проекта. Поэтому четвёртый шаг важнее шестого.

Если не получилось

Fatal error: Allowed memory size ... exhausted

PHP уперся в memory_limit на распаковке или обновлении базы. Поднимите лимит для сайта, сбросьте кеш и запустите обновление заново — оно продолжится с места, где остановилось, повторная установка уже поставленных обновлений не навредит.

Maximum execution time of N seconds exceeded

Шаг не уложился в max_execution_time. Увеличьте лимит и повторите. Если упирается постоянно на одном и том же модуле, обновляйте порциями: ставьте доступные обновления по частям, проверяя страницу после каждого прохода.

Ошибка соединения с сервером обновлений

Формулировка меняется от версии к версии, суть одна: PHP не смог выйти наружу. Проверьте исходящий доступ по 443 порту с сервера, настройки прокси и файрвола, правильность файла лицензионного ключа /bitrix/license_key.php. Актуальный список адресов сервера обновлений смотрите в документации продукта — не подставляйте тот, что нашли на форуме пятилетней давности.

Сообщение об истёкшем периоде обновлений

Лицензия работает дальше, сайт не выключается, но новые обновления ядра скачиваться не будут до продления. Условия и порядок продления уточняйте у вендора или партнёра, через которого покупали лицензию.

Белый экран или 500 после обновления

Сначала лог ошибок PHP — он почти всегда называет конкретный файл. Типичные виновники: перезаписанная кастомизация ядра, несовместимое сторонние решение, устаревший код в init.php. Отладочный вывод ошибок включается в /bitrix/.settings.php, в секции exception_handling — но делайте это на копии сайта, а не на живом: трассировки на проде показывать посторонним нельзя. Если причину не видно за десять минут, разворачивайте бэкап и разбирайтесь на тестовом домене.

Старая версия не обновляется за один заход

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

Что делать дальше

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

Параллельно уберите главную причину боли: перенесите свои компоненты, шаблоны и обработчики из /bitrix в /local. После этого обновление перестаёт быть лотереей. Держите тестовую копию сайта в актуальном состоянии и проверяйте обновления сначала на ней. И следите за двумя вещами в проде после каждого обновления: лог ошибок PHP в первые сутки и время ответа ключевых страниц — свежее ядро иногда меняет поведение кеша, и это видно именно в графике отклика.

1. Ядро — файлы самой CMS в каталоге /bitrix: модули, системные компоненты, библиотеки JS. Обновление системы заменяет их целиком, поэтому любые правки внутри ядра считаются одноразовыми.

2. /local — каталог в корне сайта для ваших компонентов, шаблонов и обработчиков. Система ищет код в нём с приоритетом, а обновления его не перезаписывают.