Настройка дисковых квот для пользователей на сервере Linux

Дисковые квоты: как один процесс забивает сервер

Дисковые квоты — это не «гигиена», а защита от конкретного класса аварий. Достаточно одного процесса — сборщика логов, кэш-агента, скрипта с включённой отладкой или зависшего выгрузчика отчётов, — который пишет в общий раздел, и занятость диска начинает расти незаметно: графики мониторинга выглядят ровно до момента, когда свободного места остаётся на считаные минуты.

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

Порог на графике «свободно меньше десяти процентов» не спасает: между уведомлением и заполнением раздела проходит меньше времени, чем нужно дежурному на разбор. Квоты переворачивают логику — ограничение ставится на конкретную учётную запись или группу, отдельно по объёму и по числу inode. Так делают XFS и ext4: мягкий предел сигналит и даёт запас времени на реакцию, жёсткий просто не пускает запись дальше, оставляя раздел живым для остальных.

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

Что даёт ограничение места: измеримые эффекты

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

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

Эффект — не «порядок на диске», а управляемый отказ: приложение получает ошибку записи на своём лимите, а не роняет узел целиком. Свободное место остаётся у системы и у сервисов, которые не должны останавливаться, а рост арендуемого объёма выравнивается под реальное потребление.

Варианты дисковых квот: сравнение режимов и границ

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

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

Порядок внедрения: от аудита до передачи регламента

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

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

2. Схема распределения. Раскладываем разделы по назначению: домашние каталоги, рабочие данные, служебные и временные области. Для каждой группы решаем, что ограничиваем — объём, число объектов или оба параметра сразу.

3. Настройка порогов. Задаём мягкий и жёсткий предел и льготный период: мягкий предупреждает и даёт время убрать лишнее, жёсткий прекращает запись. Базовый профиль распространяем на новые учётные записи, послабления — на сборки и репозитории с предсказуемым ростом.

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

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

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

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

Комплект на выходе: конфигурации, схемы и регламенты

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

• Конфигурации квот: опции монтирования usrquota, grpquota или prjquota, значения мягкого и жёсткого лимитов, отдельный порог по инодам — готовыми фрагментами под ваши файлы настроек.
• Схема размещения данных: что вынесено на отдельный том, где домашние каталоги, где временные файлы сборок и логи, какой лимит действует на каждом разделе.
• Таблица лимитов по ролям и группам: сколько выделено разработчикам, сервисным учётным записям, агентам сборки и хранилищу резервных копий — и чем обоснован каждый порог.
• Регламент обслуживания: с какой периодичностью снимается отчёт о занятости, как согласуется изменение лимита, при какой доле заполнения тома запускается расширение.
• Инструкция для дежурных: пошаговый разбор «на разделе кончилось место» — как за минуты найти потребителя, временно поднять порог и вернуть значение обратно.
• Отчёт о занятости: выгрузка по пользователям и группам с топом потребителей и динамикой, тем же скриптом, что работает по расписанию.
• Набор скриптов и заданий: включение квот, снятие отчёта, уведомление при превышении мягкого порога — в системе контроля версий, с историей правок.
• Порядок отката: как снять ограничения без потери данных и что смотреть в журналах, если после включения квот сервис не поднялся.

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

Кейс: как остановили бесконтрольный рост раздела

На одном из проектов с высоконагруженным бэкендом корневой раздел и /var регулярно уходили за 90%: логи приложений не ротировались, каталоги сборки накапливали артефакты, а отладочные копии баз оседали в /tmp. Дежурный раз в неделю искал крупнейших потребителей через du и чистил файлы руками, но через несколько дней место заканчивалось снова — рост раздела был не разовым сбоем, а устойчивой динамикой.

Что изменили: /var/log, /home, /srv и каталоги сборки вынесли на отдельные тома и включили квоты по пользователям и группам — мягкий лимит с отсрочкой на неделю и жёсткий потолок, после которого запись просто не проходит. Отдельно ограничили число инод, иначе один процесс с миллионом мелких файлов занимает раздел, не показывая заметного объёма.

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

Уведомление на 80% занятости с прогнозом по скорости роста заменило реакцию на инцидент подготовкой к нему. Аварий по остатку места за наблюдаемый период не было ни одной, а ручная уборка перестала быть регулярной обязанностью: место освобождается само, до того как дежурный откроет терминал. При том же профиле нагрузки раздел держится на треть свободным, и откат к прежнему состоянию уже не нужен.

Что делать, если раздел уже заполнен и сервисы не стартуют

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

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

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

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

Технические сомнения перед началом работ

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

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

Совместимо ли это с резервным копированием?

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

Что с системными сервисами и исключениями?

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

Можно ли откатить, если политика мешает работе?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Что полезно рассказать или прислать:

• Схему разделов и точек монтирования: где квоты уже включены, а где место расходуется бесконтрольно.
• Перечень учётных записей и групп — лимиты назначаются группе, а не каждому пользователю вручную.
• Какие сервисы пишут на диск: домашние каталоги, почта, резервные копии, рабочие наборы данных — чтобы квота не остановила нужный процесс.
• Что уже случалось: переполнение раздела, отказ записи, простои — и как их обнаруживали.
• Требования к контролю расхода: кому и на каком пороге уходит уведомление, нужен ли регулярный отчёт.
• Допустимое окно работ: можно ли перемонтировать раздел или нужно обойтись без остановки сервисов.

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