Обновление Битрикса без поломок: порядок, который меня ни разу не подвёл

Порядок такой: проверить место на диске и версию PHP, снять бэкап и убедиться, что он разворачивается, обновиться на копии, пройти по сценариям, и только потом трогать боевой сайт. Минорные обновления модулей на бою после бэкапа занимают 30-40 минут.

Обновление Битрикс это процедура, после которой сайт либо продолжает работать, либо встречает вас белым экраном и строчкой в логе про фатальную ошибку в файле, который вы никогда не открывали. Я веду абонентку шесть лет и обновлял Битрикс, наверное, пару сотен раз: от визиток на Старте до магазинов на Бизнесе с обменом с 1С и эквайрингом. Ниже порядок, который у меня ни разу не закончился лежащим сайтом. Он скучный, занимает от сорока минут до половины рабочего дня, и работает именно поэтому.

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

Почему Битрикс ломается чаще, чем другие CMS

Дело не в том, что код плохой. Дело в устройстве продукта и в том, что с ним делают за годы жизни сайта.

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

Второе. Правки в ядре. За пять лет сайт проходит через три подрядчика, и каждый второй правит файл прямо в /bitrix/components/bitrix/catalog.section/, потому что «так быстрее». Обновление аккуратно перезаписывает этот файл оригиналом. Функционал, который держался на правке, отваливается молча: ошибки в логе нет, просто перестала работать фильтрация по цвету.

Третье. Лицензия. Обновления доступны, пока активен год технической поддержки. Когда он кончился, кнопка обновления перестаёт приносить файлы, а сайт продолжает стареть вместе с PHP на хостинге. Через два года такого простоя обновление превращается в проект на неделю. Про сам механизм и цены я писал отдельно: что делать, когда лицензия Битрикса закончилась.

Четвёртое. Старые сайты в cp1251. Битрикс до сих пор встречается в однобайтовой кодировке, и любая невнимательная операция с базой превращает каталог в вопросительные знаки. Это не проблема обновления как такового, но именно на обновлении её обычно и находят.

Подготовка: что проверить до того, как жать кнопку

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

Проверка системы

Штатный инструмент лежит по адресу /bitrix/admin/site_checker.php. Он проверяет права на файлы, доступность почты, настройки PHP, работу сокетов, соединение с базой и десяток мелочей. Запускайте оба режима, быстрый и полный.

Что смотреть в первую очередь:

• версия PHP и наличие расширений mbstring, zip, gd, mysqli;
• значения memory_limit, max_execution_time, post_max_size;
• права на запись в /bitrix/, /upload/, /local/;
• доступность внешних соединений (без них каталог обновлений просто не отдаст файлы).

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

Требования к PHP

Свежие ветки ядра требуют PHP 8.1 и выше. Живых сайтов на 7.4 в 2026 году всё ещё много, и в этом случае обновление становится двухходовкой: сначала PHP, потом Битрикс. Порядок именно такой, потому что старое ядро на новом PHP обычно работает (с предупреждениями), а новое ядро на старом PHP не запускается вообще. Переключать версию на шаред-хостинге лучше в панели управления и с возможностью вернуть старую в один клик: почти все российские хостеры это умеют, и почти никто про эту кнопку не помнит.

Свободное место

Обновление скачивает архив, распаковывает его во временный каталог /bitrix/updates/ и только потом раскладывает файлы. На мажорном апдейте это легко полтора-два гигабайта пиковой нагрузки на диск. Если у вас тариф на 10 ГБ и занято 9,4, обновление встанет на середине с самым унылым результатом.

# сколько занято и сколько осталось
du -sh ~/site.ru/public_html
df -h ~

# самые жирные каталоги внутри сайта
du -h --max-depth=2 ~/site.ru/public_html | sort -hr | head -20

Чаще всего место съедают три вещи: старые бэкапы в /bitrix/backup/, кеш в /bitrix/cache/ и /bitrix/managed_cache/, и ресайзы картинок в /upload/resize_cache/. Кеш и ресайзы можно чистить смело, они пересоздадутся. Бэкапы из /bitrix/backup/ надо не удалять, а увозить с сервера (об этом ниже).

Срок лицензии

/bitrix/admin/update_system.php показывает дату окончания обновлений прямо на главной вкладке. Если до неё осталось меньше месяца, продлевайте до обновления. Продление Старта обходится порядка 8 000-9 000 руб., Стандарта в районе 25 000, и это дешевле, чем застрять с полураскатанным апдейтом и без права качать файлы.

Инвентаризация кастома

Самый важный и самый пропускаемый пункт. Нужно понять, что на сайте написано руками и где именно.

# компоненты, скопированные в вендорское пространство (их перезапишет обновление)
ls -la bitrix/components/bitrix/ | head -40

# правильное место для кастома
ls -la local/components/ local/templates/ 2>/dev/null

# правки в init.php и настройках
ls -la bitrix/php_interface/init.php local/php_interface/init.php 2>/dev/null

Если у вас нет каталога /local/, а в /bitrix/components/bitrix/ лежат компоненты с датой изменения «прошлый вторник», значит правки делали в ядре. Такие файлы надо сохранить отдельно и после обновления сравнить с новыми оригиналами. Идеально, конечно, вынести их в /local/ заранее, но это отдельная работа на несколько часов, и делать её в один заход с обновлением я не советую.

Бэкап, который потом реально развернётся

Бэкап, который никто не проверял, это не бэкап, а надежда. Перед обновлением Битрикса нужен именно проверенный.

Штатный модуль резервного копирования (Настройки, Инструменты, Резервное копирование) удобен тем, что кладёт рядом restore.php и разворачивается почти без рук. Неудобен тем, что на магазине с гигабайтами картинок он падает по таймауту. Поэтому на любом сайте тяжелее пары гигабайт я делаю бэкап руками.

cd ~/site.ru/public_html

# база: реквизиты лежат в bitrix/.settings.php
mysqldump --single-transaction --quick --default-character-set=utf8mb4 
  -u DB_USER -p DB_NAME > ~/backup/db-$(date +%F-%H%M).sql

# файлы без кеша и старых архивов
tar czf ~/backup/files-$(date +%F-%H%M).tar.gz 
  --exclude='bitrix/cache' 
  --exclude='bitrix/managed_cache' 
  --exclude='bitrix/stack_cache' 
  --exclude='bitrix/backup' 
  --exclude='upload/resize_cache' 
  .

Две оговорки, на которых люди обжигаются.

Первая: если сайт в cp1251 (в bitrix/php_interface/dbconn.php нет define("BX_UTF", true)), то --default-character-set должен быть cp1251. Дамп в utf8mb4 с однобайтовой базы формально снимется, но при восстановлении вы получите кракозябры вместо названий товаров, и поймёте это через неделю.

Вторая: архив, который лежит на том же хостинге, спасает только от кривого обновления. От сгоревшего диска, заблокированного за неуплату аккаунта и удалившего всё злоумышленника он не спасает. Уносите копию наружу, хотя бы в объектное хранилище за 30-60 руб. в месяц. Аргументы и варианты я разбирал в статье про то, где хранить резервные копии.

Проверка бэкапа занимает пять минут и выглядит так:

# дамп не обрезан таймаутом
tail -5 ~/backup/db-2026-09-14-1030.sql   # должно быть "Dump completed"
ls -lh ~/backup/                          # размер похож на правду, не 2 КБ

# архив читается целиком
tar tzf ~/backup/files-2026-09-14-1030.tar.gz > /dev/null && echo "archive ok"

Тестовая копия: чем она отличается от боевой

Обновлять Битрикс сразу на бою можно на визитке из пяти страниц. На всём остальном сначала копия.

Копия это тот же код и та же база на отдельном поддомене вроде test.site.ru, закрытом от индексации и от посторонних. Отличия от боевого сайта обязательны, иначе тестовая копия начнёт слать письма клиентам и списывать деньги с карт.

Что	Боевой	Тестовая копия
Домен	site.ru	test.site.ru, доступ по паролю
Индексация	открыт	Disallow: / плюс закрыт HTTP-авторизацией
Почта	реальный SMTP	отключена или перенаправлена на свой ящик
Обмен с 1С	включён	выключен полностью
Эквайринг	боевой ключ	тестовый ключ или заглушка
Агенты и крон	на кроне	отключены на время тестов
Метрика	счётчик 108769363	счётчик убран

Развёртывание в общем виде:

# 1. распаковать файлы в каталог поддомена
mkdir -p ~/test.site.ru/public_html && cd ~/test.site.ru/public_html
tar xzf ~/backup/files-2026-09-14-1030.tar.gz

# 2. залить базу в отдельную БД
mysql -u TEST_USER -p TEST_DB < ~/backup/db-2026-09-14-1030.sql

# 3. поправить реквизиты подключения
#    bitrix/.settings.php и bitrix/php_interface/dbconn.php

# 4. сбросить кеш и композит
rm -rf bitrix/cache/* bitrix/managed_cache/* bitrix/stack_cache/* bitrix/html_pages/*

После этого в админке копии обязательно пройдитесь по трём местам: Настройки почты, модуль обмена с 1С, настройки платёжных систем. Я один раз забыл выключить обмен на тестовой копии, и она за ночь выгрузила в боевую 1С полтора десятка тестовых заказов. Неприятно, чинится, но осадок остался.

Если поддомена и лишних рук нет, копию можно поднять локально в контейнере или на дешёвом VPS за 400-600 руб. в месяц, который берётся на два дня и гасится. Подробнее про смысл и стоимость такой площадки: staging для маленького сайта.

Порядок обновления

Дальше собственно процедура. Я делаю строго в этом порядке, отклоняюсь только когда точно понимаю, зачем.

1. Снять бэкап и проверить его (см. выше). Дата и время в имени файла обязательны.
2. Записать текущую версию ядра. Она видна в /bitrix/admin/update_system.php и в файле bitrix/modules/main/install/version.php. Без этой записи потом не поймёшь, откуда откатываться.
3. Включить режим обслуживания, если сайт коммерческий и апдейт крупный. Достаточно заглушки в .htaccess с ответом 503 и заголовком Retry-After.
4. Отключить агенты на время работ или убедиться, что они на кроне, а не на хитах. Агент, стартовавший в момент замены файлов ядра, даёт самые непонятные ошибки.
5. Обновить главный модуль (main) отдельным шагом. Битрикс сам предложит это сделать, соглашайтесь. Ядро всегда идёт первым.
6. Обновить остальные системные модули. На большом сайте система разобьёт это на несколько заходов, каждый заход завершается перезагрузкой страницы обновления.
7. Обновить решения из Маркетплейса. Только после ядра, никогда до. Если у партнёрского модуля нет версии под новое ядро, вы узнаете об этом здесь.
8. Сбросить кеш целиком: /bitrix/admin/cache_dir.php или руками через rm -rf по каталогам из примера выше. Композитный кеш в bitrix/html_pages/ тоже.
9. Прогнать site_checker.php ещё раз.
10. Пройти сценарии приёмки руками: главная, каталог, карточка товара, поиск, форма заявки, оформление заказа до платёжки, вход в личный кабинет. Список сценариев лучше держать письменным и одинаковым от обновления к обновлению, иначе каждый раз проверяется что-то своё, а ломается непроверенное.
11. Снять режим обслуживания и час-другой посматривать в логи и в Метрику.

Отдельно про шаблоны и кастом. Обновление не трогает /local/ и ваши собственные шаблоны в /bitrix/templates/<your_template>/. Оно перезаписывает /bitrix/components/bitrix/, /bitrix/modules/ и шаблон .default. Если после апдейта отвалилась какая-то мелочь в вёрстке или логике вывода, ищите правку, которая жила в перезаписанном файле, и переносите её в /local/. Один раз перенесли, дальше обновления перестают её съедать.

Если обновление встало на середине

Штатная ситуация, а не катастрофа. Обычно виноват таймаут PHP, нехватка памяти или оборвавшееся соединение с каталогом обновлений.

Что делать по шагам:

• Не трогать ничего десять минут. Битрикс мог продолжить работу в фоне, и параллельный запуск сделает хуже.
• Перезагрузить /bitrix/admin/update_system.php и посмотреть, что он говорит. Система обновления пошаговая и продолжает с того места, где встала.
• Если страница обновления не открывается, но админка работает, поднять лимиты и повторить:

# .htaccess в корне сайта, на время обновления
php_value memory_limit 512M
php_value max_execution_time 600
php_value max_input_time 600

На части хостингов php_value в .htaccess запрещён, тогда лимиты правятся в панели или в .user.ini.

• Если каталог /bitrix/updates/ забит мусором от неудачной попытки, его содержимое можно вычистить и запустить заново.
• Если админка не открывается вообще, включаем показ ошибок и смотрим, на чём падает:

// bitrix/.settings.php, секция exception_handling
'debug' => true,
'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_DEPRECATED,
'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_DEPRECATED,

Плюс лог веб-сервера, он обычно лежит в ~/logs/ или ~/site.ru/logs/. Фатальная ошибка с именем файла и номером строки закрывает половину вопросов за минуту.

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

План отката и когда им пользоваться

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

Откат сайта site.ru, обновление 14.09.2026
1. Включить 503-заглушку в .htaccess
2. mv public_html public_html_broken && mkdir public_html
3. tar xzf ~/backup/files-2026-09-14-1030.tar.gz -C public_html
4. mysql -u USER -p DB < ~/backup/db-2026-09-14-1030.sql
5. rm -rf public_html/bitrix/cache/* public_html/bitrix/html_pages/*
6. Снять заглушку, проверить главную и оформление заказа

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

Критерии, по которым я принимаю решение откатываться:

Симптом	Решение
Отвалилась одна некритичная мелочь в вёрстке	Чиним на месте, откат не нужен
Не работает форма заявки или корзина	30 минут на диагностику, дальше откат
Белый экран на всём сайте	Смотрим лог 10 минут, дальше откат
Сломался обмен с 1С	Откат, если склад расходится, иначе чиним
Ошибка в админке, витрина живая	Чиним, откат не нужен

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

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

Регламент вместо героизма

Обновление Битрикса перестаёт быть событием, когда становится процедурой. У меня в абонентке это выглядит так:

• раз в месяц: проверка списка доступных обновлений, накат минорных апдейтов модулей на бою после бэкапа, 30-40 минут;
• раз в квартал: мажорные обновления через тестовую копию, 3-5 часов;
• раз в год: проверка срока лицензии и версии PHP, планирование переезда на актуальную ветку;
• всегда: бэкап до, письменный список сценариев приёмки после.

Разовое обновление запущенного Битрикса, когда апдейтов не было два года, у меня стоит от 12 000 до 40 000 руб. в зависимости от количества кастома и наличия обмена с 1С. Регулярное сопровождение с ежемесячными обновлениями входит в абонентские тарифы, и в пересчёте на месяц выходит заметно дешевле разбора завалов. Разработка нового сайта и редизайн в эту работу не входят, я занимаюсь именно поддержкой того, что уже работает.

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

Частые вопросы

Как безопасно обновить Битрикс

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

Почему Битрикс ломается чаще других CMS

Из-за связанности модулей и из-за правок в ядре, которые делают в проектах со сложной логикой. Обновление накатывается на изменённые файлы, и результат непредсказуем.

Что делать, если обновление встало на середине

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

Когда откатываться, а когда чинить

Белый экран на всём сайте это откат, разбираться потом на копии. Не работает одна форма или один раздел это диагностика: полчаса на поиск причины, дальше по обстоятельствам.