Заполненный диск — одна из самых частых причин внезапных сбоев сервера. Сайт перестаёт открываться, база данных отказывается записывать изменения, почта не доходит, а в панели управления вместо привычных страниц появляются ошибки. Чем дольше проблема остаётся без внимания, тем выше риск потерять данные. Разберём, как быстро убедиться, что дело именно в диске, найти то, что занимает место, и безопасно его освободить.
Как понять, что на сервере закончилось место
Когда свободное пространство исчерпано, служба за службой начинают останавливаться: не загружаются файлы, не сохраняются сессии, не пишутся логи. Нередко подключиться к серверу получается только по SSH, а в тяжёлых случаях — только через консоль виртуализации (VNC).
Первым делом проверьте занятость разделов:
df -hПример вывода на переполненной системе:
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 40G 40G 0 100% /
/dev/sda1 512M 110M 402M 22% /boot
tmpfs 1.9G 0 1.9G 0% /dev/shmНас интересует раздел, смонтированный в корень (/), — именно там обычно лежат файлы сайтов, базы и логи. Название устройства у вас может отличаться (/dev/vda1, /dev/nvme0n1p1 и так далее), ориентируйтесь на размер и точку монтирования. Если в столбце Use% стоит 100%, диск действительно заполнен.
Не забудьте и вторую проверку — на исчерпание индексных дескрипторов (inode). Место на диске может быть свободно, но записать файл всё равно не получится, если закончились inode:
df -iШаг 1. Удалите то, что точно не нужно
Если вы заранее знаете, где лежат старые архивы, ненужные дампы или копии сайтов, сделанные «на всякий случай», начните с них. Это самый быстрый и самый безопасный способ вернуть пространство. Главное условие — убедиться, что у резервных копий есть ещё хотя бы одно хранилище вне этого сервера.
Шаг 2. Найдите самые тяжёлые каталоги
Если очевидных кандидатов нет, пусть систему просканирует сама. Эта команда выведет 20 самых объёмных каталогов первых трёх уровней вложенности, отсортировав их по размеру:
du -xh / --max-depth=3 2>/dev/null | sort -rh | head -20Параметр -x не даёт выходить за границы текущего раздела, поэтому смонтированные сетевые и дополнительные диски в расчёт не попадут. Результат может выглядеть так:
38G /
21G /var
14G /var/www
9.6G /var/www/shop/public_html
7.2G /var/backups
5.1G /var/log
3.4G /homeДальше нужен ручной анализ: для каждого крупного каталога задайте себе вопрос, нормально ли, что он такой большой, и можно ли его почистить. Если установлена утилита ncdu, то же самое удобнее делать в интерактивном режиме:
ncdu -x /Шаг 3. Очистите бэкапы и копии сайта
Классические «пожиратели» места — архивы резервных копий, которые копятся месяцами, и ручные копии каталога сайта вроде site_old или site_bak. Если они продублированы в другом месте и точно не понадобятся, удаляйте. Для содержимого каталога используйте команду с удалением файлов, не трогая сам каталог:
find /var/backups/old -type f -deleteПеред удалением всегда проверяйте путь: ошибка в одном символе может стоить вам рабочего сайта.
Шаг 4. Сбросьте кэш сайта и пакетного менеджера
Многие CMS хранят кэш в файлах, и со временем он разрастается до гигабайтов. Например, у сайтов на 1С-Битрикс это каталог bitrix/cache, у других систем — свои аналоги. Его содержимое можно безопасно удалить: сайт соберёт кэш заново, правда, первое время страницы будут открываться чуть медленнее.
find /var/www/shop/public_html/bitrix/cache -type f -deleteЗаодно очистите кэш установленных пакетов:
# Debian / Ubuntu
apt clean
# CentOS / AlmaLinux / Rocky
dnf clean allЕсли на сервере работает Docker, посмотрите, сколько места занимают остановленные контейнеры и неиспользуемые образы: docker system df. Очистку docker system prune запускайте только понимая, что именно она удалит.
Шаг 5. Разберитесь с логами
Ещё одна частая причина — раздувшиеся журналы. Они растут, когда записей слишком много, и системная ротация не успевает их архивировать и удалять. Сначала посмотрите, какие файлы самые крупные:
du -sh /var/log/* | sort -rh | headВажно: удалять лог-файл командой rm нельзя. Служба продолжает держать его открытым и писать «в пустоту», а место при этом не освобождается; в ряде случаев сама служба после такого удаления откажется запускаться. Правильный способ — очистить содержимое, оставив сам файл:
truncate -s 0 /var/log/nginx/shop.error.logЕсли крупных логов много, можно обнулить сразу все файлы больше 100 МБ:
find /var/log -type f -name "*.log" -size +100M -exec truncate -s 0 {} \;Системный журнал на серверах с systemd ограничивается отдельно:
journalctl --vacuum-size=200MЕсли место не освободилось
Бывает, что файл удалён, а df -h по-прежнему показывает 100%. Скорее всего, его всё ещё удерживает запущенный процесс. Найти такие файлы можно так:
lsof +L1Перезапустите службу, которая держит файл, — и пространство вернётся.
Как не допустить повторения
- Настройте ротацию логов (
logrotate) с разумным сроком хранения и сжатием старых файлов. - Подключите мониторинг с уведомлением, когда занято 80% диска: так у вас останется время подготовиться, а не тушить пожар.
- Храните резервные копии отдельно от рабочего сервера и ограничьте их количество.
- Периодически проверяйте каталоги с загрузками пользователей и временными файлами.
- Планируйте ресурсы заранее: если объём данных растёт стабильно, чистка лишь отсрочит проблему — стоит расширить диск.
Когда лучше обратиться к специалистам
Перечисленные шаги закрывают большинство типовых случаев, но бывают и нестандартные ситуации: нехватка inode, ошибки файловой системы, нетипичные источники роста данных или производственный сервер, на котором любая лишняя команда рискованна. В таких случаях разумнее доверить работу тем, кто делает это ежедневно.
Компания «Гианит» берёт на себя обслуживание компьютеров, серверов и сетей: настроим мониторинг и ротацию логов, наведём порядок с резервным копированием, а при необходимости проведём IT-аудит инфраструктуры и покажем слабые места до того, как они приведут к сбою. Позвоните нам по телефону +7 (4912) 51-09-15 или оставьте заявку на сайте.
Другие полезные материалы — в разделе «Статьи».
