Стаття також доступна російською (перейти до перегляду).

Зміст:

• Перевірити вільне місце Ubuntu: df -h
• Перевірка inode: df -i
• Як знайти каталог, який займає найбільше місце
• Пошук великих файлів Linux
• Типові каталоги, що займають місце
• Очищення логів Ubuntu через journalctl
• Очищення кешу APT: apt clean і autoremove
• Великі файли логів і truncate
• Команда df і du різниця: чому показники не збігаються
• Що не можна видаляти вручну
• Що робити після очищення
• Коли потрібно розширення диска, а не очищення
• Чекліст діагностики заповненого диска VPS

Заповнений диск може порушити роботу всього VPS: сайт перестає створювати кеш і завантажувати файли, база даних не може записувати нові дані, а системні служби завершуються з помилкою No space left on device.

У такій ситуації важливо не поспішати з видаленням файлів. Спочатку потрібно визначити, яка файлова система заповнена, знайти каталоги та файли, що займають найбільше місця, і лише після цього обрати безпечний спосіб очищення.

У статті покроково розглянемо, як перевірити використання диска в Ubuntu, знайти причину нестачі місця та звільнити його без ризику пошкодити систему або дані. Приклади наведені для Ubuntu Server 26.04 LTS на VPS.

Заповнений диск VPS впливає на весь сервер одразу:

• сайт не може створити кеш або прийняти файл;

• база даних не записує нові дані;

• системні служби не стартують після перезапуску;

• оновлення пакетів переривається на середині;

• журнали systemd перестають писати записи;

• у логах з'являється no space left on device ubuntu.

Головне правило перед тим, як звільнити місце на VPS: не видаляти нічого просто так. Спочатку діагностика диска Ubuntu, потім рішення.

Перевірити вільне місце Ubuntu: df -h

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

df -h

Ключові колонки виводу:

• Filesystem — файлова система;

• Size — розмір розділу;

• Used — зайнято;

• Avail — доступно;

• Use% — відсоток використання;

• Mounted on — точка монтування.

Корисно додати тип файлової системи через -T:

df -hT

SSH-термінал: df -h, df -hT та df -i на реальному сервері.

На тестовому сервері коренева файлова система /dev/vda2 займає 24 ГБ, зайнято 22 ГБ, вільно лише 1,5 ГБ — 94%. Це критична позначка: запасу майже немає для журналів, тимчасових файлів чи оновлень. Якщо заповнена лише точка монтування /var, шукати причину в /home сенсу немає — перевіряйте саме ту файлову систему, де Use% близький до 100%.

Перевірка inode: df -i

Іноді df -h показує вільні гігабайти, а система відмовляється створювати нові файли з помилкою no space left on device ubuntu. Причина — закінчились inode, індексні дескриптори файлової системи. df -i inodes показує їхній стан:

df -i

Кожен файл чи каталог використовує один inode незалежно від розміру. Нестача inode виникає через величезну кількість дрібних файлів: сесії PHP, кеш застосунку, тимчасові файли. На перевіреному сервері зайнято лише 14% inode при 94% зайнятого місця — проблема саме в обсязі даних. Детальніше — в матеріалі про inode в Linux.

Як знайти каталог, який займає найбільше місце

Це центральна частина діагностики диска Ubuntu — звуження пошуку від кореня файлової системи до конкретного каталогу.

du -xhd1 / 2>/dev/null | sort -h

-x забороняє переходити на інші файлові системи, -h виводить зручні одиниці, -d1 обмежує глибину першим рівнем, 2>/dev/null ховає помилки доступу, а sort -h сортує за розміром.

SSH-термінал: du -xhd1 / і аналіз найбільшого каталогу /root.

На скріншоті видно типову картину: системні каталоги /usr (6,0 ГБ) і /var (3,2 ГБ), а поруч — /root на 5,4 ГБ. Алгоритм простий:

1. перевірити корінь файлової системи командою вище;

2. знайти найбільший каталог, який реально можна чистити;

3. повторити du -xhd1 вже всередині нього;

4. заглиблюватися далі, поки не знайдете конкретні файли або підкаталоги — джерело проблеми.

du -xhd1 /root 2>/dev/null | sort -h

Заглиблення показало: більшу частину /root займають кешовані дані — .cache (1,4 ГБ), .local (2,5 ГБ), .npm (571 МБ). Такі каталоги безпечно чистити, на відміну від системних шляхів у /var/lib нижче.

Пошук великих файлів Linux

Коли обхід за каталогами не дає точної відповіді, допоможе прямий пошук великих файлів Linux за розміром:

find / -xdev -type f -size +500M -ls 2>/dev/null

-xdev обмежує пошук однією файловою системою, -type f шукає лише звичайні файли, а -size +500M задає мінімальний поріг. Альтернативний варіант із сортуванням:

find / -xdev -type f -printf '%s %p\n' 2>/dev/null | sort -n | tail -20

SSH-термінал: файли понад 500 МБ, розмір журналу через journalctl --disk-usage та du для конкретних логів.

На сервері знайшовся файл підкачки /swap.img на 2 ГБ і кілька шарів образів контейнерів по 998 МБ. Великий файл — не автоматично сміття: файл підкачки не можна видаляти без вимкнення swap, а образ контейнера може бути активним шаром запущеного сервісу.

Типові каталоги, що займають місце

Заповнений диск VPS рідко буває одним великим файлом — частіше це кілька типових джерел, які накопичуються паралельно. Куди варто заглядати системно:

/var/log

Системні та прикладні журнали. Часто найшвидше зростає без ротації — на перевіреному сервері тут 681 МБ, з яких основну частку тримає журнал systemd.

/var/lib/mysql

Файли баз даних MySQL або MariaDB. Видаляти вручну не можна — це пошкодить базу даних.

/var/cache/apt

Кеш завантажених .deb-пакетів пакетного менеджера APT.

/var/lib/snapd

Пакети Snap та старі ревізії застосунків, які залишаються після оновлень.

/tmp і /var/tmp

Тимчасові файли застосунків. Не варто видаляти все без перевірки — деякі служби тримають там робочі файли.

/home

Файли користувачів, вивантаження, резервні копії та архіви після одноразової міграції.

Каталоги сайтів

Завантажені медіафайли, кеш CMS, резервні копії та логи застосунку — типове джерело росту на хостингу.

/var/lib/docker

Docker може непомітно зайняти значну частину диска своїми образами. Детальний розбір читайте у матеріалі про те, як видалити Docker images, контейнери та volumes.

Очищення логів Ubuntu через journalctl

Journalctl і systemd ведуть бінарний журнал системи, який без обмежень може зайняти сотні мегабайтів. Спочатку перевірте фактичний розмір:

journalctl --disk-usage

На перевіреному сервері архівні та активні журнали зайняли 493,7 МБ — і це підтверджує окрема перевірка каталогу:

du -sh /var/log/journal

Безпечне очищення логів Ubuntu виконується двома способами, залежно від того, що важливіше — час чи обсяг:

journalctl --vacuum-time=7d
journalctl --vacuum-size=500M

--vacuum-time видаляє записи, старші за вказаний період, а --vacuum-size зменшує обсяг журналу до заданого ліміту. Файли journalctl вручну видаляти не варто — команди вище роблять це коректно. Для аналізу вмісту журналів — матеріал про те, як розбирати логи в Linux через journalctl, grep, awk і sed, а для ротації текстових логів — стаття про logrotate в Ubuntu.

Очищення кешу APT: apt clean і autoremove

Пакетний менеджер APT теж накопичує кеш. Після оновлень безпечно виконати:

apt clean

Команда видаляє лише локально завантажені .deb-файли з кешу — самі встановлені пакети не зачіпає. Другий крок — перевірити пакети, що більше не потрібні як залежності:

apt-get -s autoremove

Прапорець -s означає симуляцію: команда лише показує, що буде видалено, без реальних змін.

SSH-термінал: lsof +L1, симуляція apt-get -s autoremove і повторний df -h.

На сервері симуляція показала два кандидати — libfwupd2 і libgusb2. Перш ніж запускати без -s, прочитайте список: іноді APT пропонує прибрати пакет, потрібний іншому сервісу.

Великі файли логів і truncate

Якщо du або find вказали на текстовий лог, який розрісся через помилку застосунку, видаляти його командою rm небезпечно: процес продовжить писати у видалений дескриптор, а місце не звільниться (докладніше — нижче). Натомість можна безпечно обнулити вміст файлу без розриву дескриптора:

truncate -s 0 /path/to/file.log

Перед цим варто визначити, яка служба веде журнал, і перевірити ротацію. truncate -s 0 — не універсальний перший крок, а точкове рішення: дані видаляються без можливості відновлення.

Команда df і du різниця: чому показники не збігаються

Типова ситуація: файл видалили, а df -h досі показує диск заповненим. Команда df і du різниця пояснюється просто — du рахує файли, видимі у файловій системі, а df бачить реальні зайняті блоки диска. Якщо процес тримає видалений файл відкритим, місце не звільняється. Перевірити це можна командою:

lsof +L1

На перевіреному сервері вона одразу показала приклад: mariadbd тримає кілька видалених тимчасових файлів у /tmp, а php-fpm — видалений opcache_lock. Це нормальна робота служб. Файл уже не в каталозі, du його не враховує, але місце зайняте, доки процес не звільнить дескриптор. Правильне рішення — перезапустити конкретну службу, а не весь сервер:

systemctl restart service-name

Серед інших причин розбіжності — зарезервовані блоки файлової системи для root та файли, приховані під точкою монтування.

Що не можна видаляти вручну

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

• файли з /var/lib/mysql — база даних MySQL або MariaDB;

• будь-який вміст /var/lib без розуміння, якій службі він належить;

• файли в /boot, включно з образами ядра;

• активне ядро Linux, яке зараз завантажене;

• невідомі файли баз даних поза стандартними каталогами;

• каталоги системних служб у /var/lib/<service>;

• Docker volumes з даними контейнерів;

• файли сайтів і резервні копії без підтвердженого дубліката;

• журнали, якщо невідомо, яка програма їх веде.

Якщо незрозуміло, для чого потрібен файл чи каталог, не видаляйте його лише через великий розмір.

Що робити після очищення

Після кроку очищення поверніться до базової перевірки:

df -h
du -xhd1 / 2>/dev/null | sort -h
systemctl --failed

systemctl --failed покаже служби, які не запустилися. Обов'язково відкрийте сайт, перевірте базу даних, PHP-FPM та інші критичні процеси — очищення диска не повинно стати причиною нової проблеми.

Коли потрібно розширення диска, а не очищення

Іноді діагностика диска Ubuntu показує, що звільняти вже нічого: усі великі каталоги — потрібні дані, і стандартні способи, як звільнити місце на VPS, вичерпані. Ознаки, що пора не чистити, а збільшувати:

• основне місце займають дані, реально потрібні бізнесу;

• база даних або каталог сайту постійно зростають;

• резервні копії мають зберігатися саме на сервері;

• після очищення диск знову заповнюється за лічені дні;

• вільного місця вже не вистачає навіть для оновлень.

У такому разі логічний крок — розширення диска: змінити тарифний план VPS на конфігурацію з більшим сховищем, а не стискати активні дані до нескінченності. Якщо після збільшення тарифу операційна система не бачить новий обсяг, знадобиться підготувати розділ — детальний покроковий алгоритм у статті про розширення диска в Linux.

Чекліст діагностики заповненого диска VPS

Компактна послідовність команд для повторної діагностики без пояснень:

df -h
df -i
du -xhd1 / 2>/dev/null | sort -h
find / -xdev -type f -size +500M -ls 2>/dev/null
journalctl --disk-usage
lsof +L1

Це чекліст діагностики, а не готовий алгоритм, як звільнити місце на VPS автоматично. Лише після повної картини варто видаляти, обнуляти логи чи запускати apt autoremove насправді.

На Ubuntu Server 26.04 LTS і попередніх LTS-версіях підхід до діагностики однаковий: раз на кілька тижнів запустіть df -h і df -i самостійно, не чекаючи, поки no space left on device ubuntu з'явиться в логах сайту.

Дата: 12.08.2026 Автор: Ілля Піговіч #docker#linux#ssh#ubuntu

Голосування 1 2 3 4 5