Битрикс после обновления отдаёт 500, пока диск забит

После SiteUpdate сайт или коробочный портал отдаёт белый экран или 500 Internal Server Error. В чате уже «CRM лежит». Админ лезет в модули, права и кеш — и не смотрит, сколько свободно на диске.

За минуты можно отличить «диск 100%» от других причин 500, безопасно освободить место по рекомендациям 1С-Битрикс и понять, какой порог ловить до звонка клиента.

О чём статья: self-hosted БУС и коробка Битрикс24, где апдейт пишет пакеты и временные файлы на тот же раздел, что и сайт. Не о чём: облачный Битрикс24 с тарифом «Диска» — там другая модель хранилища, локальный df сервера не применим. Не путать 500 при полном диске с 502/503 (пул PHP, память, рестарт).

Типичная ловушка: выставить 777 на /bitrix/updates при ошибке [UUGZA03] и месяцами копать ACL, пока квота диска уже ноль.

Почему после «Обновить» вдруг 500

Партнёрская практика по коробке Битрикс24 описывает типичную картину сразу после обновления: белый экран или 500, портал «не грузится». Одна из самых частых причин — переполненный диск: обновление скачивает пакеты и пишет временные файлы.

На вендорском форуме SiteUpdate ошибка «[UUGZA03] Не удалось создать временную папку …/bitrix/updates/…» при правах 777 нередко оказывалась нехваткой места на хостинге — автор темы это подтверждал. Тот же паттерн всплывал у других: обмен или каталог «еле работает», а место снова кончилось.

Хостинг-разборы сообщения «The script encountered an error and will be aborted…» тоже называют закончившееся свободное место наиболее частой причиной. Практика по «сайт не открывается»: при диске 100% CMS не создаёт кеш, tmp и даже запись в лог — магазин «зависает» без явной ошибки в логах.

Официальный урок про HTTP 500 напоминает: это не «ошибка продукта» как таковая; часто лимиты shared-хостинга, права или .htaccess. Смотреть error.log сервера. Но если раздел уже полный, в лог может быть нечего писать — поэтому сначала место, потом debug модулей.

Сначала df и du, потом модули

Минимальная проверка на сервере:

• df -h — заполнение разделов; искать 100% или почти полный раздел с сайтом.
• du -sh /* | sort -rh | head -20 (или от корня сайта) — кто съел место.
• На VPS удобен ncdu; на shared — статистика и менеджер файлов панели хостинга.

В самой CMS:

• экспертный режим резервного копирования показывает объёмы БД, статистики, поискового индекса и журнала событий;
• крупные файлы контента — таблица b_file в «Настройки → Производительность → Таблицы», сортировка по FILE_SIZE (только смотреть, строки не править).

Сигнал	Что обычно значит	Куда смотреть дальше
df показывает 100% на разделе сайта	Нет места под кеш, tmp, логи, пакеты апдейта	Освобождать место; охоту на «баг модуля» остановить
[UUGZA03] и временная папка в /bitrix/updates	Часто квота диска, а не ACL	df/du, не 777 «наугад»
Белый экран / 500, error.log пуст или молчит	Раздел полный — писать некуда	Сначала место, потом debug в .settings.php
502 / 503	Пул PHP, память, рестарт — другой слой	Не лечить как «диск 100%»

Сделайте: один прогон df -h до правок модулей и прав. Не делайте: считать пустой лог доказательством «всё загадочно» — при полном диске CMS может не писать даже ошибку.

Если df показывает полный раздел — останавливаем охоту на «баг модуля» и освобождаем место. Debug в .settings.php (exception_handling → debug => true) помогает при белом экране, но на проде после починки его нужно выключить.

Как безопасно освободить место

Канон — уроки 1С-Битрикс «Рекомендации по очистке места на диске» и «Оптимизация использования места на хостинге».

1. Сначала увеличить место, если можно — вендор называет это самым простым и безопасным решением.
2. Демоданные раздувают сайт и локальные бэкапы: в коробке Б24 — «Мастер очистки данных»; в БУС — ручная чистка или чистая установка.
3. Резервные копии: удалить устаревшие локальные через «Настройки → Инструменты → Резервное копирование → Список» или вручную /bitrix/backup/. Хранить копии в облаке, не на том же диске, что сайт.
4. Кеш: админка «Настройки → Настройки продукта → Автокеширование → очистить всё» или вручную содержимое /bitrix/managed_cache/, /bitrix/resize_cache/, /bitrix/cache/. При Композите — ещё /bitrix/html_pages. Оговорка вендора: это разовая мера, не «чистить постоянно»; после очистки TTFB просядет, пока кеш не прогреется, и кеш снова вырастет.
5. Поиск, статистика, журнал событий — смотреть объёмы в экспертном режиме бэкапа; урезать сроки хранения и маски индекса.
6. /upload/ — хвосты экспорта и мёртвые файлы; крупные картинки — оптимизация без сильной потери качества (тема жива и на форуме: ответ про сжатие картинок от 04.08.2026).
7. Неиспользуемые модули, шаблоны, компоненты; в настройках модулей — лимиты картинок, сроки логов, истории и статистики.

Практика SSH, согласованная с вендором по кешу: безопасно чистить содержимое bitrix/cache, managed_cache, stack_cache, html_pages, а также bitrix/tmp и upload/tmp (после апдейтов и импортов).

Не трогать: bitrix/modules, bitrix/components, upload целиком, local, bitrix/php_interface.

В аварийном режиме иногда смотрят старые *.log старше 30 дней в /var/log и файлы /tmp/php* — только после визуальной проверки, не «rm -rf /». Перед необратимым удалением — бэкап файлов и БД, даже если сайт уже лежит. После освобождения места может понадобиться перезапуск PHP-FPM, если процессы упёрлись в I/O или tmp.

Полезные ссылки вендора и практики:

• Рекомендации по очистке места на диске
• Оптимизация использования места на хостинге
• Урок про HTTP 500

Типичные ошибки triage

• Искать баг модуля или PHP, не сделав df -h.
• Выставлять 777 на /bitrix/updates при [UUGZA03], когда проблема в квоте диска.
• Удалить /upload или modules вместо содержимого cache/tmp.
• Чистить кеш «по расписанию до нуля» как единственную стратегию: кеш вырастет снова; нужны облачные бэкапы, сроки логов и оптимизация картинок.
• Оставить debug => true на проде после разбора белого экрана.
• Путать 502/503 с 500 при полном диске.

Сделайте: бэкап файлов и БД перед необратимой чисткой. Не делайте: сносить целиком upload или modules «под метлу».

Какой порог ловить до следующего апдейта

Жёсткого percent-порога в уроке очистки 1С-Битрикс нет — чужие цифры нельзя выдавать за сертифицированные нормы вендора. Ориентиры из практики:

• партнёрский runbook: алерт при заполнении больше 80% — предупреждение до сбоя после апдейта;
• практика: занято больше 95% — зона нестабильности; для нормальной работы держать свободно хотя бы 200–300 МБ, иначе нет записи кеша, логов и tmp;
• на форуме SiteUpdate сбой создания /bitrix/updates/… при нуле места — апдейт не стартует или рвётся.

Профилактика по уроку оптимизации: не хранить локальные бэкапы рядом с сайтом на том же диске; ограничивать сроки логов/статистики/истории; оптимизировать крупные картинки в /upload/; убирать неиспользуемые модули и шаблоны.

Uptime-пингер может ещё быть «зелёным» или уже показывать 500, а корневая причина — раздел 100%. Между «сайт пингуется» и «апдейт убил прод» как раз дыра мониторинга свободного места.

Ограничения и рамка

• Scope: self-hosted БУС / коробка Битрикс24. Облачный Б24 не смешивать с df сервера.
• Не обещать «чинит за 20 минут» как статистику продукта — это формулировка чужой партнёрской практики.
• Пороги 80%, 95% и 200–300 МБ — ориентиры практики, не SLA вендора и не заявленный percent-порог BX Pulse.
• BX Pulse независим от ООО «1С-Битрикс»; не обещать, что мониторинг «гарантированно исключит простой».

Мониторинг диска до звонка клиента

Голый HTTP-пингер не видит заполнение раздела. Для эксплуатации CMS нужны внутренние метрики: диск, бэкапы, агенты/cron, лицензия, сроки SSL — чтобы заметить деградацию до обращения клиента.

Разовая починка без контроля вернёт тот же звонок после следующего апдейта. Нужен сигнал «диск заполняется», а не только «порт 443 отвечает». Если удобно держать метрики CMS рядом с uptime — подключите сайт в BX Pulse; это дополнение к triage, не замена шагов выше.

BX Pulse следит за доступностью и техническим состоянием проектов на 1С-Битрикс и коробочных порталах Битрикс24, в том числе за дисковым пространством. Имеет смысл поймать заполнение раздела на партнёрском ориентире около 80% — до понедельничного апдейта и звонка «портал лежит».

Ранний доступ и алерты по диску: Ранний доступ / демо BX Pulse — заявка на демо и настройку уведомлений по техсостоянию, включая диск. Дополнительно: Telegram BX Pulse. Если нужна помощь с разбором инцидента на стороне сайта — разработка и техподдержка; расширить место на хостинге — хостинг Beget.