How to Check and Free Up Disk Space on Linux

A full disk is one of the most disruptive server problems — databases stop writing, deploys fail, sometimes you can't even log in. The good news is it's usually easy to diagnose and fix once you know where to look. This guide shows how to find what's using your space and reclaim it safely without deleting something important.

Step 1: check overall usage

Start with the big picture:

df -h

Look at the Use% column for the filesystem mounted at /. If it's near 100%, that's your problem. If df says there's space but you still get "no space left," check inode exhaustion (millions of tiny files):

df -i

Step 2: find the space hogs

du shows what's consuming space. Work down from the top level:

sudo du -sh /* 2>/dev/null | sort -rh | head

Then drill into the biggest directory, e.g. /var:

sudo du -sh /var/* 2>/dev/null | sort -rh | head

Repeat until you find the culprit. Usual suspects: /var/log, /var/lib/docker, application data, and old backups.

{{SCREENSHOT}}

Step 3: clear the package cache

APT keeps downloaded .deb files. Clearing them is completely safe:

sudo apt clean
sudo apt autoremove --purge

autoremove also removes packages installed as dependencies that nothing needs anymore.

Step 4: prune logs

Logs grow endlessly if uncapped. Vacuum the systemd journal to a sensible size:

sudo journalctl --vacuum-size=500M

See the journalctl guide to cap it permanently. For traditional /var/log files, make sure logrotate is compressing and rotating them.

Step 5: clean up Docker (if you use it)

Docker is a notorious disk hog — old images, stopped containers, and dangling volumes pile up:

docker system df          # see what Docker is using
docker system prune -a    # remove unused images/containers/networks
docker volume prune       # remove unused volumes (careful with data!)

Be careful with volume pruning — it can delete data. See secure Docker containers for good container hygiene.

Step 6: remove old kernels

Ubuntu keeps old kernels, which eat /boot. autoremove usually handles them:

sudo apt autoremove --purge

If /boot specifically is full, this is often the fix.

Step 7: hunt down large files

Find files over 100 MB anywhere on the system:

sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

Common finds: forgotten database dumps, oversized logs, or leftover archives.

A trap: deleted-but-open files

If du and df disagree — df shows a full disk but du can't find the space — a process is likely holding a deleted file open. Find it and restart that service:

sudo lsof | grep deleted

Prevent it happening again

Once you've cleaned up, prevent recurrence: cap the journal, rotate logs, rotate backups, and set a disk-usage alert via monitoring so you hear about it at 80%, not 100%.

Automate cleanup so it never fills again

The best disk crisis is one that never happens. A small maintenance script run weekly keeps the usual culprits in check automatically:

#!/usr/bin/env bash
apt-get clean
apt-get autoremove --purge -y
journalctl --vacuum-size=500M
docker system prune -af 2>/dev/null || true
find /var/backups -name '*.gz' -mtime +14 -delete

Save it as /usr/local/bin/disk-maintenance.sh, make it executable, and schedule it with cron or a systemd timer to run weekly. Combined with proper logrotate configuration for application logs and a capped journal size, this keeps growth under control without you thinking about it. The one thing to be careful with is the Docker and backup-deletion lines — make sure the retention windows match your actual needs before enabling them, so you never prune something you'd want back.

Alert early and understand growth trends

Cleanup handles steady accumulation, but a runaway process — a log stuck in an error loop, an unbounded upload directory — can fill a disk in hours. That's why an alert at around 80% usage is worth setting up: it turns a 3am outage into a routine daytime task. Monitoring tools like netdata will fire on disk thresholds out of the box. Beyond a simple threshold, watching the *trend* is even more useful: a disk that's been climbing 1% a day tells you roughly when you'll run out, so you can plan a cleanup or a larger volume before it's urgent. Disk problems are almost always predictable in hindsight — the goal is to see them coming in foresight instead, and a little automation plus one good alert gets you there.

FAQ

df says full but du can't find the space — why?

Usually a deleted file still held open by a running process. Find it with sudo lsof | grep deleted and restart the offending service to release the space.

Is apt clean safe to run?

Yes — it only removes cached .deb downloads that apt can re-fetch if needed. It never removes installed software.

What usually fills up a VPS disk?

Logs, Docker images/volumes, old kernels, and forgotten backups or database dumps. Check /var/log and /var/lib/docker first.

How do I avoid running out again?

Cap the journal, rotate logs, prune Docker regularly, rotate backups, and set a monitoring alert at ~80% usage so you act before it's critical.

The disk-space troubleshooting flow

When a disk fills up, work through it in order and you'll find and fix it fast:

1. Confirm the problem: df -h (space) and df -i (inodes).
2. Find the hogs: sudo du -sh /* | sort -rh | head, then drill down.
3. Clear safe wins: sudo apt clean && sudo apt autoremove --purge.
4. Prune logs: sudo journalctl --vacuum-size=500M and check logrotate.
5. Clean Docker if present: docker system prune -a (careful with volumes).
6. Remove old kernels: usually handled by autoremove.
7. Hunt large files: sudo find / -type f -size +100M.
8. Check the trap: if df and du disagree, a deleted-but-open file is the cause — sudo lsof | grep deleted, then restart that service.

Once you've recovered the space, prevent a repeat: cap the journal, rotate logs and backups, schedule a weekly cleanup script, and set a monitoring alert at around 80% usage. Disk exhaustion is almost always predictable in hindsight — a little automation and one good alert let you see it coming instead of discovering it during an outage.

Staying on top of disk usage prevents a whole category of outages. Run on generous NVMe storage — see VPS plans, and add block storage when you need more room.