How to Check Disk Space Usage on a Linux VPS
Find what's filling your disk, in five commands. A practical reference for the moments when your VPS suddenly stops accepting writes and you need to know which directory ate the space.
Running out of disk space is one of the most common reasons a VPS stops behaving. Logs balloon, a runaway backup script writes a 40 GB tarball, a database keeps growing, or an update leaves old kernels lying around. This guide walks through the tools that find the culprit fast — from the one-line overview down to the byte.
Two questions, two tools
Most disk investigations split cleanly: df answers how full is each filesystem? and du answers what's taking up the space inside it?. You'll usually run df first to spot the problem mount, then du to drill down.
The 30-second overview
# How full is every mounted filesystem? df -hT # T shows the filesystem type (ext4, xfs, tmpfs...) # h shows human-readable sizes (1.2G instead of 1234567)
You're looking for a line where the Use% column is at or near 100%. Note the mount point (often / or /var) and the device name (usually /dev/vda1 on a KVM VPS). That's where the rest of the investigation goes.
1Find the biggest directories
du (disk usage) walks a directory tree and adds up every file inside. The flag combination below gives a clean, sorted list of the top space hogs — this is the single most useful command in this whole article.
# From the root, find the 20 biggest directories sudo du -h -x -d 3 / 2>/dev/null | sort -hr | head -n 20 # Flag breakdown: # -h human-readable sizes # -x stay on one filesystem (don't descend into /proc, /mnt, etc) # -d 3 only go 3 levels deep — keeps output readable
Start at the problem mount, not always at /
If df showed /var at 98%, run sudo du -h -x -d 3 /var 2>/dev/null | sort -hr | head -n 20 instead. You'll get answers in seconds rather than waiting for du to scan the whole disk.
2Find the biggest individual files
Sometimes the issue isn't a directory full of small files but one giant log or one runaway dump file. find with size sorting gets you there.
# Files larger than 100 MB, sorted biggest first sudo find / -xdev -type f -size +100M -printf "%s\t%p\n" 2>/dev/null \ | sort -nr | head -n 20 | numfmt --to=iec --field=1
The -xdev flag is important: without it find crosses into /proc, /sys, and any mounted disks, producing a flood of noise and wasted time.
3Use a TUI for interactive exploration
For ad-hoc investigation, a text-mode browser is much faster than running du repeatedly with longer paths. ncdu renders a sortable, navigable view of disk usage that you can step into with the arrow keys.
# Install sudo apt install -y ncdu # Debian / Ubuntu sudo dnf install -y ncdu # AlmaLinux / Rocky # Scan and explore (start at the problem mount) sudo ncdu -x /var # Navigate with arrow keys; press d to delete an item, q to quit
Delete with caution
ncdu can delete files directly with the d key — very handy, but a wrong keystroke is unrecoverable. Read the path twice before pressing d, and never run it as root unless you have to.
4Check inode usage too
You can run out of disk space the other way: not bytes, but inodes. Each file takes one inode, and millions of tiny files (session caches, mail queues, runaway log rotations) can exhaust them long before the disk is full. Writes start failing with "no space left on device" even though df -h shows free space.
# Show inode usage per filesystem df -i # Find directories with the most files sudo find /var -xdev -type d -printf "%p\n" 2>/dev/null \ | while read d; do echo "$(ls -A1 "$d" 2>/dev/null | wc -l) $d"; done \ | sort -nr | head -n 20
5Common culprits and quick fixes
When you find the offending directory, these are the usual suspects:
# /var/log — old or massive log files sudo journalctl --vacuum-size=200M # keep 200 MB of systemd journal sudo find /var/log -type f -name '*.gz' -mtime +30 -delete # /var/cache/apt — apt package archives sudo apt clean # Debian / Ubuntu sudo dnf clean all # AlmaLinux / Rocky # Old kernels stacking up in /boot sudo apt autoremove --purge # Debian / Ubuntu sudo dnf autoremove # AlmaLinux / Rocky # Docker images and dangling containers docker system prune -a --volumes # A specific large file you actually want to truncate (not delete) sudo truncate -s 0 /var/log/some-app.log
Never rm files in /var/lib/mysql or /var/lib/docker
Deleting from those directories with a normal rm will corrupt the database or container store and likely cost you data. Always go through the app's own tooling: mysqladmin, docker system prune, or a backup-then-restore.
Spot trouble before the disk fills
Most outages caused by full disks are slow-burning — you have weeks of warning if anyone looks. A small cron job that emails or logs when usage crosses 80% closes that gap entirely.
#!/bin/sh
# Warn if any local filesystem is over 80% full
df -h --output=pcent,target -x tmpfs -x devtmpfs \
| awk 'NR>1 && int($1) > 80 { print "WARN " $0 }' \
| logger -t disk-watch
Save, chmod +x, and you'll see warnings in journalctl -t disk-watch or your remote log aggregator.
Frequently asked questions
What's the difference between df and du?
df reads filesystem metadata — it asks the kernel how much space is left on a mounted volume. du walks the directory tree and sums file sizes. They can disagree when a process holds an open file handle to a deleted file: du thinks the file is gone, df still counts the space.df says the disk is full but du shows much less. Why?
sudo lsof +L1 — the +L1 flag lists files with zero links (deleted) that are still open. Restart the holding process and the space comes back instantly.Will resizing the partition give me more space immediately?
Can VPS-SERVER HOST help me clean up?
Need more storage?
Resize your VPS in the client area and a bigger NVMe disk is attached in seconds — no migration, no downtime, no data loss.
Deploy a VPS Open a Ticket