Чем занято место на диске в Linux и как его освободить

Место на диске всегда заканчивается не вовремя. Сервер перестаёт принимать файлы, база данных падает, apt upgrade ругается No space left on device, а на рабочем компьютере не сохраняется даже текстовый файл. В Windows в таком случае открывают «Очистку диска». В Linux её аналог — несколько команд в терминале, и они показывают картину точнее любого мастера.

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

Все команды проверены на Ubuntu 24.04, но работают и в Debian, и в Linux Mint. Там, где команда что-то удаляет, я отдельно пишу, насколько это безопасно.

Шаг 1. Какой раздел заполнен: df

Первая команда — df. Она показывает все смонтированные файловые системы: размер, сколько занято, сколько свободно.

df -h

Ключ -h (human-readable) переводит размеры в привычные K, M, G. Без него всё будет в килобайтных блоках.

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.2G  2.1M  3.2G   1% /run
/dev/nvme0n1p2  468G  401G   43G  91% /
tmpfs            16G     0   16G   0% /dev/shm
/dev/nvme0n1p1  1.1G  6.2M  1.1G   1% /boot/efi
/dev/sdb1       3.6T  2.9T  557G  85% /mnt/data

Как читать:

• Mounted on — куда подключён раздел. / — корень системы, всё остальное «висит» на нём, если не вынесено на отдельный раздел.
• Use% — процент заполнения. Выше 90% — пора разбираться, на 100% начинаются ошибки.
• Avail — сколько реально можно записать обычному пользователю.

Обратите внимание: Used + Avail меньше, чем Size. Это не ошибка. На ext4 около 5% места зарезервировано для root — об этом ниже, в отдельном разделе.

Строки tmpfs — это файловые системы в оперативной памяти, на диск они не влияют. На системах со snap ещё будет десяток строк /dev/loop… на 100%: это образы snap-пакетов, они всегда заполнены «под завязку», и так и должно быть. Чтобы скрыть лишнее, исключите эти типы и добавьте колонку с типом файловой системы:

df -hT -x tmpfs -x squashfs

Ключ -T выводит тип (ext4, btrfs, xfs), -x исключает указанный тип. Можно спросить и про один конкретный каталог — df -h /var покажет раздел, на котором он лежит.

Места много, а записать нельзя: иноды

Бывает странная ситуация: df -h показывает 40 ГБ свободного места, а система всё равно пишет No space left on device. Почти всегда дело в инодах.

Инод — это служебная запись о файле в файловой системе. На ext4 их число задаётся при создании раздела и потом не меняется. Если какая-то программа насоздавала миллионы крошечных файлов (сессии PHP, кэш почты, превью), иноды кончаются раньше места.

df -i /

Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/vda       16777216 309109 16468107    2% /

Смотрите на IUse%. Если там 100% — ищите каталог с огромным количеством файлов. В du для этого есть ключ --inodes: он считает не размер, а число файлов.

sudo du --inodes -x -d1 /var | sort -n | tail -5

Для наглядности я создал в тестовом каталоге 20 000 пустых файлов:

20001    /srv/demo/sessions
20003    /srv/demo

Места эти файлы почти не занимают, а инодов съели 20 тысяч. Дальше спускайтесь в найденный каталог той же командой, пока не найдёте виновника.

Шаг 2. Что занимает место: du

df говорит, какой раздел полон, но не говорит, чем. Для этого есть du (disk usage) — он обходит каталоги и суммирует размер файлов.

Размер каталогов в текущей папке

Самая полезная связка:

du -sh * | sort -h

• -s — показать итог по каждому аргументу, а не каждый подкаталог;
• -h — размеры в K/M/G;
• sort -h — сортировка, которая понимает такие размеры: самое большое окажется внизу, прямо над курсором.

4.0K    /var/mail
4.0K    /var/tmp
16K    /var/spool
1.2M    /var/log
4.6M    /var/cache
269M    /var/lib

Звёздочка * не захватывает скрытые файлы и каталоги, начинающиеся с точки. В домашней папке именно они чаще всего и толстые: .cache, .local, .steam. Для них используйте вариант ниже.

Обход по уровням: --max-depth и -x

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h

• --max-depth=1 (коротко -d1) — показывать только первый уровень вложенности, но считать всё целиком. Скрытые каталоги тоже попадают в список.
• -x — не переходить на другие файловые системы. Без этого ключа du / полезет в /proc, /sys, примонтированные сетевые папки и внешние диски, и цифры станут бессмысленными. С -x вы видите только то, что лежит на корневом разделе.
• 2>/dev/null — прячет ошибки «Permission denied» и «No such file», которых при обходе всей системы бывает много.

237M    /usr/libexec
657M    /usr/bin
1.1G    /usr/share
2.4G    /usr/lib
6.7G    /usr

Последняя строка — итог по самому каталогу. Дальше идёте «вниз»: нашли толстый каталог — запускаете ту же команду для него, и так до конкретного виновника.

Удобнее: ncdu

Набирать du раз за разом, спускаясь по каталогам, утомительно. ncdu делает то же самое, но один раз сканирует диск и даёт ходить по результату стрелками.

sudo apt install ncdu
sudo ncdu -x /

Ключ -x здесь значит то же, что и у du: оставаться на одной файловой системе. Через несколько секунд или минут появится список каталогов, отсортированный по размеру:

ncdu 1.19 ~ Use the arrow keys to navigate, press ? for help
--- / ---------------------------------------------------------------
   38.2 GiB [##########] /home
   12.4 GiB [###       ] /var
    6.7 GiB [#         ] /usr
    1.9 GiB [          ] /snap
  412.0 MiB [          ] /boot
   18.0 MiB [          ] /etc
 Total disk usage:  59.7 GiB  Apparent size:  58.9 GiB  Items: 612344

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

На сервере, где сканирование идёт долго, результат можно сохранить в файл и открыть позже: sudo ncdu -x -o /tmp/scan.ncdu /, а потом ncdu -f /tmp/scan.ncdu.

Поиск больших файлов: find -size

Иногда место съедает не каталог, а несколько огромных файлов, разбросанных по системе: забытый образ ISO, дамп базы, старый бэкап. Их удобно искать через find. Подробно эта команда разобрана в статье про поиск файлов в Linux, здесь — только про размер.

sudo find / -xdev -type f -size +500M -exec du -h {} + 2>/dev/null | sort -rh | head -20

• -xdev — то же, что -x у du: не уходить на другие разделы;
• -type f — только обычные файлы;
• -size +500M — больше 500 МБ. Можно +1G, +100M; минус вместо плюса ищет файлы меньше указанного;
• -exec du -h {} + — для найденных файлов показать размер;
• sort -rh | head -20 — двадцать самых больших сверху.

Я положил в тестовый каталог три файла и поискал всё, что больше 100 МБ:

1.2G    /srv/demo/video.mkv
601M    /srv/demo/backup.tar.gz
150M    /srv/demo/old/iso.img

Чтобы найти большие и при этом давно не нужные файлы, добавьте условие по дате изменения: -mtime +180 — не менялись больше полугода.

Безопасная очистка: с чего начать

Теперь, когда понятно, куда смотреть, — чистим. Сначала то, что можно удалить без раздумий.

Кэш пакетов apt

При каждой установке и обновлении apt скачивает .deb-файлы в /var/cache/apt/archives и хранит их там. За год обновлений набирается от сотен мегабайт до нескольких гигабайт.

du -sh /var/cache/apt/archives
sudo apt clean

apt clean удаляет все скачанные пакеты. Установленные программы при этом не трогаются, а если пакет понадобится снова, apt просто скачает его ещё раз. Команда ничего не выводит — это нормально. Есть и мягкий вариант sudo apt autoclean: он удаляет только те пакеты, которых уже нет в репозиториях.

Ненужные зависимости и старые ядра

sudo apt autoremove --purge

autoremove удаляет пакеты, которые ставились как зависимости, но больше никому не нужны. --purge заодно стирает их конфигурационные файлы. Самое весомое, что эта команда обычно убирает, — старые ядра: каждое вместе с модулями и заголовками занимает несколько сотен мегабайт.

The following packages will be REMOVED:
  linux-headers-6.8.0-45* linux-headers-6.8.0-45-generic*
  linux-image-6.8.0-45-generic* linux-modules-6.8.0-45-generic*
  linux-modules-extra-6.8.0-45-generic*
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
After this operation, 612 MB disk space will be freed.
Do you want to continue? [Y/n]

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

uname -r
dpkg --list 'linux-image-[0-9]*' | grep ^ii

Журналы systemd: journalctl

Системный журнал хранится в /var/log/journal и по умолчанию может вырасти до 10% раздела (но не больше 4 ГБ). На маленьком диске VPS это заметно. Подробно про журнал — в статье про systemd и journalctl.

Сколько он занимает:

journalctl --disk-usage

Archived and active journals take up 3.9G in the file system.

Почистить можно двумя способами — по размеру или по возрасту:

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=2weeks

Первая команда удаляет старые архивные файлы журнала, пока всё не уложится в 200 МБ. Вторая — удаляет записи старше двух недель. Принимаются суффиксы K, M, G для размера и d, weeks, months для времени.

Deleted archived journal /var/log/journal/3f2a…/system@…-000000000001a2b3.journal (128.0M).
Deleted archived journal /var/log/journal/3f2a…/system@…-000000000001c4d5.journal (128.0M).
…
Vacuuming done, freed 3.7G of archived journals from /var/log/journal/3f2a….

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

Чтобы журнал больше не разрастался, задайте постоянный лимит. Удобнее не править основной файл, а создать дополнительный:

sudo mkdir -p /etc/systemd/journald.conf.d
echo -e "[Journal]\nSystemMaxUse=300M" | sudo tee /etc/systemd/journald.conf.d/size.conf
sudo systemctl restart systemd-journald

Старые ревизии snap

Snap при каждом обновлении сохраняет предыдущие версии пакета, чтобы можно было откатиться. Неактивные ревизии каждого пакета остаются на диске, и на десктопе с Firefox, Chromium и парой сред выполнения это легко 3–5 ГБ. Про то, чем snap отличается от apt и flatpak, — в статье apt, snap, flatpak и AppImage.

Посмотреть, что занимает место:

du -sh /var/lib/snapd/snaps
snap list --all | awk '/disabled/{print $1, $3}'

Вторая команда показывает неактивные ревизии: имя пакета и номер ревизии.

core22 1612
firefox 4955
gnome-42-2204 176

Удалить их все одним заходом:

snap list --all | awk '/disabled/{print $1, $3}' |
  while read name rev; do
    sudo snap remove "$name" --revision="$rev"
  done

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

sudo snap set system refresh.retain=2

Кэш в домашней папке

В ~/.cache программы складывают то, что можно пересоздать: кэш браузеров, миниатюры картинок, скачанные пакеты pip и npm, шейдеры игр. Это безопасно удалять — в худшем случае программа один раз запустится медленнее.

du -sh ~/.cache
du -sh ~/.cache/* 2>/dev/null | sort -h | tail

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

rm -rf ~/.cache/thumbnails

Корзина

Файлы, удалённые в файловом менеджере, не исчезают, а переезжают в ~/.local/share/Trash. Проверить и очистить:

du -sh ~/.local/share/Trash
gio trash --empty

У внешних дисков и разделов своя корзина — скрытый каталог .Trash-1000 в корне диска (1000 — ваш UID). du и ncdu его покажут; удалять можно, как обычную папку.

Продвинутая очистка: осторожно

Docker

Если на машине работает Docker, он почти наверняка в лидерах по месту: образы, остановленные контейнеры, тома и кэш сборки лежат в /var/lib/docker. Сначала смотрим сводку:

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          14        5         6.8GB     4.1GB (60%)
Containers      7         5         212MB     38MB (17%)
Local Volumes   9         4         3.2GB     1.4GB (43%)
Build Cache     63        0         2.5GB     2.5GB

RECLAIMABLE — сколько можно освободить, не трогая то, что используется сейчас. Чистит всё это команда prune, и она честно предупреждает, что будет удалено:

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - unused build cache

Are you sure you want to continue? [y/N]

Разница между вариантами:

• docker system prune — остановленные контейнеры, неиспользуемые сети, «висячие» образы без тега и кэш сборки. Относительно безопасно.
• docker system prune -a — плюс все образы, у которых нет контейнера. Если вы остановили сервис через docker compose down, его образы тоже удалятся, и при следующем запуске их придётся скачивать заново.
• --volumes — плюс анонимные тома. Здесь можно потерять данные: в томах живут базы данных и настройки контейнеров.

Отдельная история — логи контейнеров. По умолчанию Docker пишет их в файлы *-json.log без ограничения размера. Проверить: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h. Лимит задаётся в /etc/docker/daemon.json параметрами "log-opts": {"max-size": "50m", "max-file": "3"} и действует для вновь созданных контейнеров.

Удалённые, но открытые файлы: lsof +L1

Классическая загадка: вы удалили гигантский лог, а df показывает, что места не прибавилось. Или df говорит «занято 95%», а du насчитывает в два раза меньше.

Причина в том, как Linux удаляет файлы. Команда rm убирает имя файла из каталога, но если файл в этот момент открыт каким-то процессом, данные остаются на диске, пока процесс его не закроет. du такой файл не видит — у него больше нет имени. А место он занимает.

Найти такие файлы:

sudo lsof +L1

+L1 означает «файлы, у которых меньше одной ссылки», то есть удалённые. Для примера я создал файл на 300 МБ, открыл его процессом sleep и удалил:

COMMAND    PID     USER   FD   TYPE DEVICE  SIZE/OFF NLINK   NODE NAME
sleep     1037     root    3r   REG  254,0 314572800     0 901187 /srv/demo/app.log (deleted)

Смотрите на SIZE/OFF — размер в байтах, NAME с пометкой (deleted) и COMMAND/PID — кто держит файл. В реальности это обычно nginx, база данных или сама программа, писавшая лог.

Как освободить место:

1. Перезапустить службу, которая держит файл: sudo systemctl restart nginx. Самый правильный способ.
2. Если перезапуск невозможен — обнулить файл через дескриптор процесса. Номер дескриптора — цифра в колонке FD (здесь 3):

sudo truncate -s 0 /proc/1037/fd/3

После этого lsof покажет для файла размер 0, и место вернётся. На будущее: большой лог, который ещё пишется, не удаляйте, а обнуляйте — sudo truncate -s 0 /var/log/имя.log.

Зарезервированные 5% на ext4

При создании раздела ext4 по умолчанию резервирует 5% блоков для root. Смысл в том, чтобы при переполненном диске системные службы и администратор могли продолжать работать. На системном разделе это полезно. А вот на диске на 4 ТБ под фильмы и бэкапы 5% — это 200 ГБ, которые просто простаивают.

Посмотреть резерв:

sudo tune2fs -l /dev/sdb1 | grep -E 'Block count|Reserved block count'

Block count:              976754176
Reserved block count:     48837708

Уменьшить до 1% (или до нуля — -m 0):

sudo tune2fs -m 1 /dev/sdb1

tune2fs 1.47.0 (5-Feb-2023)
Setting reserved blocks percentage to 1% (9767541 blocks)

Работает на смонтированном разделе, данные не трогает, применяется сразу. Имя раздела берите из df -h или lsblk. Для корневого раздела / резерв лучше оставить как есть. Про разметку дисков подробнее — в статье про ручную разметку диска в Ubuntu Server.

Логи в /var/log

Кроме журнала systemd, в /var/log пишут и обычные текстовые логи: syslog, auth.log, логи nginx, Apache, Samba. Их ротирует logrotate: раз в день или неделю старый лог сжимается в .gz, а самые старые удаляются.

sudo du -sh /var/log/* 2>/dev/null | sort -h | tail

Если там лежит лог на десятки гигабайт, это симптом: какая-то программа сыплет ошибками. Сначала откройте конец файла (sudo tail -n 50 /var/log/имя.log) и разберитесь с причиной, иначе через неделю всё повторится. Сам файл обнуляйте через truncate, а старые сжатые архивы *.gz и *.1 можно удалять.

Куда смотреть в первую очередь

Шпаргалка команд

Частые ошибки

rm -rf с переменной или пробелом. Команда rm -rf удаляет без вопросов и мимо корзины. Опечатка sudo rm -rf / var/log/old (лишний пробел после /) означает «удалить корень и ещё один каталог». А в скриптах rm -rf "$DIR"/* при пустой переменной превращается в rm -rf /*. Перед удалением всегда сначала выполните ls с тем же путём и посмотрите, что попадёт под удаление. Для разовой чистки удобнее rm -ri — он спросит про каждый файл.

Удаление логов, которые пишутся. rm /var/log/syslog не вернёт место, пока служба не перезапустится, — см. раздел про lsof +L1. Обнуляйте через truncate -s 0.

du без -x. Цифры для / получаются огромными, потому что в подсчёт попали внешние диски, сетевые папки и /proc. Добавляйте -x.

Чистка не того раздела. Если заполнен /mnt/data, чистить кэш apt бесполезно — он лежит на корневом разделе. Сначала df -h, потом действия.

Удаление /var/lib/… руками. Каталоги docker, snapd, mysql, postgresql, dpkg — это рабочие данные служб. Удалять их содержимое можно только средствами самих программ.

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

Чтобы не превратить уборку в переустановку системы, вот список того, что трогать не надо:

• ⛔ /bin, /sbin, /lib, /usr, /etc — сама система и её настройки;
• ⛔ /boot и ядро, совпадающее с uname -r, — без них система не загрузится;
• ⛔ /var/lib/dpkg и /var/lib/apt — база установленных пакетов, без неё apt сломается;
• ⛔ /var/lib/docker, /var/lib/snapd, /var/lib/mysql, /var/lib/postgresql — только через сами программы;
• ⛔ /proc, /sys, /dev, /run — виртуальные файловые системы, места на диске они не занимают;
• ⛔ /swap.img или /swapfile — файл подкачки. Если хочется его уменьшить, делайте это правильно, как описано в статье про swap в Ubuntu;
• ⛔ /lost+found — служебный каталог ext4, он почти пустой;
• ⛔ скрытые файлы в домашней папке, кроме ~/.cache: в ~/.config, ~/.local/share, ~/.ssh лежат настройки программ, ключи и данные.

Чек-лист

• 📊 Проверил df -h: понял, какой раздел заполнен.
• 🔢 Если места много, а ошибка есть, — проверил иноды через df -i.
• 🔍 Нашёл крупнейшие каталоги через du -xh -d1 или ncdu -rx.
• 📦 Выполнил sudo apt clean и sudo apt autoremove --purge, прочитав список.
• 📜 Ужал журнал systemd и задал ему постоянный лимит.
• 🧹 Удалил старые ревизии snap и кэш в ~/.cache.
• 👻 Проверил sudo lsof +L1, если df и du не сходятся.
• ⚠️ Перед каждым rm -rf проверил путь через ls.

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

Почему df и du показывают разное занятое место?

Самая частая причина — удалённые, но ещё открытые файлы: du их не видит, а место они занимают. Проверьте sudo lsof +L1. Ещё du не учитывает зарезервированные блоки ext4 и не заходит в каталоги, куда нет прав, если запущен без sudo.

Можно ли удалить всё из /tmp?

Лучше не делать этого вручную на работающей системе: там лежат сокеты и временные файлы запущенных программ. Ubuntu сама чистит /tmp при перезагрузке. Если места мало прямо сейчас — перезагрузитесь.

Безопасно ли удалять ~/.cache целиком?

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

Сколько места нужно оставлять свободным?

Для корневого раздела — не меньше 10–15%: обновлениям системы нужно место для скачивания и распаковки пакетов. Кроме того, на почти полном диске службы начинают падать с ошибками записи.

Как автоматически чистить место по расписанию?

Достаточно задать лимит журналу systemd и refresh.retain=2 для snap — дальше они следят за собой сами. Для своих задач, например удаления старых бэкапов через find … -mtime +30 -delete, используйте cron — нужную строку соберёт генератор cron.

Как быть с местом на диске на сервере Proxmox?

На хосте Proxmox работают те же команды: df -h, du, journalctl --vacuum-size. Дополнительно смотрите на старые бэкапы виртуальных машин и ISO-образы в хранилище local — подробнее о настройке в статье про Proxmox на мини-ПК.

Удалил файлы, но место не освободилось — что делать?

Проверьте три вещи: не в корзине ли они (~/.local/share/Trash), не держит ли их процесс (sudo lsof +L1) и тот ли раздел вы чистили (df -h). Если файлы удалялись на Samba-шаре с компьютера в сети, они могли попасть в корзину самого сервера Samba, если она включена.

Что лучше — ncdu или графическая программа?

На десктопе есть «Анализатор использования дисков» (baobab) с наглядной круговой диаграммой. Но ncdu работает везде, в том числе по SSH на сервере без графики, и запускается быстрее. Для серверов он стандарт.