DevOps
VPS
Docker
Мониторинг

На VPS закончился диск: как безопасно проверить Docker, логи и бэкапы

Порядок расследования заполненного диска без удаления нужных томов: диагностика, выбор безопасной очистки и проверка сайта после инцидента.

Команда Yabeard
6 мин

Сначала сохранить возможность расследования

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

Зафиксируйте время, затронутые сервисы и последние изменения. Приостановите необязательные сборки, экспорт и другие подтверждённые источники роста. Не перезапускайте сразу весь сервер: это прервёт диагностику и может усложнить запуск сервисов без свободного места. Команды ниже предназначены для Linux-сервера через SSH, а не для локального PowerShell.

Отделите занятые байты от исчерпанных inode

Начните с df -h и df -i. Первая проверка показывает использование пространства файловых систем, вторая помогает обнаружить исчерпание inode, то есть ресурса учёта файлов. Миллионы маленьких файлов могут остановить запись, даже если свободные гигабайты ещё видны. Уточните точку монтирования каталога приложения: свободное место на соседнем диске не помогает заполненному разделу.

Затем изучайте каталоги по уровням, например с помощью du -xhd1 /var на GNU/Linux. Ограничение одной файловой системой помогает не смешивать разные диски. На нагруженном сервере такой обход тоже создаёт нагрузку, поэтому не запускайте несколько полных сканирований одновременно. Если показания расходятся, проверьте права обхода, точки монтирования и удалённые файлы, которые процессы ещё держат открытыми.

Docker: размер не говорит о ценности данных

Получите сводку docker system df -v, затем сопоставьте контейнеры с их томами и bind-монтированиями. Документация docker system df описывает подробный вывод, включая общий и уникальный размер образов. Эта сводка не заменяет обследование диска: отдельно учитывайте журналы, каталоги приложения и резервные копии вне управляемых Docker объектов.

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

В руководстве Docker по prune перечислены объекты, удаляемые разными командами. Обычный system prune не удаляет тома по умолчанию, но удаляет остановленные контейнеры; дополнительные флаги расширяют область очистки. Поэтому не начинайте расследование с копирования команды «очистить всё». Даже кэш удаляйте осознанно: следующая сборка потребует времени, сети и снова свободного места.

Логи и резервные копии проверяйте отдельно

Уточните драйвер журналирования каждого контейнера. Для json-file проверьте ограничения размера и количества файлов. Документация драйвера json-file предупреждает против внешнего редактирования его файлов и указывает, что новые настройки по умолчанию не меняют уже созданные контейнеры автоматически. Ротацию нужно внедрить с контролируемым пересозданием затронутых контейнеров и проверкой сохранности их данных.

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

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

Чек-лист безопасного освобождения места

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

Типичные ошибки и критерии приёмки

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

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

Регулярный контроль входит в сопровождение инфраструктуры. Для предотвращения повторения полезно отдельно пересмотреть разделение окружений и организацию CI/CD: временные сборки не должны бесконтрольно конкурировать с рабочими данными.

Короткий FAQ

Можно ли удалить самый большой файл?

Только после определения его назначения и последствий. Размер не отличает ненужный кэш от базы или единственной копии загрузок пользователей.

Почему после удаления место не освободилось?

Один из вариантов: файл остаётся открытым процессом. Найдите владельца и согласуйте штатное закрытие или перезапуск конкретного сервиса, не всего сервера.

Сколько места нужно держать свободным?

Столько, чтобы выдержать обычный рост и обслуживающие операции до реакции команды. Это рассчитывают по наблюдениям, размеру обновлений и резервных копий, а не универсальному числу.

Поможем применить на практике

DevOps и сопровождение серверов

Нужна помощь с проектом?

Обсудим вашу задачу и предложим оптимальное решение.