Disk Quotas and Capacity Monitoring: VPS Basics

Two different limits stop a server when storage runs out, and they rarely talk to each other. The first is quota: a deliberate cap on how much a given user or filesystem may consume. The second is raw capacity: the physical ceiling of the volume, which no quota can postpone. Managing a VPS well means setting the former so the latter never becomes an incident. This guide sets up quota accounting on a data volume and builds the monitoring loop that tells you before a mount fills, not after.

Quotas: cap the consumers, not the filesystem

On a single-application VPS quotas are mostly defense in depth: users, build agents, or an out-of-control cron cannot fill the shared volume by accident. On a box that hosts several tenants or a reseller control panel, quotas become the product itself. Either way the mechanism is identical: per-filesystem accounting of blocks and inodes, with a soft limit that warns and a hard limit that refuses.

• Soft limit: a warning threshold; writes keep working while a grace period counts down.
• Hard limit: the ceiling; further allocation fails with an honest disk quota exceeded error.
• Inode quota: stops the many-small-files attack that fills the inode table while df still shows plenty of free space.

Enabling quotas on an ext4 volume

Quotas live on a filesystem, so they need the mount option plus an accounting layer that scans usage before the kernel can enforce anything:

mount -o remount,usrquota,grpquota /srv/data
quotacheck -ugm /srv/data
echo '/dev/vg0/data /srv/data ext4 defaults,usrquota,grpquota 0 2' >> /etc/fstab

quotacheck builds the accounting files, unit and group limits are then both active, and the fstab line keeps the options on every reboot. Re-run quotacheck after an unclean shutdown, because the accounting tables are rebuilt per boot by the init system on most modern distros anyway.

Setting and inspecting limits

# soft 8 GiB, hard 10 GiB, 400k/500k inodes for user 'app'
setquota -u app 8388608 10485760 400000 500000 /srv/data
repquota -s /srv/data

When a user crosses the soft limit, writes keep working while their grace period counts down; crossing the hard limit produces the refreshingly honest disk quota exceeded failure instead of vague application errors. repquota -s prints everything in human sizes so a dashboard can consume it directly.

Capacity monitoring: the loop that prevents alerts

Quotas contain the consumer; monitoring contains the filesystem, and the two overlap, a quota set at 95 percent of the volume still lets pressure reach the ceiling. A cron job that surfaces the tightest mount costs nothing and removes the surprise from a production server:

#!/usr/bin/env bash
# /usr/local/bin/diskcheck.sh
df -P | awk 'NR>1 && $5+0 >= 85 { print "ALERT " $6 " at " $5 " used" }'

# every ten minutes, output lands in cron's mail or this log
*/10 * * * * root /usr/local/bin/diskcheck.sh >> /var/log/diskcheck.log 2>&1

Point a monitoring agent at the same command and you get charted history, which turns the question from is it full into how fast is it filling, and that rate is what tells you whether pruning will be enough or whether the volume will outgrow you before the quarter ends.

Acting on the alert

1. df -h to confirm which mount, then du -xsh to find the six largest directories under it.
2. Decide between prune (logs, old snapshots, caches) and grow (lvextend -r, covered in the LVM post in this series).
3. Fix the cause, not the symptom: an upload folder that refills in a day needs a size cap or a cleanup job, not just a bigger disk.

Takeaway

Quotas keep any single consumer from holding your filesystem hostage, and a ten-minute monitoring loop keeps the mount itself honest. Set both before you need them, and the out-of-space call becomes a scheduled event rather than an incident. Netbay lets you practice the whole loop safely on disposable High-Speed SSD instances at netbayhosts.in.