Як безпечно очистити Linux-сервер без зупинки сервісів

Рівень: Середній (production-системи)
Орієнтовний час: ~30 хвилин
Мета: Звільнити місце на диску Linux-сервера шляхом видалення невикористовуваних пакетів, старих ядер, застарілих журналів та кешованих файлів – без зупинки жодного із запущених сервісів.

Цей посібник передбачає SSH-доступ до production або production-подібного VPS. Не виконуйте команди наосліп на критичних системах без знімків стану (snapshot).

Вступ

З часом навіть мало використовуваний VPS накопичує «мертвий вантаж»: осиротілі пакети, застарілі ядра, гігабайти неротованих журналів і залишки кешу пакетного менеджера. Якщо не контролювати це, переповнений диск завалить ваш веб-сервер, порушить запис у базу даних і заповнить чергу пошти. Цей посібник з очищення Linux-системи проведе вас через безпечне очищення Linux-сервера – спершу перевірте використання диска, видаліть лише те, що безпечно видаляти, і переконайтеся, що ваші сервіси пережили процес. Кожна команда тут є безпечною для запуску на живому сервері без простоїв.

Що буде очищено

Категорія	Приклади	Типова економія
Невикористовувані пакети та залежності	Осиротілі бібліотеки, замінені драйвери	100 МБ – 2 ГБ
Старі ядра	Попередні версії ядра	200 МБ на ядро
Кеш пакетів	Завантажені файли .deb / .rpm	500 МБ – 5 ГБ
Журнали journal	Архіви журналів systemd	100 МБ – 10 ГБ
Ротовані файли журналів	/var/log/*.gz, *.1	Змінюється

Передумови

Перш ніж почати, переконайтеся, що виконані такі умови:

• Операційна система: Ubuntu 24.04/26.04 LTS, Debian 13 або AlmaLinux 10
• Доступ: Права sudo або root до сервера через SSH
• Необхідні знання: Впевнене використання терміналу Linux та базова навігація в командному рядку
• Резервна копія: Завжди робіть знімок або резервну копію перед масовим видаленням пакетів на production-сервері. На INTROSERV ви можете замовити повну резервну копію безпосередньо з Клієнтської зони.

Не продовжуйте, якщо істинною є хоча б одна з наступних умов:

• Розділ / заповнений більш ніж на 95% – ваша система, можливо, вже зазнає збоїв запису. Спершу усуньте безпосередню причину (знайдіть і вручну видаліть один великий файл).
• Сервіси вже не працюють або поводяться неочікувано. Дослідіть першопричину перед очищенням, щоб не порушити роботу сервісів, від яких залежать Linux-системи.
• У вас немає резервної копії або знімка. Спершу створіть її – на INTROSERV це займає менше 2 хвилин із Клієнтської зони.

Крок 1: Перевірте використання диска перед початком

Рівень ризику: НИЗЬКИЙ – Тільки команди читання. Нічого не змінюється.

Ніколи не прибирайте наосліп. Спочатку зрозумійте, що насправді займає місце.

1.1 Перевірте загальне використання диска

Запустіть df, щоб перевірити використання диска на рівні файлової системи:

df -h

Очікуваний вивід:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   34G  3.8G  90% /
tmpfs           1.0G     0  1.0G   0% /dev/shm

Розділ / вище 80% використання – тривожний сигнал. Вище 95% – сервіси почнуть давати збої.

1.2 Знайдіть найбільших споживачів простору

Використовуйте du, щоб заглибитися в каталоги. Починайте з кореня і рухайтеся вниз:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Це показує 20 найбільших каталогів під /. Типові винуватці: /var/log, /var/cache, /usr та /home.

Звузьте пошук далі:

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 Перевірте використання inode

Місце на диску – не єдине обмеження. Inode відстежують кількість файлів. Розділ може мати вільне місце, але вичерпати inode, що також призведе до збоїв запису.

df -i

Очікуваний вивід:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 210543 2410897    9% /

Якщо IUse% вище 80%, швидше за все, є каталог із десятками тисяч дрібних файлів – часто черга пошти, каталог сесій або кеш PHP. Використовуйте du --inodes, щоб знайти його:

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Крок 2: Видалення невикористовуваних пакетів і залежностей

Рівень ризику: СЕРЕДНІЙ – Видалення пакетів є оборотним через історію пакетного менеджера, але перегляньте список перед підтвердженням.

Невикористовувані пакети – найбезпечніше, що можна очистити. Вони займають місце на диску, не обслуговуючи жодний запущений процес, а в деяких випадках містять незакриті CVE.

2.1 Ubuntu / Debian – apt autoremove

apt autoremove видаляє пакети, які були встановлені як залежності, але більше нікому не потрібні:

sudo apt autoremove --purge -y

Прапор --purge також видаляє залишкові конфігураційні файли. Без нього двійковий файл пакету видаляється, але конфігураційні файли залишаються на місці.

Очікуваний вивід:

The following packages will be REMOVED:
  libfoo1 libbar2 old-driver-utils ...
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

2.2 AlmaLinux / RHEL – dnf autoremove

sudo dnf autoremove -y

На старіших системах RHEL 7 / CentOS 7 використовуйте yum autoremove:

sudo yum autoremove -y

2.3 Очищення кешу пакетів

Після оновлень та встановлень пакетні менеджери зберігають завантажені архівні файли локально. Їх безпечно видаляти після завершення встановлення.

Ubuntu / Debian:

sudo apt clean

Це видаляє всі кешовані файли .deb з /var/cache/apt/archives/. Щоб видалити лише пакети, яких більше немає в репозиторії (застарілі версії):

sudo apt autoclean

AlmaLinux / RHEL:

sudo dnf clean all

Очікуваний вивід:

16 files removed

Крок 3: Видалення старих ядер

Рівень ризику: ВИСОКИЙ – Видалення неправильного ядра зробить сервер незавантажуваним після наступного перезавантаження. Завжди перевіряйте uname -r перед продовженням.

Кожне оновлення ядра залишає попередню версію на місці як страховку. Після підтвердження стабільності сервера на новому ядрі старі ядра безпечно видалити – кожне, як правило, звільняє 200–400 МБ.

3.1 Перевірте, яке ядро запущено

Ніколи не видаляйте ядро, у яке ви завантажилися:

uname -r

Очікуваний вивід:

5.15.0-105-generic

3.2 Перегляньте всі встановлені ядра

Ubuntu / Debian:

dpkg -l | grep linux-image | awk '{print $2}'

Очікуваний вивід:

linux-image-5.15.0-100-generic
linux-image-5.15.0-105-generic
linux-image-generic

Мета-пакет не можна видаляти – він відстежує поточне рекомендоване ядро:

• Ubuntu: linux-image-generic
• Debian: linux-image-amd64
• AlmaLinux: Мета-пакет не використовується, натомість застосовується installonly_limit у dnf.

Видаляйте лише конкретні версіоновані пакети, які не є вашим поточним ядром.

AlmaLinux / RHEL:

rpm -q kernel

Очікуваний вивід:

kernel-5.14.0-284.11.1.el9_2.x86_64
kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Видалення старих ядер

Ubuntu / Debian – автоматичний метод:

apt autoremove з Кроку 2 вже обробляє старі ядра в Ubuntu, якщо встановлено linux-image-generic. Ви також можете вказати їх явно. Замініть версію на ту, яку хочете видалити (не поточну):

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL:

Пакетний менеджер dnf зберігає налаштовувану кількість старих ядер. Встановіть ліміт у /etc/dnf/dnf.conf:

sudo nano /etc/dnf/dnf.conf

Додайте або оновіть рядок:

installonly_limit=2

Потім запустіть:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Це видаляє всі ядра, крім двох найновіших.

Крок 4: Очищення журналів journal

Рівень ризику: НИЗЬКИЙ – Видаляються лише архівні записи журналу. Запущені сервіси не зачіпаються.

systemd-journald збирає журнали від кожного сервісу в системі. За замовчуванням він може рости без обмежень, поки не досягне ліміту диска – або поки вільне місце на диску не досягне нуля.

4.1 Перевірте поточний розмір журналу

journalctl --disk-usage

Очікуваний вивід:

Archived and active journals take up 2.3G in the filesystem.

4.2 Обрізання журналу

Щоб зберегти лише журнали за останні 7 днів:

sudo journalctl --vacuum-time=7d

Щоб зберегти лише останні 500 МБ:

sudo journalctl --vacuum-size=500M

Очікуваний вивід:

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Запобігання майбутньому зростанню журналу

Створіть файл конфігурації drop-in, щоб постійно обмежити розмір журналу (на AlmaLinux 10 основний конфігураційний файл за замовчуванням відсутній у /etc/, тому це стандартний підхід):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Застосуйте зміни:

sudo systemctl restart systemd-journald

Крок 5: Очищення ротованих і старих файлів журналів

Рівень ризику: СЕРЕДНІЙ – Видаляються лише стиснуті архіви. Не чіпайте файли без розширення .gz або числового суфіксу.

Журнали додатків у /var/log/ керуються logrotate. Зазвичай logrotate зберігає встановлену кількість ротованих копій і автоматично стискає їх. Якщо logrotate був неправильно налаштований або не запускався, ви можете знайти великі накопичення файлів .gz, .1, .2.

5.1 Знайдіть великі файли журналів

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

Або простіше:

sudo du -h /var/log | sort -rh | head -20

5.2 Видалення старих стиснутих архівів журналів

Стиснуті ротовані журнали (.gz) безпечно видаляти. Це архіви вже закритих файлів журналів.

Спочатку перегляньте, що буде видалено – запустіть без -delete, щоб побачити список:

sudo find /var/log -name "*.gz" -mtime +30

Якщо вивід виглядає правильно, виконайте фактичне видалення:

sudo find /var/log -name "*.gz" -mtime +30 -delete

Це видаляє архіви журналів .gz старші за 30 днів.

5.3 Перевірте правильність налаштування logrotate

Перевірте, які сервіси мають конфігурації logrotate:

ls /etc/logrotate.d/

Запустіть logrotate вручну в режимі налагодження, щоб переконатися, що він працює без помилок:

sudo logrotate -d /etc/logrotate.conf

Прапор -d – це пробний запуск: нічого не змінюється, але ви побачите, що саме відбулося б. Якщо сервіс відсутній у /etc/logrotate.d/, створіть для нього конфігурацію. Дивіться посібник з ротації журналів для повних інструкцій з налаштування logrotate.

Крок 6: Очищення тимчасових файлів

Рівень ризику: СЕРЕДНІЙ – PHP-сесії та кеші додатків впливають на живих користувачів. Перегляньте перед видаленням.

6.1 Очищення /tmp

/tmp очищується при перезавантаженні на більшості дистрибутивів. Якщо ваш сервер працює вже місяцями, там можуть накопичитися великі тимчасові файли:

du -sh /tmp

Щоб видалити файли старші за 7 днів, спочатку перегляньте список:

sudo find /tmp -type f -mtime +7

Якщо список виглядає безпечним, виконайте видалення:

sudo find /tmp -type f -mtime +7 -delete

6.2 Очищення кешів додатків

Багато додатків записують власні кеші. Перевірте ці поширені розташування (зверніть увагу: переконайтеся, що ці каталоги існують у вашій системі; на чистій системі вони можуть бути відсутні, і ви побачите помилку «No such file or directory»):

# PHP-файли сесій (часто забуваються, якщо встановлено)
sudo du -sh /var/lib/php/sessions/

# Кеші pip / Python (якщо запущено від root та встановлено)
sudo du -sh /root/.cache/pip/

# Кеш npm (якщо node встановлено на рівні системи)
sudo du -sh /root/.npm/

Ці каталоги безпечно очищати, якщо додаток активно їх не використовує.

Крок 7: Перевірка роботи сервісів

Рівень ризику: НИЗЬКИЙ – Перевірка тільки для читання. Запускайте після кожного кроку, а не лише в кінці.

Після кожного проходу очищення переконайтеся, що ваші сервіси пережили його. Робіть це перед закриттям SSH-сесії.

7.1 Перевірте статус критичних сервісів

Перевіряйте лише ті сервіси, які фактично встановлені на вашому сервері (на чистій системі перевірка nginx або mysql поверне Unit not found).

Ubuntu / Debian:

systemctl status nginx
systemctl status mysql
systemctl status ssh

AlmaLinux / RHEL:

systemctl status nginx
systemctl status mysqld
systemctl status sshd

Кожен має показувати Active: active (running). Якщо будь-який показує failed або inactive, перевірте його журнали:

journalctl -u nginx --since "10 minutes ago"

7.2 Підтвердьте покращення використання диска

df -h

Порівняйте стовпець Use% з тим, що ви бачили в Кроці 1. Зміна повинна відображати звільнений простір.

7.3 Протестуйте ваш додаток

Якщо ви запускаєте веб-сервер, надішліть тестовий запит:

curl -I http://localhost

Очікуваний вивід:

HTTP/1.1 200 OK
Server: nginx/1.24.0

Відповідь 200 OK підтверджує, що nginx нормально обслуговує трафік.

Усунення несправностей

`df` не показує покращення після видалення пакетів

Видалення пакетів звільняє місце негайно. Якщо df не змінюється, файли все ще відкриті. Знайдіть відкриті, але видалені файли:

sudo lsof | grep deleted

Перезапустіть сервіс, який тримає файл відкритим, і місце буде звільнено.

`apt autoremove` хоче видалити щось важливе

Уважно прочитайте список. Якщо ви бачите назву пакета, який є залежністю запущеного сервісу, натисніть N і розберіться. Запустіть apt-cache rdepends <package>, щоб побачити, що від нього залежить.

`journalctl --vacuum-time` не дає жодного результату

Журнал уже може бути меншим за цільовий розмір. Перевірте за допомогою journalctl --disk-usage. Також переконайтеся, що журнал є постійним: перевірте наявність /var/log/journal/. Якщо існує лише /run/log/journal/, журнал зберігається в RAM і автоматично очищається при перезавантаженні.

Сервіс не працює після `apt autoremove`

Запустіть systemctl status <service> і перевірте помилку. Якщо було видалено спільну бібліотеку, перевстановіть пакет, що її надає:

sudo apt install --fix-broken

Закінчуються inode незважаючи на вільне місце на диску

Знайдіть каталог з найбільшою кількістю файлів:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Типові винуватці: черги пошти у /var/spool/mail, PHP-сесії у /var/lib/php/sessions або задача cron, що некероване створює тимчасові файли.

Відкат

Більшість операцій очищення незворотні – видалені файли зникають. Це робить крок резервного копіювання в розділі «Передумови» обов'язковим, а не опціональним.

Для видалення пакетів зокрема ви можете перевстановити видалене:

Ubuntu / Debian:

sudo apt install <package-name>

AlmaLinux / RHEL:

sudo dnf install <package-name>

Щоб переглянути історію того, що було видалено в поточній сесії:

Ubuntu / Debian:

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL:

sudo dnf history list
sudo dnf history undo last

dnf history undo last перевстановлює пакети, видалені в останній транзакції – корисний інструмент відновлення, якщо autoremove зайшов далі, ніж передбачалося.

Висновок

Очищення Linux-сервера без простоїв зводиться до трьох речей: спочатку виміряйте, видаляйте лише те, що система підтверджує як невикористовуване, і перевіряйте сервіси після кожного кроку. Запустіть df -h і du, перш ніж щось чіпати. Використовуйте apt autoremove / yum autoremove для невикористовуваних пакетів, journalctl --vacuum-time для очищення журналів journal і find /var/log -name "*.gz" для старих ротованих архівів. Видаляйте старі ядра лише після підтвердження, що uname -r відповідає тому, що ви залишаєте. І завжди перевіряйте systemctl status перед закриттям термінала.

Для VPS на INTROSERV підтримання використання / нижче 80% є практичною метою – це залишає місце для сплесків журналів і оновлень пакетів без аварійного втручання. Якщо місце на диску є постійною проблемою, розгляньте можливість збільшення сховища VPS безпосередньо з Клієнтської зони INTROSERV.

Версія документа: 1.0
Останнє оновлення: Травень 2026
Власник: Команда технічної документації