На файловой системе свободно 160 ГБ. Данные прибавляются на 20 ГБ в неделю. Деление 160 / 20 оставляет восемь недель до заполнения — закупку пора обсуждать, хотя мониторинг ещё не показывает аварию.

Снимок df -h отвечает только на вопрос «сколько места осталось сейчас». Для решения об апгрейде нужны ещё темп роста и дата, когда место закончится. Тогда директор увидит не красную полосу на графике, а срок и требуемую ёмкость.

Процент заполнения не показывает, сколько времени осталось

Алерты на 80, 90 и 95% реагируют на долю занятого пространства. Один и тот же порог может означать три месяца запаса на файловом сервере и четыре дня на разделе с журналами.

Для прогноза нужны два последовательных замера:

недельный прирост = занято сейчас − занято неделю назад
срок до заполнения = свободное место / недельный прирост

Эту схему приводит материал DMCloud Architect о прогнозировании заполнения дисков Linux. Microsoft Azure Well-Architected Framework называет такой подход анализом тренда: исторические данные используют для прогноза будущего спроса.

Допустим, неделю назад файловая система занимала 1 040 ГБ, сейчас — 1 060 ГБ. Прирост равен 20 ГБ. При свободных 160 ГБ расчёт даёт восемь недель.

Порог в процентах здесь вторичен. Для закупки важнее дата.

Сначала отдели рабочий рост от ошибки

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

DMCloud Architect делит причины роста на четыре группы:

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

Сначала посмотри, какая файловая система растёт:

df -P | awk 'NR>1 {print $6, $5, $4}'

Команда выводит точку монтирования, процент заполнения и доступное место.

Крупнейшие каталоги внутри /var и /home покажут два среза:

sudo du -xh /var | sort -h | tail -20
sudo du -xh /home | sort -h | tail -20

Ключ -x не даёт du перейти на соседнюю файловую систему. Размер системного журнала проверяется отдельно:

sudo journalctl --disk-usage

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

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

Алерт должен оставлять время на закупку

DMCloud Architect предлагает три горизонта:

меньше 90 дней или прирост больше 5% за неделю — проверить причину и начать пересмотр ёмкости;
меньше 45 дней или повторяющийся рост выше обычного темпа — зафиксировать объём расширения и спланировать работы;
меньше 21 дня, 85% заполнения при продолжающемся росте или критический раздел выше безопасного порога — расширять хранилище либо освобождать место.

Эти значения подходят как исходная политика, но не как норматив для любой компании. Если согласование и поставка занимают шесть недель, порог в 45 дней не оставляет времени на установку и перенос данных. Подними его до полного срока закупки и работ.

Расчёт ёмкости для заявки

Исходные данные:

свободно сейчас — 160 ГБ;
недельный прирост — 20 ГБ;
горизонт планирования — 90 дней, примерно 13 недель.

За этот срок накопится:

20 ГБ × 13 недель = 260 ГБ

Без расширения не хватит:

260 − 160 = 100 ГБ

Эти 100 ГБ позволят лишь дотянуть до конца периода с нулевым остатком. Так закупку считать нельзя: задержка поставки или ускорение роста снова приведёт к заполнению.

Чтобы через 90 дней сохранить нынешний резерв в 160 ГБ, добавь 260 ГБ полезной ёмкости. Формула такая:

дополнительная полезная ёмкость =
недельный прирост × горизонт планирования

При росте 10 ГБ в неделю потребуются 130 ГБ. При 40 ГБ — 520 ГБ. Расчёт меняется линейно: удвоился недельный прирост — удвоился требуемый объём.

Спецификация под задачу

Считаем для одиночного файлового сервера, который прибавляет 20 ГБ в неделю. Требование — сохранить резерв 160 ГБ через 90 дней.

В заявку включи:

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

Поставщику передай именно требование к полезной ёмкости, а не только номинальный объём накопителей. Конкретное число и ёмкость устройств зависят от выбранной схемы массива и возможностей контроллера.

Если после расширения сервер получит 320 ГБ полезной ёмкости, через 90 дней останется:

160 + 320 − 260 = 220 ГБ

При прежнем росте этого хватит ещё на 11 недель: 220 / 20 = 11.

Избыточность массива увеличивает требуемую сырую ёмкость. Перед закупкой проверь выбранную схему, допустимое число отказов и порядок замены накопителя. Границы такой защиты разобраны в материале про RAID, резервное питание и горячую замену.

Если файловая система расположена на внешней СХД, сначала определи, какой ресурс требуется расширить. Материал про устройство LUN и связь с физическими массивами поможет проверить схему до заявки.

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

Что принести на согласование

Для каждой растущей файловой системы зафиксируй три значения: свободный объём, недельный прирост и срок до заполнения.

Меньше 90 дней — ищи причину и готовь расчёт. Меньше 45 — фиксируй конфигурацию и срок поставки. Меньше 21 — переходи к расширению или освобождению места. Не жди этого срока, если занято уже 85% и раздел продолжает расти либо критическая файловая система пересекла установленный безопасный порог.

В заявке оставь одну формулу и её исходные данные:

20 ГБ в неделю × 13 недель = 260 ГБ полезной ёмкости

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