На сервере закончилось место: что проверить до очистки

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

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

Не запускайте уборку, пока не определили границу сбоя

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

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

До изменений согласуйте, какие данные нельзя терять и где находится проверенная копия. Архив на том же заполненном разделе не является независимым местом восстановления. Попытка прямо сейчас собрать туда ещё один полный архив может усугубить нехватку места. Если копии нет, это нужно явно сообщить владельцу и выбрать способ сохранения важных данных на другом доступном хранилище, а не скрывать риск за словами «почистим кэш».

Место и количество файлов проверяются отдельно

В GNU/Linux команда `df -h /путь` показывает использование файловой системы, содержащей указанный путь. Для конкретного проекта полезнее проверить путь записи сайта, чем смотреть только корневой раздел. Команда `df -i /путь` проверяет использование inode. Это разные ограничения: большое количество маленьких файлов способно исчерпать доступные inode, хотя свободные байты ещё остаются. Условия конкретной файловой системы и ограничения провайдера нужно учитывать отдельно.

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

Найдите категорию роста, а не случайного виновника

GNU `du` оценивает занятое пространство по файлам и каталогам. Администратор может начать с ограниченного дерева проекта, затем изучить обнаруженный участок. Не запускайте тяжёлое сканирование всех дисков одновременно с аварийной нагрузкой без оценки последствий. Обход большого хранилища сам создаёт работу ввода-вывода. Нужен разумный порядок: нужный раздел, верхние каталоги, затем конкретная категория и её владелец.

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

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

Освобождение места согласуйте по категориям

Начинайте с данных, назначение и возможность повторного создания которых подтверждены. Для временного файла нужно знать, что его уже не использует текущая задача. Для результата сборки — какая версия работает и нужна ли предыдущая для отката. Для копии — какая политика хранения согласована и где остаётся пригодное восстановление. Универсальная команда удаления всех каталогов с названием cache не учитывает устройство конкретного проекта.

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

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

Рассчитайте запас, который нужен вашему процессу

Процент заполнения сам по себе не задаёт безопасный остаток. Учитывайте размер ближайшего ожидаемого действия: сборку, импорт, обновление базы или резервирование. В условном примере после уборки осталось 6 ГБ, а предстоящая операция временно создаёт до 8 ГБ новых данных на этом же разделе. Такой запас не подходит даже при спокойном среднем суточном росте. Числа вымышлены и показывают способ планирования, а не норматив для любого сайта.

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

Проверьте восстановление записи, а не только красивый график

1. Повторите измерение того же раздела и inode после согласованного изменения.
2. Убедитесь, что запас сохраняется, а подтверждённый источник неконтролируемого роста устранён.
3. Проверьте безопасную запись и чтение в затронутом сценарии приложения.
4. Изучите состояние очередей и фоновых заданий, остановившихся во время сбоя.
5. Подтвердите пригодность резервирования и назначьте ответственного за наблюдение.

Не считайте пропавшее сообщение об ошибке доказательством сохранности всех операций аварийного периода. Сверьте записи приложения и бизнес-системы в допустимом объёме. Если были неуспешные задания, повторный запуск должен учитывать защиту от дублей и фактический результат первой попытки. Это особенно важно для уведомлений, импорта и обработки заказов. График свободного диска отвечает на вопрос о ресурсе, а не о корректности каждого действия бизнеса.

В заявке на техническую поддержку передайте путь проблемного ресурса, симптомы, результаты измерений и уже выполненные изменения. Если запись рабочих данных остановилась, обратитесь за администрированием сервера с обозначением затронутого процесса. Хороший результат работы — объяснённая причина, восстановленный сценарий записи, согласованный запас и наблюдение. Удалённое количество гигабайт без этих подтверждений не является полноценной приёмкой.