История одного переполненного диска

Авария с формулировкой «кончилось место на диске» — одна из самых обидных. Ничего не сломалось, никто не атаковал, оборудование исправно. Просто в какой-то момент запись перестала проходить, и проект встал. Обиднее всего то, что предупреждение было доступно за несколько недель до события — его просто некому было увидеть.

Как это выглядит со стороны

Симптомы почти никогда не указывают на диск напрямую. Обычно происходит что-нибудь из этого списка:

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

В результате первые двадцать минут уходят на поиск несуществующей проблемы в коде. Потом кто-нибудь смотрит на свободное место — и всё становится понятно.

Что обычно съедает место

  • Логи. Главный подозреваемый. Особенно если где-то включили подробный режим отладки и забыли выключить: такой журнал растёт гигабайтами в сутки.
  • Резервные копии на том же сервере. Плагин делает копию ежедневно, старые не удаляет. Через полгода это десятки архивов, каждый размером с сам проект.
  • Кэш и временные файлы. Кэш страниц, сгенерированные превью картинок, сессии, недогруженные файлы.
  • Сама база данных. Особенно таблицы логов, статистики и очередей задач: они растут тихо и сами по себе не чистятся.
  • Загруженные пользователями файлы. Растут медленно, но никогда не уменьшаются.
  • Старые версии пакетов и ядер. После года обновлений набегает прилично.

Почему это опаснее обычной аварии

Данные могут повредиться. База, которой не хватило места посреди записи, иногда остаётся в несогласованном состоянии. Это уже не «перезапустить и работать дальше».

Резервная копия тоже не создастся. Ровно в тот момент, когда она особенно нужна: места-то нет.

Перезагрузка не помогает. Обычный первый рефлекс здесь бесполезен, а иногда и вреден — система может не подняться нормально, потому что при старте ей тоже нужно куда-то писать.

Как быстро найти виновника

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

Освобождать место стоит осмысленно. Удалить старые архивы и разросшиеся логи — нормально. Чистить наугад системные каталоги, потому что «они большие», — плохая идея, которая превращает одну аварию в две.

Как больше не попадать

  • Мониторинг свободного места с предупреждением заранее. Не «диск заполнен», а «осталось 20 процентов». Разница между этими двумя уведомлениями — несколько дней спокойной работы вместо аварии.
  • Ротация логов. Штатное средство есть в любой системе, но у нестандартных приложений его нередко забывают настроить.
  • Резервные копии не на этом же диске. Это полезно и для свободного места, и по существу.
  • Периодическая уборка. Старые копии, кэш, ненужные пакеты — раз в месяц, как часть регулярного обслуживания.
  • Отладочный режим выключен на рабочем сервере. Без исключений.

Коротко

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

Из всего, что мы включаем в мониторинг, свободное место — показатель, который чаще других срабатывает по-настоящему. Уведомление «осталось 20 процентов» приходит в среду днём, а не в субботу ночью. В этом вся разница.