A full disk on a cheap VPS is rarely a sudden event. It builds over weeks as logs rotate badly, databases grow, package caches accumulate, and backup snapshots stack up. By the time services crash the disk is often 100 percent full and the box is refusing writes to files as basic as /etc/mtab. This guide explains what actually breaks at each stage, how to find the space hogs, and how to add capacity without overpaying.
The important thing to understand is that Linux behaves differently at 100 percent versus 90 percent full. Symptoms appear well before the disk is full, and recognising them early is the difference between a five-minute cleanup and a rebuild from backup.
Symptoms by Fill Level
Between 85 and 95 percent, you typically see warnings in logs, intermittent write failures in application output, and services that restart but refuse to persist state. PostgreSQL and MySQL may log disk-space errors while still running, giving you a window to act.
At 100 percent, the picture changes sharply. systemd cannot write its journal, so logging stops. SSH may still accept connections, but tools that need temporary files fail. Cron jobs error silently. Web servers return 500s because sessions and caches cannot be written. In the worst case the filesystem goes read-only or the provider’s monitoring suspends the instance.
Databases deserve special mention because they fail in their own way. PostgreSQL refuses to extend its write-ahead log and throws write errors, and MySQL can corrupt tables if killed mid-write. A disk that fills while a database is under load is the scenario most likely to force a restore from backup, so treat the database host as the one that needs the earliest warning threshold.
The Usual Culprits
Six sources account for the majority of unexpected growth on a budget VPS:
- Application logs in /var/log with no rotation rule
- Databases and their write-ahead logs growing with retention gaps
- Package manager caches, especially after large upgrades
- Docker images and layers that pile up across deployments
- Local backup files written to the same disk they protect
- Deleted-but-open files held by a running process
That last item is the most deceptive. A process can hold open a file that has been deleted, so the space is not freed until the process restarts. df reports the disk full while du reports plenty free, and the discrepancy points straight at the culprit.
Finding the Space Quickly
Start with df -h to confirm which filesystem is full, then du -x -h –max-depth=1 / to rank top-level directories by size. Drill into the biggest one and repeat. For a fast answer, sort du output and read the top few lines rather than scrolling. Remember that a dedicated data disk can fill while the root filesystem looks healthy, so check every mounted volume, not just /.
If du and df disagree, look for deleted-but-open files by listing open file handles and sorting by size, or with an lsof variant that shows deleted entries. Restarting the responsible service reclaims the space immediately. On Docker hosts, a prune of unused images and volumes often frees several gigabytes in one command.
Emergency Recovery at 100 Percent
When writes are failing, free a small amount of space fast so the system can function, then investigate properly. Truncating a runaway log file is the quickest fix: redirect an empty stream into it rather than deleting it, because a deleted open log keeps its file handle and holds the space.
Other immediate moves include vacuuming logs with journalctl –vacuum-time or –vacuum-size, clearing the package cache, and removing old kernel images. Free a few hundred megabytes, restore service, and only then do the full cleanup. Fighting a full disk while everything is failing turns a short outage into a long one. Note that journald keeps a reserved minimum by default, and that reservation is what usually lets you log in at all when the disk reads as full.
Prevention That Costs Nothing
Prevention is cheaper than any upgrade. Configure logrotate with size caps and a retention count, set the systemd journal to a maximum size, and schedule a weekly package cache clean. For databases, decide a retention window and enforce it with a job rather than leaving it to grow indefinitely.
Add a simple monitoring check that alerts at 80 percent, not 95 percent, so you act during business hours instead of at 3 a.m. A free monitoring agent or a cron job that emails a threshold warning is enough. Track the trend as well as the level: a disk growing 2 GB per week has a predictable date of failure, and seeing that date lets you plan an upgrade instead of reacting to one. If you want a framework for which thresholds are worth alerting on, see our budget VPS comparison table notes on included monitoring.
When to Add Storage vs Upgrade
If clean-up frees enough space and growth is slow, stay on the current plan. If your data genuinely grows month over month, price the options: an extra storage block at $0.10-0.30 per GB-month, a plan upgrade to a larger disk tier, or moving cold data to object storage at roughly $0.005-0.023 per GB-month.
Object storage wins for archives, backups, and media that is read rarely. Block storage attached to the VPS wins for databases and active files that need low latency. For the growing portion being logs and old backups, offloading to object storage is usually the cheapest correct answer.
Bottom Line
A full disk is a maintenance failure, not a capacity failure, in most cases. Rotate logs, cap the journal, clean caches, enforce database retention, and alert at 80 percent. Do that and a 25-40 GB disk comfortably holds a small site for years. When growth is real rather than accidental, offload cold data first and compare budget VPS plans only if the numbers justify a larger tier.
