Linux quotas на VDS: user quota, project quota, /var/www и лимиты для бэкапов

Когда на одном VDS живут несколько сайтов, пользователей, CI-задач или резервных копий, вопрос свободного места быстро перестаёт быть бытовым. Один runaway-лог, неудачный дамп базы или загруженные через CMS медиафайлы могут занять весь диск, после чего начинаются неприятности: MySQL перестаёт писать binlog, PHP не может создать сессию, Nginx отдаёт 500/502, а SSH-вход иногда тормозит из-за переполненного /var.

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

В этой статье разберём linux quotas практически: чем disk quota отличается от прав chmod, когда удобнее user quota, а когда project quota, как включить квоты на ext4 и XFS, как ограничить /var/www по сайтам и как сделать отдельную backup quota, чтобы бэкапы не съели весь сервер.

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

Что именно ограничивают Linux quotas

Классическая квота в Linux ограничивает два ресурса файловой системы: блоки и inode. Блоки — это фактически объём данных на диске, например 5 ГБ или 50 ГБ. Inode — это количество файлов и каталогов. Второй лимит часто забывают, хотя на веб-серверах он бывает не менее важен: кеши, сессии, миниатюры изображений и временные файлы могут создать сотни тысяч мелких объектов и упереться не в гигабайты, а именно в inode.

Есть несколько видов квот. user quota привязывается к UID пользователя. Если у каждого сайта на VDS есть отдельный системный пользователь, это простой и понятный вариант. group quota привязывается к GID группы и удобна, если несколько пользователей работают с общим деревом файлов. project quota ограничивает не пользователя, а дерево каталогов: например, весь /var/www/site1, даже если файлы внутри принадлежат www-data, deploy-пользователю и процессу сборки.

На ext4 обычно используют инструменты quota, quotacheck, edquota, setquota, repquota. На XFS квоты встроены в файловую систему и управляются через xfs_quota. Если у вас современный VDS с XFS, особенно на RHEL-based дистрибутивах, для лимитов на каталоги чаще всего удобнее именно project quota.

Квоты и chmod: почему это разные механизмы

В названии темы часто рядом оказываются квоты и chmod, но решают они разные задачи. chmod отвечает на вопрос «кто может читать, писать или выполнять файл». Квота отвечает на вопрос «сколько места этот пользователь, группа или проект может занять». Если вы закрыли каталог через chmod 750, посторонний пользователь не сможет туда писать, но владелец всё равно может заполнить весь раздел. Если вы поставили квоту 10 ГБ, владелец может иметь права на запись, но после достижения лимита новые записи начнут получать ошибку Disk quota exceeded.

На практике нужны оба механизма. Права и владельцы изолируют сайты друг от друга, а квоты ограничивают ущерб от ошибок и внезапного роста данных. Например, для /var/www/site1 можно настроить владельца site1, группу веб-сервера, режимы доступа через chmod и setgid-бит, а сверху добавить project quota на 20 ГБ. Тогда деплой, PHP-FPM и веб-сервер работают штатно, но один сайт не забирает весь диск.

Перед настройкой: проверьте файловую систему и точки монтирования

Квоты включаются на уровне файловой системы. Поэтому сначала важно понять, где находится нужный каталог. На VDS часто бывает один корневой раздел /, внутри которого лежат и /var/www, и /home, и /var/backups. В более аккуратной схеме под /var, /home или бэкапы выделяют отдельный раздел или LVM-том. Квоты можно использовать и на корневом разделе, но отдельные точки монтирования обычно проще обслуживать и безопаснее расширять.

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /var/www
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /var/backups
df -hT
df -ih

Обратите внимание на FSTYPE: для ext4 и XFS команды отличаются. Также проверьте, не находится ли нужный каталог на overlay, bind mount или сетевом хранилище. В этой статье говорим именно про локальные Linux-файловые системы на VDS: ext4 и XFS.

Установка инструментов quota

На большинстве серверных систем базовые утилиты не всегда установлены по умолчанию. Пакет quota нужен в первую очередь для ext4 и для просмотра пользовательских квот. На XFS дополнительно понадобится xfsprogs; обычно он уже есть, если система установлена на XFS.

Debian и Ubuntu

apt update
apt install quota xfsprogs

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora

dnf install quota xfsprogs

После установки проверьте, что доступны основные команды:

which edquota
which repquota
which xfs_quota

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

User quota на ext4: лимит для пользователя

Начнём с классического сценария: у вас есть пользователь site1, его файлы лежат в /var/www/site1, и нужно ограничить суммарное место, которое он может занять на разделе. Это хорошо работает, если все файлы сайта действительно принадлежат одному UID. Если часть файлов создаёт общий пользователь веб-сервера, пользовательская квота site1 их не посчитает — в таком случае смотрите раздел про project quota.

Для ext4 квоты включаются через параметры монтирования. Найдите строку нужной файловой системы в /etc/fstab. Если /var/www находится на корневом разделе, менять нужно строку для /. Пример для ext4 с пользовательскими и групповыми квотами:

UUID=11111111-2222-3333-4444-555555555555 / ext4 defaults,usrquota,grpquota 0 1

После изменения /etc/fstab перемонтируйте файловую систему или перезагрузите сервер в плановое окно. Для корневого раздела перемонтирование обычно проходит без остановки сервисов, но на production лучше заранее убедиться, что есть актуальная резервная копия и доступ в консоль VDS.

mount -o remount /
findmnt -o TARGET,FSTYPE,OPTIONS /

Теперь создайте и проинициализируйте файлы учёта квот. Для корневого раздела:

quotacheck -cum /
quotacheck -cgm /
quotaon /
quotaon -p /

Опции -u и -g отвечают за пользовательские и групповые квоты. Если на разделе уже много данных, quotacheck может занять заметное время и создать нагрузку на диск. На небольшом VDS это особенно чувствительно, поэтому лучше выполнять процедуру вне пиковой нагрузки.

Дальше зададим лимит пользователю. Есть интерактивный способ через edquota и неинтерактивный через setquota. Для автоматизации удобнее setquota. Пример: мягкий лимит 8 ГБ, жёсткий лимит 10 ГБ, inode не ограничиваем:

setquota -u site1 8388608 10485760 0 0 /
quota -u site1
repquota -u /

Значения для блоков в классических quota-утилитах обычно задаются в килобайтах. Поэтому 10 ГБ — это 10 × 1024 × 1024, то есть 10485760. Мягкий лимит можно превышать в течение grace period, жёсткий лимит превышать нельзя. Настроить grace period можно через edquota -t:

edquota -t

Интерактивный редактор удобен, когда вы вручную настраиваете несколько пользователей и хотите видеть текущие значения. Но для инфраструктуры как код, cloud-init или Ansible лучше использовать setquota, чтобы результат был воспроизводимым.

User quota на XFS

В XFS квоты включаются параметрами монтирования, но учёт работает иначе: отдельный quotacheck обычно не нужен. Для пользовательских квот добавьте параметр uquota или usrquota в /etc/fstab. Для групповых — gquota или grpquota. Пример:

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee / xfs defaults,uquota,gquota 0 0

Перемонтируйте раздел и проверьте параметры:

mount -o remount /
findmnt -o TARGET,FSTYPE,OPTIONS /
xfs_quota -x -c 'state' /

Задать лимит пользователю на XFS можно через xfs_quota. Пример: мягкий лимит 8 ГБ, жёсткий 10 ГБ:

xfs_quota -x -c 'limit -u bsoft=8g bhard=10g site1' /
xfs_quota -x -c 'report -uh' /

Флаг -x включает expert mode, который нужен для изменения лимитов. Команда report -uh показывает отчёт по пользователям в человекочитаемом виде. Если нужен лимит на количество файлов, используйте inode-лимиты:

xfs_quota -x -c 'limit -u isoft=200k ihard=250k site1' /
xfs_quota -x -c 'report -u -i -h' /

Project quota: лучший вариант для /var/www

project quota особенно полезна на веб-серверах. Представьте каталог /var/www/site1. Внутри могут быть файлы владельца site1, временные файлы от пользователя веб-сервера, артефакты деплоя от deploy, кеш приложения, загруженные пользователями изображения. Если ограничивать только UID site1, часть данных выпадет из учёта. Project quota считает всё дерево каталога независимо от владельцев файлов.

На XFS project quota — зрелый и удобный инструмент. На ext4 проектные квоты тоже существуют в современных ядрах, но в админской практике для каталогов на VDS чаще используют XFS. Поэтому ниже основной пример будет для XFS. Если вы только планируете разметку сервера под много сайтов, отдельный XFS-раздел для /var/www с prjquota — очень практичное решение.

Сначала включите project quota в /etc/fstab. Если /var/www на отдельном разделе:

UUID=bbbbbbbb-cccc-dddd-eeee-ffffffffffff /var/www xfs defaults,prjquota 0 0

Если /var/www лежит на корневом XFS-разделе, параметр prjquota добавляется к строке корня:

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee / xfs defaults,uquota,prjquota 0 0

Перемонтируйте и проверьте состояние:

mount -o remount /var/www
xfs_quota -x -c 'state' /var/www

Если /var/www не отдельная точка монтирования, используйте путь к соответствующей файловой системе, например /:

mount -o remount /
xfs_quota -x -c 'state' /

Назначаем project quota каталогу сайта

Для project quota нужны два файла соответствий: /etc/projects и /etc/projid. В первом project ID связывается с путём, во втором имя проекта связывается с project ID. Номера выбирайте так, чтобы они не пересекались. Например, для сайта site1 используем ID 1001.

mkdir -p /var/www/site1
echo '1001:/var/www/site1' >> /etc/projects
echo 'site1:1001' >> /etc/projid
xfs_quota -x -c 'project -s site1' /var/www
xfs_quota -x -c 'limit -p bsoft=18g bhard=20g site1' /var/www
xfs_quota -x -c 'report -ph' /var/www

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

Проверить конкретный каталог можно так:

xfs_io -c stat /var/www/site1

В выводе ищите project ID. Если он не соответствует ожидаемому, повторите project -s и убедитесь, что команда выполняется относительно правильной точки монтирования. Частая ошибка — запускать xfs_quota для /var/www, когда на самом деле это обычный каталог на корневом разделе, а не отдельная файловая система. В таком случае нужно указывать /.

Backup quota: как ограничить каталог резервных копий

Бэкапы должны спасать, а не становиться причиной аварии. На небольшом VDS типовая проблема выглядит так: настроили ежедневный дамп MySQL в /var/backups, забыли ротацию, через месяц диск заполнен. Ещё хуже, если backup-скрипт сначала создаёт новый архив, а старые удаляет только после успешного завершения: при нехватке места процесс падает, старые копии остаются, свободное место не возвращается.

Квота для бэкапов помогает ограничить максимальный ущерб. Но она не отменяет retention-политику. Хорошая схема обычно включает три уровня: локальная короткая история для быстрого восстановления, удалённая копия вне VDS, регулярная проверка восстановления. Если нужен отдельный удалённый слой, посмотрите практику резервного копирования в S3 с restic и Borg.

Если /var/backups находится на XFS с prjquota, заведём отдельный проект:

mkdir -p /var/backups/local
echo '2001:/var/backups/local' >> /etc/projects
echo 'localbackups:2001' >> /etc/projid
xfs_quota -x -c 'project -s localbackups' /
xfs_quota -x -c 'limit -p bsoft=25g bhard=30g localbackups' /
xfs_quota -x -c 'report -ph' /

Здесь важно выбрать точку монтирования правильно. Если /var/backups на корневом разделе, в командах используем /. Если это отдельный XFS-раздел, используем /var/backups. Ошибка в точке монтирования — одна из самых частых причин, почему xfs_quota не видит проект или показывает пустой отчёт.

Для ext4 можно ограничить пользователя, от имени которого выполняется backup-скрипт. Например, создайте пользователя backup, отдайте ему каталог и задайте user quota:

useradd --system --home-dir /var/backups/local --shell /usr/sbin/nologin backup
mkdir -p /var/backups/local
chown backup:backup /var/backups/local
chmod 750 /var/backups/local
setquota -u backup 26214400 31457280 0 0 /
quota -u backup

В RHEL-based системах путь к nologin обычно /sbin/nologin, поэтому перед созданием пользователя проверьте command -v nologin. Сама идея остаётся той же: архивы должны создаваться от имени пользователя, на которого назначена квота.

Если скрипт запускается от root и пишет файлы с владельцем root, пользовательская квота backup не поможет. В таком случае либо запускайте конкретную задачу от отдельного пользователя, либо используйте project quota.

Права доступа для /var/www: где chmod всё-таки нужен

Квоты ограничивают объём, но не наводят порядок в правах. Для многосайтового VDS полезно держать модель простой: отдельный пользователь на сайт, общая группа для веб-сервера там, где это действительно нужно, минимальные права на запись. Не стоит делать chmod -R 777 /var/www: это маскирует проблемы деплоя и создаёт новые риски.

Группа веб-сервера зависит от дистрибутива и стека. В Debian и Ubuntu для Apache/Nginx с PHP-FPM часто используют www-data. В AlmaLinux, Rocky Linux, CentOS Stream и Oracle Linux для Apache это обычно apache, а для Nginx — nginx. В примерах ниже подставьте свою группу.

Debian и Ubuntu

WEBGROUP=www-data
useradd --create-home --shell /bin/bash site1
mkdir -p /var/www/site1/public
chown -R site1:${WEBGROUP} /var/www/site1
find /var/www/site1 -type d -exec chmod 2750 {} +
find /var/www/site1 -type f -exec chmod 0640 {} +
chmod 2750 /var/www/site1/public

RHEL-based системы и Fedora

WEBGROUP=apache
useradd --create-home --shell /bin/bash site1
mkdir -p /var/www/site1/public
chown -R site1:${WEBGROUP} /var/www/site1
find /var/www/site1 -type d -exec chmod 2750 {} +
find /var/www/site1 -type f -exec chmod 0640 {} +
chmod 2750 /var/www/site1/public

Режим 2750 на каталогах включает setgid-бит: новые файлы и каталоги наследуют группу родительского каталога. Это удобно, когда веб-серверу нужна групповая читаемость, а деплой выполняется пользователем сайта. Для каталогов загрузок, кеша или runtime-директорий права могут отличаться:

mkdir -p /var/www/site1/shared/uploads
mkdir -p /var/www/site1/shared/cache
chown -R site1:${WEBGROUP} /var/www/site1/shared
find /var/www/site1/shared -type d -exec chmod 2770 {} +
find /var/www/site1/shared -type f -exec chmod 0660 {} +

Если у вас PHP-FPM-пулы запускаются от отдельных пользователей, модель становится ещё чище: сайт пишет только в свои каталоги, а project quota контролирует общий объём дерева. Если же все сайты работают от одного пользователя веб-сервера, user quota почти бесполезна для разделения сайтов — тогда project quota для /var/www/siteN становится предпочтительным вариантом.

Как тестировать квоты без сюрпризов

После настройки не ограничивайтесь просмотром отчёта. Проверьте, что лимит реально срабатывает. Самый простой способ — создать тестовый файл внутри каталога или от имени нужного пользователя. Делайте это аккуратно и не на production в час пик: команда записи большого файла создаёт I/O-нагрузку.

sudo -u site1 dd if=/dev/zero of=/var/www/site1/quota-test.bin bs=10M count=1200 status=progress
rm -f /var/www/site1/quota-test.bin

Если лимит 10 ГБ, команда должна завершиться ошибкой около этой границы. Для project quota можно писать файл от любого пользователя, который имеет права на запись в каталог: квота должна считаться по проекту, а не по UID.

Полезные команды для диагностики:

quota -u site1
repquota -a
xfs_quota -x -c 'report -uh' /
xfs_quota -x -c 'report -ph' /
xfs_quota -x -c 'state' /

Если приложение получает ошибку Disk quota exceeded, проверьте не только блоки, но и inode. Веб-приложение может иметь свободные гигабайты, но не иметь возможности создать новый файл из-за inode-лимита.

df -h
df -ih
xfs_quota -x -c 'report -p -i -h' /

Мягкий и жёсткий лимит: как выбирать значения

Жёсткий лимит — это абсолютная граница. Мягкий лимит — предупреждающая зона, которую можно превышать ограниченное время. Для сайтов обычно удобно ставить soft limit на 85–90% от hard limit. Например, 18 ГБ soft и 20 ГБ hard. Тогда у администратора есть время заметить рост и отреагировать, а приложение не падает сразу при кратковременном всплеске.

Для backup quota подход другой. Бэкапы часто растут скачками: большой дамп, полный архив, временный файл сжатия. Если поставить слишком узкий зазор между soft и hard, задания будут нестабильными. Лучше рассчитать максимальный размер одного полного бэкапа, добавить место на временный файл и только потом задавать лимит. Если полный архив сайта и базы занимает 8 ГБ, а во время упаковки создаётся временный файл, лимит 10 ГБ может быть слишком мал.

Типовые ошибки при настройке linux quotas

Первая ошибка — включить параметры в /etc/fstab, но не перемонтировать файловую систему. В отчётах ничего не меняется, потому что ядро ещё не использует новые параметры. Всегда проверяйте findmnt, а не только содержимое /etc/fstab.

Вторая ошибка — путать пользователя приложения и владельца файлов. Если PHP-FPM работает от общего пользователя веб-сервера, а файлы сайта принадлежат site1, новые кеши и загрузки могут считаться не туда, куда вы ожидаете. Для одного сайта это терпимо, для нескольких — плохо: все сайты начинают делить одну квоту. Решение — отдельные PHP-FPM-пулы по пользователям или project quota.

Третья ошибка — забыть про inode. Лимит в гигабайтах не защитит от миллиона мелких файлов. Для каталогов кеша, очередей, сессий и превью изображений имеет смысл дополнительно задавать inode-лимит или хотя бы мониторить df -i.

Четвёртая ошибка — использовать квоты как единственный контроль бэкапов. Если локальные копии упёрлись в лимит, новые бэкапы могут перестать создаваться. Это лучше, чем заполнить весь диск, но всё равно проблема. Нужны уведомления о неуспешных заданиях и периодическая проверка восстановления.

Пятая ошибка — массово применять chmod -R 777, когда приложение не может писать в каталог. Такой подход не лечит квоты, владельцев или неверный PHP-FPM-пул. Правильнее выяснить, какой пользователь пишет файл, кому принадлежит каталог и какой лимит сработал.

Мини-чеклист для VDS с несколькими сайтами

• Разнести сайты по отдельным системным пользователям: site1, site2, site3.
• По возможности запускать PHP-FPM-пул каждого сайта от соответствующего пользователя.
• Для /var/www использовать XFS с prjquota, если нужна квота на каталог независимо от владельцев файлов.
• Для каждого сайта завести project ID и лимит через xfs_quota.
• Для локальных бэкапов выделить отдельный каталог, пользователя или project quota.
• Не использовать chmod 777 как универсальное решение проблем записи.
• Мониторить свободное место, inode и отчёты квот, а не ждать ошибки от приложения.

Как снять или изменить квоту

Изменение лимитов безопаснее, чем отключение квот целиком. На XFS достаточно задать новые значения:

xfs_quota -x -c 'limit -p bsoft=28g bhard=30g site1' /var/www
xfs_quota -x -c 'report -ph' /var/www

Чтобы фактически убрать лимит project quota, задайте нули:

xfs_quota -x -c 'limit -p bsoft=0 bhard=0 site1' /var/www

Для ext4 user quota через setquota:

setquota -u site1 0 0 0 0 /
quota -u site1

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

Итоги

Linux quotas — простой и надёжный способ не дать одному пользователю, сайту или каталогу занять весь диск VDS. Для классической схемы «один пользователь — один сайт» подойдёт user quota с edquota или setquota. Для современных веб-серверов с несколькими владельцами файлов внутри /var/www чаще удобнее project quota на XFS и управление через xfs_quota.

Главная мысль: квоты и chmod не конкурируют. Права доступа определяют, кто может писать, а квоты — сколько можно записать. Если совместить аккуратных владельцев, отдельные PHP-FPM-пулы, project quota для сайтов и backup quota для локальных копий, VDS становится заметно устойчивее к типовым авариям с переполнением диска.