Disk space: where it goes

How to find what has filled up the disk, why a deleted but open file is dangerous, what is safe to clean, and why the usage ring in the control panel may show the wrong thing.

Updated August 23, 2026

Running out of space is an outage that looks like anything: the database won't write, the site returns an error, containers restart. A VDS disk ranges from 40 GB on the entry tier to 250 GB on the top tier, and it almost always fills up with the same things.

First commands

df -h
df -i
sudo du -x -h -d1 / | sort -h | tail -15

Don't skip df -i: you may have space but run out of inodes — then you get “disk full” with free gigabytes. The culprit is usually millions of small cache files.

Then drill down into the largest directory:

sudo du -x -h -d1 /var | sort -h | tail
sudo du -x -h -d1 /var/lib | sort -h | tail

The -x flag keeps the count within a single filesystem and doesn't wander into mounted directories.

Common culprits

What	How to check	What to do
Container logs	`du -sh /var/lib/docker/containers//-json.log`	Limit the size, see logs
Images and build cache	`docker system df`	`docker image prune`, `docker builder prune`
System journal	`journalctl --disk-usage`	`journalctl --vacuum-size=200M`
Old kernels in `/boot`	`df -h /boot`	`apt autoremove --purge`
Package cache	`du -sh /var/cache/apt`	`apt clean`
Copies left in place	`du -sh /backup`	Move them offsite, see another location
User uploads	`du -sh /var/www/uploads`	Storage outside or a larger disk

A deleted file that still takes up space

A classic puzzle: du shows 5 GB, df shows 30 GB used. That means the file was deleted, but a process still holds it open, and the space won't be freed until a restart.

sudo lsof +L1 | head -20

The output will show processes and sizes. The fix is to restart the culprit:

sudo systemctl restart <service>
docker compose restart <service>

Never free up space with rm on a log file that's in use. The right way is to truncate it: sudo truncate -s 0 /var/log/big.log. Deleting it will leave the space occupied and also cost you the log.

The usage ring in the control panel

On the “Overview” tab there's a disk usage ring. It's calculated via the guest agent qemu-guest-agent. If the agent is removed or not running, the data won't update — the panel will show the install command. To check inside the machine:

systemctl status qemu-guest-agent

The agent's readings and df -h should match. A discrepancy most often means that some space is taken up in a separately mounted partition — see partitions and filesystems.

Prevention

Set up a scheduled task with cleanup and an alert:

#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
  journalctl --vacuum-size=200M
  apt clean
  docker image prune -f
  echo "Disk is ${USED}% full" | mail -s "VDS: low disk space" you@example.com
fi

An 85% threshold gives you room to react. You can't wait for 100%: when the disk is full, some services won't even be able to write a log about what happened.

If there's no space at all

Free up a couple of gigabytes with quick measures: journalctl --vacuum-size=100M, apt clean, docker builder prune -f.
Find the real cause with the commands above — otherwise everything will repeat in a week.
If the data really has grown, you need to increase the disk by moving to a higher tier. Downgrading isn't available: the disk can't be shrunk.