Кончилось место на сервере BitrixVM: что проверить и что почистить

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

Нехватка места на сервере редко выглядит как нехватка места. Сначала падает что-то другое, и час уходит на поиски не там.

Как это проявляется

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

Посмотреть, сколько места и где

Если доступа по SSH нет, а в административную часть вы попадаете, ту же команду можно выполнить в php-консоли: print_r(shell_exec('df -h'));

df -h

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

Дальше ищем виновника сверху вниз:

du -sh /home/bitrix/* | sort -h
du -sh /var/log/* | sort -h
du -sh /var/lib/mysql/* | sort -h

Что обычно занимает место

С чего начинать чистку

Порядок — от безопасного к осторожному. После каждого шага смотрите df -h: если место вернулось, дальше можно не идти.

1. Резервные копии продукта. Каталог bitrix/backup/ внутри сайта — первое, куда стоит заглянуть: один полный архив весит почти столько же, сколько сам сайт. На нашей машине там два месяца лежал архив на 906 МБ при размере сайта 3 ГБ. Копии нужны, но не на том же диске, что и сайт.
2. Кеш компонентов и управляемый кеш. Пересоздаются сами, удалять можно на работающем сайте:

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

   Путь зависит от того, где лежит сайт: на машине с несколькими сайтами это /home/bitrix/ext_www/<домен>/.
3. Кеш уменьшенных картинок — upload/resize_cache/. Удаляется безопасно, но пересобирается при первых же посещениях и нагружает процессор, поэтому в час пик его лучше не трогать.
4. Файлы обмена с 1С — upload/1c_catalog/ и каталоги выгрузок. Там копятся файлы прошлых обменов, иногда по гигабайту и больше.
5. Журналы. Про них ниже отдельно: чаще всего самым большим каталогом на машине оказываются именно они.

Журналы веб-сервера: сначала проверьте ротацию

На машине, с которой писался этот разбор, каталог /var/log занимал 2,7 ГБ — больше, чем весь сайт. Из них 2,2 ГБ приходилось на журналы nginx, а один файл доступа дорос до 1,2 ГБ за два месяца.

Дело было не в посещаемости: ротация не отработала ни разу. Проверяется это одной командой:

ls /var/log/nginx/ | grep -c '\.gz$'

Ноль в ответе означает, что старые журналы не упаковываются и не удаляются — правило ротации в системе есть, а выполнять его некому. Дальше смотрите, жив ли планировщик и что он собирается делать:

systemctl list-timers 'logrotate*'
logrotate -d /etc/logrotate.conf

Вторая команда показывает действия logrotate, ничего не меняя.

Вторая ловушка — журналы отдельного сайта: их заводит его собственная конфигурация, имена у них свои, владелец root, и под общее правило они попадают не всегда. Сверьте пути из конфигурации сайта с маской в /etc/logrotate.d/nginx.

Ещё два файла растут незаметно. /var/log/cron: на виртуальной машине Битрикса агенты запускаются раз в минуту, и каждый запуск оставляет запись. /var/log/btmp: неудачные попытки входа. Если второй распух до сотен мегабайт, по SSH кто-то перебирает пароли — чистка файла такой симптом не лечит.

Двоичные журналы базы — частый сюрприз

На виртуальных машинах Битрикса включено ведение двоичного журнала MySQL: он нужен для репликации и восстановления на точку во времени. Настройки лежат в отдельном файле конфигурации (на машинах вендора это bx_replica.cnf), и если срок хранения не ограничен, журналы спокойно съедают десятки гигабайт.

Удалять их файлами нельзя — база потеряет согласованность. Чистят штатной командой очистки журналов и выставляют разумный срок хранения, чтобы не возвращаться к этому каждый квартал.

Чего делать нельзя

• Удалять файлы базы руками. Табличные файлы и журналы чистятся только средствами самой базы, иначе она не поднимется.
• Чистить /upload/ целиком. Там файлы сайта: картинки товаров, документы, вложения. Кеш — только подкаталог resize_cache.
• Удалять каталоги ядра, чтобы освободить место: продукт не запустится, восстанавливать придётся из копии.
• Удалять журнал, который ведётся прямо сейчас. Пока служба держит файл открытым, место не вернётся, даже если файла уже нет в каталоге. Обнуляйте его — truncate -s 0 /var/log/nginx/access.log — или перезапускайте службу после удаления.

Когда освободили, а не помогло

Типичная картина: место освободили, а база всё равно не стартует или сайт отдаёт ошибку. Проверьте:

1. Перезапущены ли службы. База, упавшая от нехватки места, сама не поднимется.
2. Тот ли раздел вы чистили. Вывод df -h после чистки должен показывать свободное место именно там, где его не было.
3. Не осталось ли удалённых, но открытых файлов. Пока процесс держит удалённый журнал, место не возвращается — помогает перезапуск службы.
4. Не кончились ли иноды. Место есть, а файлы не создаются: смотрите df -i. Обычно это миллионы мелких файлов кеша.

Чтобы не повторялось

1. Перенесите резервные копии с сервера: копия рядом с сайтом не спасёт при отказе диска и занимает место.
2. Ограничьте срок хранения двоичных журналов базы.
3. Настройте ротацию журналов системы и веб-сервера.
4. Поставьте оповещение о свободном месте: предупреждение за неделю до аварии стоит дешевле самой аварии.

Если чистить уже нечего, диск пора расширять — порядок в отдельной инструкции. А если место съедает база, смотрите разбор про размер базы Битрикс24.