Закончилось место на диске в Битрикс: чистка кеша, логов и бэкапов

Опять письмо от хостинга «диск заполнен на 95%», или сайт падает с ошибкой записи во временные файлы, хотя товаров и страниц вы неделями не добавляли. Закончилось место на диске в Битрикс - одна из самых частых причин простоя интернет-магазинов, с которой я разбираюсь на практике у клиентов на выделенных серверах и в облаке. Разберём, откуда берётся мусор и как почистить кеш, логи и бэкапы без риска потерять рабочий сайт.

Откуда на самом деле кончается место на сервере с Битрикс

За три года работы с проектами на 1С-Битрикс я вывел для себя примерный расклад: в 60% случаев виноват кеш и его производные, в 25% - неубранные бэкапы, в оставшихся - логи и мусор в /upload. Ниже таблица с типичными объёмами, которые я видел на реальных проектах с каталогом на 5-10 тысяч товаров.

Диагностика перед чисткой: что реально жрёт место

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

du -sh /home/bitrix/www/* | sort -rh | head -20
df -h

Если на сервере доступен ncdu, ставлю его сразу, интерактивный обзор диска экономит минут двадцать по сравнению с ручным перебором du по подпапкам. На хостингах вроде Timeweb или Beget часто не хватает прав на apt-get install, тогда обхожусь связкой du и sort по каталогам bitrix/cache, bitrix/backup, upload и log.

Чистка кеша Битрикс: managed cache, stack cache и композит

Кеш в Битрикс живёт в нескольких местах, и это не всегда очевидно новичкам. Файловый кеш лежит в bitrix/cache, кеш компонентов и результатов запросов - в bitrix/managed_cache, а стек-кеш меню и других вложенных структур - в bitrix/stack_cache. Если у вас включена композитная технология, добавляется ещё html_pages с готовыми HTML-страницами для анонимных посетителей, и это отдельная и часто самая тяжёлая папка.

Самый безопасный способ почистить всё разом - через админку: «Настройки» - «Настройки продукта» - «Автокеширование» - кнопка «Очистить кеш». Но когда место кончилось прямо сейчас и в админку зайти не получается из-за забитого диска, я захожу по SSH и чищу руками.

rm -rf /home/bitrix/www/bitrix/cache/*
rm -rf /home/bitrix/www/bitrix/managed_cache/*
rm -rf /home/bitrix/www/bitrix/stack_cache/*
rm -rf /home/bitrix/www/bitrix/html_pages/*

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

Логи: где они растут и что можно удалять без опаски

Второй по частоте виновник - логи, которые никто не ротирует годами. У меня был случай на проекте с интеграцией СДЭК и обменом с 1С: php error_log вырос до 6 ГБ из-за того, что модуль обмена сыпал одну и ту же ошибку авторизации каждые несколько минут, а логротейт на сервере не был настроен вовсе.

Что обычно стоит проверить:

• error_log PHP - путь обычно в php.ini или в .htaccess проекта
• Логи Apache/Nginx - access.log и error.log, на некоторых хостингах растут без ограничения
• MySQL slow query log, если он включён для отладки и забыт
• upload/1c_exchange - файлы обмена с 1С, накапливаются с каждой синхронизацией
• bitrix/modules/main/tools - служебные временные файлы модулей

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

Бэкапы: почему они съедают весь диск быстрее всего

Встроенный модуль резервного копирования Битрикс по умолчанию кладёт архивы в bitrix/backup - на тот же диск, где крутится сайт. Это устраивает, пока сайт маленький, но на магазине с изображениями товаров и видео бэкап быстро становится крупнее самого проекта, а если backup настроен без ротации, через несколько месяцев там лежит десяток архивов по 10-20 ГБ каждый.

При работе с интеграциями оплаты через Т‑Банк или прием заказов из WooCommerce-каталога, перенесённого на Битрикс, я всегда сразу выношу бэкапы за пределы рабочего диска, обычно на отдельный сервер, в Яндекс.Облако или S3-совместимое хранилище. Это не только экономит место, но и страхует от ситуации, когда бэкап и рабочие файлы гибнут одновременно при аппаратном сбое.

При настройке автоматического бэкапа в самом Битрикс полезно исключать из архива папки upload с тяжёлыми медиафайлами и bitrix/cache - кеш всё равно пересоздаётся, а таскать его в бэкапе бессмысленно и долго.

Автоматизация очистки: cron вместо ручной работы

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

0 3 * * * find /home/bitrix/www/bitrix/backup/ -name "*.tar.gz" -mtime +7 -delete
0 4 * * 0 find /home/bitrix/www/upload/1c_exchange/ -type f -mtime +14 -delete
0 2 * * * find /var/log/nginx/ -name "*.log.*.gz" -mtime +30 -delete

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

Как не допустить повторения: мониторинг свободного места

После чистки диска первым делом настраиваю алерт, чтобы не ловить ту же проблему через три месяца. Минимальный вариант - cron-скрипт, который раз в час проверяет df ‑h и шлёт сообщение в Telegram-бот на aiogram, если занято больше 85%. Для проектов посерьёзнее ставлю Zabbix или подключаю мониторинг от хостинга, если он есть в тарифе.

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

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

Можно ли удалять папку bitrix/cache прямо на боевом сайте без остановки?

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

Почему после чистки кеша место на диске освобождается не сразу?

Если файлы кеша были открыты процессом PHP-FPM или Apache в момент удаления, место освобождается только после того, как процесс закроет дескриптор. Обычно помогает перезапуск php-fpm или веб-сервера следующей командой: systemctl restart php-fpm.

Сколько места должно оставаться свободным на сервере с Битрикс в норме

Я стараюсь держать запас не меньше 20% от общего объёма диска, а для проектов с активными бэкапами и обменом 1С - не меньше 15-20 ГБ свободных даже на полном диске. Ниже этого порога MySQL и временные файлы Битрикс начинают падать с ошибками записи.

Что делать, если диск заполнен на 100% и админка не открывается

Подключаюсь по SSH и вручную удаляю содержимое bitrix/cache, managed_cache и старые архивы из bitrix/backup, этого обычно хватает, чтобы освободить достаточно места для запуска админки. После восстановления доступа уже настраиваю автоматическую ротацию логов и бэкапов, чтобы ситуация не повторилась.