Как безопасно очистить 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
Владелец: Команда технической документации