Закончилось место на диске VPS

MAATRIX

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

Первым делом: находим виновника

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

df -h

Обратите внимание на столбец использования: раздел на 100% и есть источник проблем. Часто это корневой раздел, но иногда отдельно вынесенный раздел под данные или логи. Определив заполненный раздел, найдите внутри него самые тяжёлые каталоги, спускаясь от корня вглубь:

du -h --max-depth=1 / | sort -hr | head -20

Команда покажет двадцать самых объёмных каталогов верхнего уровня. Заходите в самый большой из них и повторяйте ту же команду уже внутри него, пока не доберётесь до конкретной папки или файла, съевшего место. Этот приём «спуска по дереву» за несколько шагов приводит к виновнику, будь то раздутый лог, забытый дамп базы или гора старых бэкапов. Пока вы не увидели реальную картину распределения места, любые удаления — это стрельба вслепую.

Быстро и безопасно освобождаем место

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

apt clean
journalctl --vacuum-size=200M

Вторая команда обрезает системный журнал до разумных 200 мегабайт — на серверах, работающих месяцами, journald нередко разрастается до гигабайтов. Если используете Docker, огромные объёмы часто съедают неиспользуемые образы, остановленные контейнеры и тома. Их безопасно убрать одной командой, которая удаляет только то, что уже не задействовано:

docker system prune -a

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

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

Ещё одна тонкость касается inodes — служебных записей файловой системы. Диск может показывать свободное место, но при этом отказываться создавать файлы, потому что закончились именно inodes: такое бывает, когда система забита огромным числом крошечных файлов, например мелкими сессиями или кэшем. Проверить это можно командой df -i, которая показывает использование inodes отдельно от объёма. Если заняты именно они, ищите каталог с миллионами мелких файлов — обычная проверка по размеру его не выявит, а причина недоступности записи будет ровно в этом.

Куда чаще всего утекает диск

Понимание типичных пожирателей места экономит время в следующий раз. Логи — виновник номер один: приложение в цикле пишет ошибку, и файл лога за сутки распухает до десятков гигабайт. Всегда проверяйте каталог с логами первым делом, особенно если проблема возникла внезапно после какого-то сбоя.

Второй по частоте источник — бэкапы, которые складываются на тот же диск и не удаляются. Копии копятся, пока не займут всё, поэтому резервные копии должны лежать на отдельном хранилище с автоматической ротацией, а не рядом с данными. Третий — Docker с его образами и слоями, четвёртый — временные файлы и загрузки, которые никто не убирает. Пятый, коварный, — удалённые файлы, которые всё ещё держит открытым работающий процесс: место при этом не освобождается, пока процесс не перезапустить. Знание этих пяти категорий превращает поиск в проверку короткого списка, а не в блуждание по всей файловой системе.

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

Освобождая место, легко навредить, поэтому запомните, чего не трогать. Не удаляйте системные каталоги и библиотеки, содержимое каталогов с конфигурацией и, тем более, файлы, назначение которых вам непонятно. Не чистите каталоги данных баз напрямую — удаление файлов базы через файловый менеджер почти гарантированно её сломает; лишние данные удаляют средствами самой СУБД.

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

Находим большие и старые файлы

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

find / -type f -size +500M -exec ls -lh {} \;

Так находятся забытые дампы баз, архивы, установочные образы и логи-переростки, о которых вы давно не помните. Отдельно стоит поискать старые файлы, которые уже не нужны, но занимают место, — например, записи или выгрузки старше нескольких месяцев. Разобравшись, что именно копится и почему, вы не только освободите диск сейчас, но и поймёте, какую профилактику настроить, чтобы проблема не вернулась через месяц.

Профилактика: чтобы не повторилось

Переполнение диска почти всегда предотвратимо. Первое и главное — настройте ротацию логов, чтобы файлы автоматически обрезались и старые удалялись, а не росли бесконечно. В большинстве систем для этого есть штатный механизм, его нужно лишь проверить и при необходимости ужесточить лимиты для «болтливых» приложений.

Второе — мониторинг свободного места с оповещением при заполнении выше порога, скажем, 80%. Предупреждение заранее превращает аварию в плановую уборку: вы реагируете, пока сервисы ещё работают, а не когда всё уже упало. Третье — держите бэкапы на отдельном хранилище, а не на рабочем диске, и настройте им ротацию. Четвёртое — регулярно чистите Docker и кэши, если активно ими пользуетесь. Эти привычки стоят пяти минут настройки и избавляют от ночных авралов с переполненным разделом.

Когда диска действительно мало

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

Здесь и стоит трезво оценить конфигурацию. Нормальный провайдер позволяет расширить диск или перейти на тариф побольше без переезда и долгого простоя. Заложить запас дешевле, чем регулярно тушить пожары: диск с комфортным свободным пространством работает стабильнее и не подводит в самый неподходящий момент. Если ваш нынешний хостинг не даёт удобно наращивать ресурсы, это повод присмотреться к провайдеру, у которого апгрейд — вопрос пары кликов.

Полезно также разделять данные по назначению. Держать операционную систему, базу данных, пользовательские загрузки и бэкапы на одном разделе удобно ровно до первого переполнения — потом любой распухший лог валит вообще всё. Разнесение по отдельным разделам или дискам локализует проблему: заполнившийся раздел с логами не мешает работать базе. Для нагруженных проектов это стандартная практика, которая превращает катастрофу в мелкую неприятность. И, конечно, копии данных должны жить не на том же сервере, а на отдельном хранилище — как организовать выделенный узел под бэкапы, разобрано в материале про VPS для бэкапов.

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