План исправления ситуации с диском /storage (2026-02-15)
Основание: Анализ инцидента INCIDENT-ANALYSIS-STORAGE-DISK-SPACE-BELOW-RESERVE.md, текущее состояние STORAGE-CURRENT-STATE-2026-02-15.md.
1. Прошлый опыт (кратко)
| Факт | Вывод |
|---|---|
| За 5 дней (10–15.02) свободное место на /storage упало с ~230 ГБ до 41 ГБ, затем до 0 ГБ (EMERGENCY). | Рост данных (LXD снимки, Docker) не компенсировался автоочисткой на /storage. |
| При WARNING/CRITICAL/EMERGENCY монитор не освобождал место на /storage (не было веток для /storage в очистке). | В disk-space-monitor.sh и disk-space-emergency-cleanup.sh добавлена очистка для /storage (Docker prune, вызов cleanup-lxd-snapshots от cdto). |
| Очистка снимков LXD при вызове из systemd показывала «Контейнер не найден». | Контейнеры принадлежат пользователю cdto; при таймауте 120 с на переполненном диске LXD не успевал ответить. Увеличен LXC_INFO_TIMEOUT до 300 с в cleanup-lxd-snapshots.sh. |
| Не было раннего порога предупреждения. | Введён STORAGE_EARLY_WARNING_GB=100 в мониторе и документации. |
| Регламентная еженедельная проверка не предотвратила выход за резерв. | В политике и disk-space-protection зафиксирована обязательная еженедельная проверка и реакция при < 80 ГБ / < 100 ГБ. |
2. План исправления (выполнено и осталось)
2.1 Выполнено
- Описание текущего состояния — документ STORAGE-CURRENT-STATE-2026-02-15.md.
- Мониторинг и автоочистка для /storage — в disk-space-monitor.sh и disk-space-emergency-cleanup.sh добавлены ветки для /storage (Docker, вызов cleanup-lxd-snapshots от пользователя cdto).
- Ранний порог — STORAGE_EARLY_WARNING_GB=100 в скрипте и документации.
- Аварийная очистка — обнуление логов Docker на /storage при 100% диска (в disk-space-emergency-cleanup.sh и STORAGE-BRING-TO-NORMAL.md).
- Таймаут LXD — LXC_INFO_TIMEOUT увеличен до 300 с в cleanup-lxd-snapshots.sh.
- Запуск очистки снимков вручную — от пользователя cdto для немедленного освобождения места (выполняется; при большом числе снимков — длительно).
2.2 Осталось / регулярно
- Дождаться завершения очистки снимков и проверить
df -h /storage. При необходимости повторить очистку или выполнить анализ крупных каталогов (du -h --max-depth=2 /storage | sort -h | tail -25). - Еженедельно: проверка по POST-REBOOT-CHECKLIST.md и при свободном < 100 ГБ — плановая очистка по STORAGE-BRING-TO-NORMAL.md.
- Установка обновлённых скриптов в систему (если правки делались в репозитории):
sudo cp /home/cdto/DENKART/scripts/disk-space-monitor.sh /usr/local/bin/
sudo cp /home/cdto/DENKART/scripts/disk-space-emergency-cleanup.sh /usr/local/bin/
sudo cp /home/cdto/DENKART/scripts/cleanup-lxd-snapshots.sh /usr/local/bin/(если скрипт копируется в систему) или оставить запуск из репозитория.
3. Критерий «штатное состояние»
- Свободно на
/storage≥ 80 ГБ. - Мониторинг активен; при следующем WARNING/CRITICAL/EMERGENCY автоочистка (в т.ч. LXD от cdto с увеличенным таймаутом) выполняется без ручного запуска, где возможно.
- Еженедельная проверка и реакция при < 100 ГБ зафиксированы в регламенте.
4. Связанные документы
- Анализ инцидента: /storage ниже резерва 80 ГБ
- Приведение /storage к нормальной работе
- Политика хранения данных и контроля дискового пространства
- Защита от переполнения диска
Документ подготовлен: AI Denkart, технический директор.