A full disk stops a server in ways that do not look like a full disk: the database refuses writes, sessions fail, uploads error, and eventually the site returns 500s. It is one of the commonest causes of an outage and one of the easiest to prevent. Here is how to find what is using the space and what is safe to remove.
Is the disk full?
df -hFilesystem Size Used Avail Use% Mounted on
/dev/vda1 80G 76G 3.9G 96% /Anything over 90% on / needs attention today. Note that a filesystem can also run out of inodes — the count of files — while showing free space; millions of tiny session or cache files do this:
df -iFind the biggest directories
Start at the top and drill down:
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail-x stays on one filesystem; sort -h sorts human sizes; the biggest is at the bottom. Repeat into whichever directory dominates.
Faster and interactive: ncdu, which shows a navigable tree.
sudo apt install ncdu -y # dnf install ncdu
sudo ncdu -x /Arrow keys to navigate, d to delete (carefully), q to quit.
The usual culprits on a web server
Logs — /var/log, and per-site logs in /var/www/vhosts/*/logs on Plesk. A misconfigured app can write gigabytes of PHP notices a day.
sudo du -sh /var/log/* | sort -h | tail -5
sudo find /var/log -name "*.log" -size +500MFix: rotate rather than delete. logrotate handles system logs; check /etc/logrotate.d/ has an entry for the app, and set rotate 14 and compress. Emptying a large live log without stopping the service:
sudo truncate -s 0 /var/log/nginx/access.log(Never rm an open log file — the process keeps the space until restart.)
Backups stored locally — Plesk's /var/lib/psa/dumps, or a cron job writing .tar.gz files to /backup forever.
sudo du -sh /var/lib/psa/dumps /backup 2>/dev/nullFix: keep a rotation (Plesk: Backup Manager → Schedule → number of backups to keep) and move copies off the server. Local-only backups are also not backups.
Journal — journalctl --disk-usage; cap it with SystemMaxUse=500M in /etc/systemd/journald.conf.
Package caches — harmless to clear:
sudo apt clean # dnf clean all
sudo journalctl --vacuum-time=14dOld kernels (Ubuntu) — sudo apt autoremove --purge.
Application caches — wp-content/cache, Laravel's storage/framework/cache, Composer and npm caches in home directories. Safe to empty; they rebuild.
Mail — one abandoned mailbox catching spam for three years can be tens of gigabytes. Plesk: Mail shows size per mailbox.
Session files — /var/lib/php/sessions with millions of files eats inodes. Cron cleans it on Ubuntu; check the job exists and PHP's session.gc_maxlifetime is sane.
Deleted-but-open files — space that du cannot see because a process still holds a deleted file:
sudo lsof +L1 | headRestart the process listed and the space returns.
Docker
If Docker is installed, it is usually the answer:
docker system df
docker system prune -a --volumes # removes unused images, containers, volumes — read the warningStop it happening again
-
Alert at 80%. Any monitoring tool does it; even a cron line that emails you works:
0 * * * * df -h / | awk 'NR==2 && $5+0 > 80 {print "Disk at "$5" on "$(hostname)}' | mail -s "Disk warning" you@example.com -
Rotate every log, including the application's own.
-
Backups off-box with retention, not accumulating locally.
-
Size the disk for growth. A site's uploads grow; leave 30% headroom.
On a VPSPioneer managed VPS, disk usage is one of the metrics we monitor every five minutes; the ticket you get at 80% is a lot cheaper than the outage at 100%.