Анализ инцидента: свободное место на /storage ниже резерва (41 ГБ при норме 80 ГБ)

Дата анализа: 2026-02-15
Инцидент: На разделе /storage свободно 41 ГБ при установленном политикой резерве 80 ГБ (состояние WARNING).
Цель документа: Выявить причины допущения ситуации и зафиксировать решения по предотвращению повторения.

1. Факты

Параметр Значение
Раздел /storage (LVM storage-lv, ~569 ГБ)
Занято 501 ГБ
Свободно 41 ГБ
Политика (резерв) Не менее 80 ГБ свободного места
Статус по мониторингу WARNING (срабатывает при < 80 ГБ)
Дата расширения storage-lv 2026-02-10 (ubuntu-lv уменьшен, storage-lv увеличен до ~578 ГБ)
Свободно сразу после расширения ~230 ГБ (по чек-листу 2026-02-10)

За период с 2026-02-10 по 2026-02-15 свободное место на /storage снизилось с ~230 ГБ до 41 ГБ (рост занятого объёма примерно на 189 ГБ за несколько дней).

2. Почему была допущена ошибка (причины)

2.1 Прямая причина: рост данных без компенсирующей очистки

Основной потребитель места на /storage — каталоги LXD (контейнеры, снимки) и Docker (overlay2: образы, контейнеры, тома). Возможные источники роста:

  • накопление образов и неиспользуемых слоёв Docker;
  • накопление снимков LXD (скрипт ротации ограничивает количество, но при частом создании снимков объём мог вырасти до лимита);
  • логи и данные внутри контейнеров (в т.ч. записи BBB, если хранятся в пуле на /storage);
  • прочие данные сервисов в /storage.

Рост не был ограничен автоматической очисткой именно на /storage (см. п. 2.2).

2.2 Корневая причина 1: автоматическая очистка не действует на /storage

В скриптах мониторинга и аварийной очистки обрабатываются только разделы / и /D:

  • disk-space-monitor.sh: функции preventive_cleanup, aggressive_cleanup, emergency_cleanup принимают аргумент mountpoint, но содержат ветки только для "/" и "/D". При срабатывании WARNING/CRITICAL/EMERGENCY для /storage вызывается та же профилактическая/агрессивная/аварийная очистка с аргументом "/storage", однако внутри этих функций нет кода, очищающего данные на /storage (нет Docker prune, нет принудительного запуска очистки снимков LXD по этому разделу). В результате при падении свободного места ниже 80 ГБ монитор только пишет в лог и опционально отправляет алерт, но не освобождает место на /storage.

  • disk-space-emergency-cleanup.sh: очищает только временные файлы, логи, кэш apt, снимки Timeshift и старые ядра — всё это относится к корню или к /D. Раздел /storage скриптом не обрабатывается.

Вывод: Срабатывание порога WARNING для /storage не приводит к автоматическому освобождению места на этом разделе. Ошибка допущена в том смысле, что система не может самостоятельно вернуть /storage в зону резерва 80 ГБ.

2.3 Корневая причина 2: отсутствие раннего предупреждения

Порог WARNING установлен на границе резерва (80 ГБ). Нет отдельного порога «раннего предупреждения» (например, свободно < 100 ГБ или < 90 ГБ), который бы:

  • заставлял реагировать до входа в зону резерва;
  • давал время на плановую очистку (Docker, LXD, перенос данных) без спешки.

В результате реакция начинается только когда резерв уже нарушен (41 ГБ), а не когда до него остаётся 10–20 ГБ.

2.4 Корневая причина 3: регламентная проверка не предотвратила выход за резерв

В документации рекомендована еженедельная проверка (df -h, просмотр логов монитора). Однако:

  • либо проверка не выполнялась в период быстрого роста (2026-02-10 – 2026-02-15);
  • либо не была зафиксирована обязательность реакции при «свободно < 80 ГБ» (или при приближении к 80 ГБ);
  • либо регламент не предписывает явно запуск очистки Docker/LXD при приближении к резерву.

В итоге регламент не сработал как барьер до нарушения резерва.

2.5 Сводка причин

№ Причина Тип
1 Автоочистка при WARNING/CRITICAL/EMERGENCY не освобождает место на /storage (нет Docker/LXD очистки для этого раздела) Техническая
2 Нет порога «раннего предупреждения» (например, < 100 ГБ свободно) для плановых действий до входа в зону 80 ГБ Техническая / процессная
3 Еженедельная проверка не предотвратила выход за резерв: не выполнялась или не предусматривала обязательную реакцию при приближении к 80 ГБ Процессная
4 Рост данных на /storage (Docker, LXD, возможно записи/логи) не ограничивался проактивной очисткой и не мониторился по компонентам Техническая / процессная

3. Решения по предотвращению таких ошибок в дальнейшем

3.1 Технические меры

3.1.1 Добавить очистку раздела /storage в скрипты мониторинга

  • В disk-space-monitor.sh в функциях preventive_cleanup, aggressive_cleanup и при необходимости emergency_cleanup добавить ветку для mountpoint = "/storage":
  • Профилактическая (WARNING): выполнять docker image prune -f (только «висячие» образы), при необходимости — вызов скрипта очистки снимков LXD (cleanup-lxd-snapshots.sh) по расписанию уже есть; дополнительно можно вызывать его при WARNING по /storage.
  • Агрессивная (CRITICAL): docker system prune -f (неиспользуемые образы/контейнеры/сети), проверка и при необходимости ручной или скриптовый пересчёт/очистка снимков LXD в пределах политики (20/10 снимков).
  • Аварийная (EMERGENCY): более жёсткий prune (с учётом риска удаления неиспользуемых образов, нужных для быстрого перезапуска), плюс принудительный запуск cleanup-lxd-snapshots.sh.
  • Учитывать, что полный docker system prune -a удаляет все неиспользуемые образы — применять по решению (например, только при CRITICAL/EMERGENCY и с логированием).

3.1.2 Ранний порог предупреждения для /storage

  • Ввести в мониторинг порог «раннее предупреждение», например: свободно на /storage < 100 ГБ (или 110 ГБ).
  • При его достижении: запись в лог уровня NOTICE/INFO и по возможности уведомление (email/алерт), чтобы ответственный мог провести плановую очистку до нарушения резерва 80 ГБ.
  • Порог 100 ГБ зафиксировать в документации и в скрипте (переменная, например STORAGE_EARLY_WARNING_GB=100).

3.1.3 Обработка /storage в disk-space-emergency-cleanup.sh

  • В скрипт аварийной очистки добавить поддержку аргумента /storage: при вызове disk-space-emergency-cleanup.sh /storage [целевой_ГБ] выполнять безопасную очистку Docker (prune) и при необходимости запуск cleanup-lxd-snapshots.sh, с логированием объёма освобождённого места.

3.2 Процессные меры

3.2.1 Обязательный еженедельный регламент

  • Зафиксировать в Политике хранения данных и контроля дискового пространства и в Защите от переполнения диска:
  • не реже одного раза в неделю выполнять df -h / /storage /D и просматривать последние записи /var/log/disk-space-monitor.log;
  • если на /storage свободно менее 80 ГБ или менее 100 ГБ (ранний порог) — в ту же неделю выполнить плановую очистку: docker system df, при необходимости docker image prune / docker system prune, проверка количества снимков LXD и при необходимости ручная ротация в рамках политики (20/10 снимков);
  • результат проверки и выполненные действия при необходимости кратко фиксировать (например, в операционном журнале или в отчёте о проверке дисков).

3.2.2 Архитектурные решения и новый контент на /storage

  • При принятии решений о размещении новых сервисов или данных на /storage (новые контейнеры, тома Docker, записи BBB и т.п.):
  • оценивать ожидаемый рост объёма и убеждаться, что с учётом текущего использования и резерва 80 ГБ место не будет исчерпано в краткосрочной перспективе;
  • при необходимости закладывать автоматическую ротацию (логи, записи, снимки) и лимиты (например, max-size для логов контейнеров).

3.2.3 Реакция на раннее предупреждение

  • При срабатывании раннего порога (например, свободно < 100 ГБ) в течение той же недели:
  • провести анализ крупных каталогов на /storage (du -h --max-depth=2 /storage);
  • выполнить очистку Docker и проверку снимков LXD по п. 3.2.1;
  • при повторном срабатывании раннего порога без явного разового роста (обновления, миграции) — зафиксировать тренд и рассмотреть перенос части данных на /D или расширение тома по согласованию.

3.3 Документирование

  • Внести в disk-space-protection.md описание раннего порога для /storage и перечень действий при WARNING/раннем пороге.
  • В DISK-SPACE-CHECK-2026-02-15.md или отдельный чек-лист: «Еженедельная проверка дисков» с явным пунктом: при свободном месте на /storage < 80 ГБ или < 100 ГБ — выполнить перечисленные шаги очистки и зафиксировать результат.
  • Обновить политику и раздел «Исключение аварийного состояния» с указанием раннего порога и обязательности еженедельной проверки с реакцией при приближении к резерву.

4. План внедрения (кратко)

№ Действие Ответственный
1 Доработать disk-space-monitor.sh: очистка для /storage (Docker prune, вызов cleanup-lxd-snapshots при WARNING/CRITICAL/EMERGENCY) Технический директор
2 Ввести ранний порог (например, 100 ГБ) в мониторинг и документацию Технический директор
3 Доработать disk-space-emergency-cleanup.sh: поддержка /storage Технический директор
4 Зафиксировать обязательный еженедельный регламент проверки и реакции при < 80 ГБ / < 100 ГБ в политике и в disk-space-protection.md Технический директор
5 Провести разовую очистку /storage до достижения резерва ≥ 80 ГБ (Docker, LXD по политике) Эксплуатация

5. Связанные документы

Документ подготовлен: AI Denkart, технический директор проекта DENKART.
Утверждение / ознакомление: по решению владельца ресурсов (CDTO Dkvark).