A full disk is the most common cause of a budget VPS going down for reasons the owner did not see coming. It is also one of the easiest failures to predict and prevent, because disk usage is almost perfectly linear. This article explains what breaks when storage fills, what usually fills it, and how to build an early-warning routine that costs nothing.
What happens when the disk hits 100%
- Databases stop accepting writes. MySQL and PostgreSQL refuse writes once the volume is full, which breaks dynamic sites instantly.
- Logs stop being written. Failed log writes can cascade into application errors and, in some cases, service restarts.
- Packages and updates fail. apt/dnf need free space to stage packages, so security updates silently stop.
- Temporary files break applications. Session files, upload buffers, and cache directories all need writable space.
- SSH and shells misbehave. In severe cases you cannot log in to fix the problem.
The failure mode is rarely graceful. Sites return 500 errors, the database drops into read-only, and by then the fix requires freeing space from a degraded shell.
What actually fills a budget VPS disk
| Culprit | Typical growth | Fix |
|---|---|---|
| Application and web server logs | 100 MB–2 GB/month | logrotate with retention |
| Old kernel and package caches | 500 MB–2 GB one-off | apt autoremove, clean cache |
| Database binlogs | Unbounded | binlog expiry or disable |
| Docker images and volumes | 1–20 GB | docker system prune on schedule |
| Backups stored locally | Grows with data | ship off-site, keep one local |
| User uploads and media | Grows with content | object storage offload |
The two that surprise people most are database binlogs and Docker layers. Both can consume multiple gigabytes without any change in your actual content.
Diagnosing what is using your space
Before you can fix a filling disk you have to know what is filling it. Three commands cover most cases, and they run in seconds:
- du -h –max-depth=1 / | sort -h shows which top-level directories hold the most data.
- du -sh /var/log/* | sort -h isolates log growth, the most common culprit on a neglected server.
- journalctl –disk-usage reports how much the systemd journal is consuming, which is frequently hundreds of megabytes on long-running servers.
- docker system df summarises image, container, and volume usage if you run containers.
- du -sh /var/lib/mysql/* | sort -h reveals whether binlogs or table data dominate your database directory.
Building a free early-warning routine
You do not need a monitoring subscription to catch a filling disk. A single cron job that checks usage and alerts you at 75% is enough.
- Add a daily cron job that reads disk usage and sends an email or webhook when it crosses 75%.
- Schedule logrotate for every service that writes logs, with a two-week retention window.
- Set a Docker prune job if you run containers, weekly at minimum.
- Configure database binlog expiry, or disable binlogs if you do not replicate.
- Move backups off the server; local backups are the fastest way to fill a disk and the first thing to lose when it fails.
The 75% threshold gives you days of warning instead of minutes. That is the difference between a scheduled cleanup and an outage.
Choosing a plan with enough storage
Storage is the spec buyers most often under-buy, because it feels less important than CPU and RAM. A reasonable rule is to double your current usage when sizing a new plan, then confirm the provider’s snapshot and backup storage does not count against your main quota. Some budget providers meter backups separately and generously; others fold them into the same volume, which halves your usable space.
Check the storage figure, the snapshot policy, and the overage terms on the budget VPS comparison table before you pick a plan. A server that runs out of disk is a server that is down, no matter how much RAM it has.
Related reading on this blog: disk optimization tactics for low-storage plans, server storage cost per gigabyte, and free monitoring tools for budget servers.
