Disk Full on a VDS: How to Find What Ate the Space

How to quickly check if the disk is actually full

If a website or database on your VDS suddenly stops responding, and the logs show write errors, check free disk space first. The df -h command shows usage per partition in a readable format, with percentages and size in gigabytes.

df -h

If the / or /var partition shows 100%, you need to find the specific files and folders that ate up the space. A plain "disk full" message explains nothing about the cause — you have to find the cause separately, step by step.

How to find which folders take up the most space

The du utility calculates directory size recursively. To avoid scrolling through a long list, sort the output and limit the depth:

du -h --max-depth=1 /var | sort -rh | head -n 10

This gives you the top 10 heaviest subfolders inside /var. Repeat the command for the folder you found to go one level deeper and find the exact culprit. For interactive analysis, it is convenient to install ncdu — it builds a directory tree navigator right in the terminal:

apt install ncdu
ncdu /var

Deleted but open files: the invisible space consumer

Sometimes du and df show different disk usage numbers. The reason is a process holding open a file already deleted from the filesystem. Space is not freed until the process closes the file descriptor. You can find such files with:

lsof +L1

The output shows the process PID and the size of the deleted but still occupied file. This is often a forgotten application log after rotation without a service restart, or a stuck temporary file from Nginx or MySQL. The fix is simple — restart the specific service:

systemctl restart nginx

Logs and journals: the most common cause of overflow

On a VDS without configured rotation, logs grow for years. Check the size of the systemd journal and application logs in /var/log:

journalctl --disk-usage
du -sh /var/log/*

If the systemd journal weighs several gigabytes, limit its size and clean out old entries — a detailed breakdown of the parameters is in the article about journalctl and rsyslog. For other logs, set up rotation through logrotate so the problem does not come back every month.

Package caches, Docker, and old kernels

Besides logs, space is eaten by package manager caches and unused Docker images. On Ubuntu and Debian, clean the APT cache and remove old kernel versions:

apt clean
apt autoremove --purge

If Docker is running on the server, images and stopped containers can take up dozens of gigabytes. Check usage and clean up what is not needed:

docker system df
docker system prune -a

The docker system prune -a command removes all unused images, not just dangling ones — use it deliberately if there are other active projects on the server.

What to do if the disk is 100% full right now

When there is no space at all, even familiar commands sometimes fail with a write error. First delete the most obvious large file found through du, then deal with the cause. Do not delete files blindly in system directories — first check with lsof whether an active process is using them.

Final checklist:

• Set up free space monitoring in advance — see the article on VDS resource monitoring.
• Enable and check log rotation for all services.
• Limit the systemd journal size with the SystemMaxUse parameter.
• Regularly clean up unused Docker images and package caches.
• Keep the command du -h --max-depth=1 | sort -rh handy — it closes 90% of diagnostic cases.