Monitor and free disk space

2 min read07 November 2026

A full disk does more than block writes: databases may reject a transaction, logging stops and SSH can even fail to open a session. On a 20 or 40 GB VPS, headroom disappears quickly. The right method is to measure, identify the culprit, then delete with a backup within reach.

Measure usage

Bash
df -h
df -i
sudo du -xhd1 /var | sort -rh | head -20

df -h shows space per filesystem. df -i shows inodes: a disk can have free space and still be full because of millions of small files. du -x stays on one filesystem and avoids walking /proc or a network mount. Without -x, scanning / is slow.

Install ncdu for interactive exploration:

Bash
sudo apt install ncdu
sudo ncdu -x /

The usual suspects:

Path Content Action
/var/log System and application logs rotation, vacuum
/var/cache/apt Downloaded packages apt clean
/var/lib/docker Images, containers, volumes docker system df
/tmp Temporary files tmpfiles cleanup
/home and /srv Data and backups manual audit

Find the faulty file or process

Bash
sudo find / -xdev -type f -size +500M -ls 2>/dev/null
sudo lsof +L1

lsof +L1 lists deleted files still held open by a process. Their space is only freed when that process stops or reloads: a deleted log file can therefore keep filling the disk.

For Docker:

Bash
docker system df

It separates images, containers, volumes and build cache. Never delete a volume blindly: it may hold a database.

Free space without breaking things

Bash
sudo apt clean
sudo apt autoremove --purge
sudo journalctl --vacuum-size=200M
sudo systemd-tmpfiles --clean

Read the list proposed by autoremove before confirming. For unused images:

Bash
docker system prune

Without -a, this does not remove images used by an existing container. docker image prune -a and docker volume prune are more aggressive: check what will be removed.

For a log file held by a service, truncate instead of deleting:

Bash
sudo truncate -s 0 /var/log/my-app.log

The file descriptor stays valid and space is returned immediately.

Best practices

  • Back up before any bulk deletion, and check the mount point: rm -rf on a mistyped path does not forgive.
  • Set up logrotate for application logs.
  • Watch the 80% threshold: df --output=pcent / is enough in a cron script.
  • In a system container, space is limited by the disk allocated to the VPS; quotas can also cause write errors before df reports a full disk.

Verify

Bash
df -h
df -i
sudo du -xhd1 / | sort -rh | head

After cleanup, freed space must appear in df. If du and df diverge strongly, look for a deleted file still open with lsof +L1. Finally test the affected service: cleanup must not have removed its data.

Advertisement

Was this article helpful?

Read next