---
title: "What is taking up disk space on your VPS: how to find and free it | StreetHosting"
description: "Find what fills your VPS disk with df, du, ncdu and find, clean up the journal, apt and Docker, and reclaim space held by deleted files still open."
url: "https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps"
type: "page"
language: "en-US"
---

VPS · 9 min · Beginner

Published on Sep 28, 2026 · Updated on Sep 28, 2026

# VPS disk full: find the large files and free up space safely

A full disk takes down databases, stalls updates and makes applications fail without a clear error message. Here is how to find the culprit in a few commands and what you can delete without breaking anything.

By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team

[Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Security and hardening](https://streethosting.com.br/en/guides/topics/security) [Containers and Docker](https://streethosting.com.br/en/guides/topics/docker)

Summarize with:

[](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity")

Share:

[](https://x.com/intent/tweet?text=What%20is%20taking%20up%20disk%20space%20on%20your%20VPS%3A%20how%20to%20find%20and%20free%20it&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps "Share on LinkedIn") [](https://wa.me/?text=What%20is%20taking%20up%20disk%20space%20on%20your%20VPS%3A%20how%20to%20find%20and%20free%20it%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Ffind-what-uses-disk-space-on-vps "Share on WhatsApp")

For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps.md)

In this guide 8 sections

* [Start with df: what filled up](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#df-primeiro)
* [Heavy directories with du and ncdu](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#du-ncdu)
* [Large files with find](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#arquivos-grandes)
* [The usual suspects](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#suspeitos)
* [Docker: images, volumes and logs](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#docker)
* [Deleted file still open](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#apagados-abertos)
* [Keep the disk from filling up again](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#prevenir)
* [When cleaning up is not enough](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#quando-aumentar)

Quick answer

To find out **what is taking up disk space on your VPS**, run `df -h` to see which filesystem filled up, `df -i` for the inodes and `sudo du -xh --max-depth=1 / | sort -h` to drill down directory by directory to the culprit, or browse with `ncdu -x /`. The most common suspects are the journal, logs, the apt cache, Docker images and forgotten backups. If df reports a full disk and du finds nothing, look for deleted files that are still open with `sudo lsof +L1`.

## Start with df: what filled up[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#df-primeiro)

Before hunting for files, find out which filesystem is full and whether the problem is space or inodes:

`df -hT df -i Filesystem Type Size Used Avail Use% Mounted on /dev/vda1 ext4 39G 37G 1.6G 96% / tmpfs tmpfs 197M 1.1M 196M 1% /run /dev/vda15 vfat 105M 6.1M 99M 6% /boot/efi`

Look at the line mounted on /, the root, where the problem is in almost every case. The tmpfs lines live in memory and take no disk space. Notice that Size minus Used does not match Avail: by default ext4 reserves about 5% of the blocks for root, precisely so the system can keep working when a regular user fills the disk.

df -i shows the inodes, the entries the filesystem uses for each file and directory. If the IUse% column is at 100% with space to spare, the problem is millions of small files: PHP sessions, application cache, a mail queue or duplicated dependency folders. To find where they are, count inodes per directory instead of bytes: `sudo du --inodes -x --max-depth=1 / | sort -n`.

It pays to act early. With the disk full, the database stops writing, applications fail when creating temporary files and apt updates break halfway through, leaving packages half installed. If you are still trying to work out whether the slowness is the disk or another resource, the full checklist is in [checking CPU, RAM, disk and network on Linux](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux).

## Heavy directories with du and ncdu[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#du-ncdu)

du adds up the size of each directory. The trick is to look at one level at a time and always descend into the largest one:

`sudo du -xh --max-depth=1 / 2>/dev/null | sort -h sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h sudo du -xh --max-depth=1 /var/lib 2>/dev/null | sort -h`

The `-x` flag keeps du from entering other filesystems, such as /proc and mounted disks, which would only skew the count. The `-h` flag prints human-readable sizes, `--max-depth=1` limits it to one level and sort -h sorts the output, with the largest directory last. The redirect to /dev/null hides permission warnings from virtual directories.

If you are going to investigate several directories, ncdu saves time: it scans once and lets you browse the result with the arrow keys.

`sudo apt install -y ncdu sudo ncdu -x /`

Enter opens a directory, the left arrow goes back, the d key deletes the selected item (after asking for confirmation) and q quits. Directories are sorted by size, so the culprit is usually at the top.

Do not delete anything inside /var/lib/mysql, /var/lib/postgresql or /var/lib/docker through ncdu or with rm. These directories have an internal structure managed by the program itself, and removing files by hand corrupts the database or Docker. They are cleaned up with each tool's own commands, shown further down.

## Large files with find[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#arquivos-grandes)

Sometimes the culprit is not a directory full of small things but a giant stray file: an 8 GB database dump in root's home, a compressed backup nobody moved out, a forgotten debug log. find locates these files directly:

`# files over 500 MB, largest first sudo find / -xdev -type f -size +500M -exec du -h {} + 2>/dev/null | sort -rh | head -n 20 # files over 100 MB modified in the last 7 days sudo find / -xdev -type f -size +100M -mtime -7 -exec ls -lh {} + 2>/dev/null # forgotten dumps and compressed backups sudo find / -xdev -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.tar.gz" -o -name "*.zip" \) -size +100M -exec du -h {} + 2>/dev/null | sort -rh`

The `-xdev` flag plays the same role as the -x in du. `-size +500M` filters by size and `-mtime -7` by modification date. That second command is the best one when the disk filled up suddenly: the culprit is almost always recent.

## The usual suspects[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#suspeitos)

On an application VPS, space tends to disappear in the same places every time. Check them in this order:

| Where                      | What piles up                                             | Safe cleanup                                                    |
| -------------------------- | --------------------------------------------------------- | --------------------------------------------------------------- |
| /var/log/journal           | The systemd journal, which can grow past 1 GB             | Vacuum by size or by age and a permanent cap in journald.conf   |
| /var/log                   | Text logs and their rotated versions                      | Delete the old .gz files and empty the active log with truncate |
| /var/cache/apt             | .deb packages downloaded during updates                   | apt clean                                                       |
| /boot and /usr/lib/modules | Old kernels that stayed installed                         | apt autoremove with purge                                       |
| /var/lib/snapd             | Old snap revisions                                        | Remove disabled revisions and keep only two                     |
| /var/lib/docker            | Images, stopped containers, volumes, build cache and logs | Docker's own prune commands                                     |
| /home and /root            | Forgotten backups, database dumps and downloads           | Move off the VPS and delete                                     |
| /var/crash                 | Program crash reports                                     | Delete after reviewing                                          |
| /var/lib/mysql             | MySQL or MariaDB binlogs                                  | PURGE BINARY LOGS and a configured expiration period            |

The cleanup commands for the first three groups and for snaps:

`# journal journalctl --disk-usage sudo journalctl --vacuum-size=200M sudo journalctl --vacuum-time=2weeks # apt cache and old kernels sudo apt clean sudo apt autoremove --purge # snaps: list disabled revisions and keep only two from now on snap list --all | awk '/disabled/{print $1, $3}' sudo snap remove NOME_DO_SNAP --revision=NUMERO sudo snap set system refresh.retain=2`

The journal vacuum fixes it right away, but the journal grows back up to the default limit. To set a hard cap, define SystemMaxUse in journald.conf; that setting, along with logrotate for the text logs, is covered in [how to analyze logs on a Linux VPS](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs).

Avoid commands like rm on all of /var/log or all of /var/cache. Some services expect those directories to exist, and Nginx, for example, will not even start if its log directory is gone. Delete files, not the structure.

## Docker: images, volumes and logs[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#docker)

On a VPS running applications in containers, Docker is the most frequent culprit, because it piles up silently. Every deploy pulls a new image and the old one stays behind. The build cache grows with every build. Stopped containers keep their layers. And each container's log grows without limit in the default configuration.

`docker system df docker system df -v`

The output breaks down Images, Containers, Local Volumes and Build Cache, and the RECLAIMABLE column shows how much can be recovered in each group. With that in hand, clean up piece by piece:

`docker container prune # stopped containers docker image prune -a # images no container uses docker builder prune # build cache docker system prune # stopped containers, unused networks, dangling images and build cache`

Volumes deserve separate care: that is where database data, uploads and container configuration live. List them with docker volume ls, check which container each one belongs to and only then remove what is truly junk. Never run a volume prune automatically without knowing what is in there.

Container logs are stored as JSON files under /var/lib/docker/containers. To see the largest ones and enforce a limit:

`sudo sh -c 'du -sh /var/lib/docker/containers/*/*-json.log' | sort -h | tail # /etc/docker/daemon.json { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } sudo systemctl restart docker`

The limit only applies to containers created after the change. Recreate the existing ones, for example with `docker compose up -d --force-recreate`, so they start respecting the 10 MB per file. If you are just getting started with containers, the groundwork is in [installing Docker on Ubuntu on your VPS](https://streethosting.com.br/en/guides/vps/install-docker-ubuntu-vps).

## Deleted file still open[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#apagados-abertos)

The most confusing full-disk case: df says 100%, du adds up to far less and no large file shows up. The most common cause is a deleted file that some process still has open. Someone removed a 10 GB log with rm while the service was still writing to it; the name is gone, but Linux only releases the blocks when the last process closes the file.

`sudo lsof +L1`

The command lists open files whose name no longer exists, marked as deleted, with the process (COMMAND and PID), the descriptor (FD) and the size. The cleanest fix is to restart the service that owns the process with systemctl restart: once the file is closed, the space comes back immediately. If you cannot restart right now, empty the file through its descriptor, using the number from the FD column without the letter:

`# example: PID 1234 and FD 3w in the lsof output sudo truncate -s 0 /proc/1234/fd/3`

There are two more reasons for df and du to disagree. Files written to a directory before a disk was mounted on it stay hidden under the mount point, taking up space without showing up. And the ext4 block reservation mentioned at the start counts toward Used in df but does not belong to any directory.

To never fall into this trap again, change the habit: instead of deleting a log that is in use, empty it with `sudo truncate -s 0 /caminho/arquivo.log`. The process keeps writing to the same file, now empty, and the space is released immediately.

## Keep the disk from filling up again[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#prevenir)

Cleaning up only solves today's problem. These measures keep you from repeating the process next month:

* An alert when the disk passes 80% and when inodes pass 80%
* Journal cap set in journald.conf
* A logrotate rule for every application log
* Log size limit on Docker containers
* Backups shipped off the VPS instead of stored on it
* A monthly routine with apt autoremove and cleanup of old Docker images

The backup item deserves a highlight, because it is the most common way people fill their own disk: a script that generates one dump a day on the same VPS and never deletes any of them. Besides taking up space, that backup does not protect you against losing the VPS. The right way, shipping it off-site with automatic retention, is in [automated backups with restic and cron](https://streethosting.com.br/en/guides/vps/vps-backup-restic-cron). And for the disk alert to arrive before the problem does, see [how to monitor a VPS 24 hours a day](https://streethosting.com.br/en/guides/vps/monitor-vps-24-7).

## When cleaning up is not enough[](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#quando-aumentar)

If, after a thorough cleanup, the disk climbs back past 80% within a few weeks, the data is growing legitimately: database, user uploads, game server worlds. At that point the answer is more disk, not more housekeeping.

On StreetHosting VPS plans, all on NVMe, the disk grows with the plan: each step brings 10 GB of NVMe for every GB of RAM, from 20 GB on the entry plan to 640 GB on the largest, on both lines. The upgrade is done through the control panel, charges only the prorated difference for the billing cycle and requires a VM reboot. After it, you may need to grow the partition and the filesystem, as shown in [how to expand the disk on a Linux VPS](https://streethosting.com.br/en/guides/vps/expand-linux-vps-disk). Since shrinking a disk is not always possible, step up gradually instead of jumping straight to the largest plan.

| NVMe   | Xeon VPS                   | Ryzen 9 9950X VPS          |
| ------ | -------------------------- | -------------------------- |
| 40 GB  | R$ 43.00 (3 vCPU, 4 GB)    | R$ 66.00 (2 vCPU, 4 GB)    |
| 80 GB  | R$ 77.00 (6 vCPU, 8 GB)    | R$ 118.00 (4 vCPU, 8 GB)   |
| 160 GB | R$ 145.00 (9 vCPU, 16 GB)  | R$ 222.00 (6 vCPU, 16 GB)  |
| 320 GB | R$ 281.00 (15 vCPU, 32 GB) | R$ 430.00 (10 vCPU, 32 GB) |
| 640 GB | R$ 553.00 (24 vCPU, 64 GB) | R$ 846.00 (14 vCPU, 64 GB) |

When the data volume passes 640 GB, the next option is [dedicated servers](https://streethosting.com.br/en/dedicated), with 2 TB of NVMe starting at R$ 1,499.00 per month. To compare every VPS tier, with monthly price and specs, see the [VPS page](https://streethosting.com.br/en/vps).

In this guide

* [Start with df: what filled up](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#df-primeiro)
* [Heavy directories with du and ncdu](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#du-ncdu)
* [Large files with find](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#arquivos-grandes)
* [The usual suspects](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#suspeitos)
* [Docker: images, volumes and logs](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#docker)
* [Deleted file still open](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#apagados-abertos)
* [Keep the disk from filling up again](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#prevenir)
* [When cleaning up is not enough](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps#quando-aumentar)

## Frequently asked questions

Which command shows disk space on Linux?

df -h shows the size, usage and free space of each filesystem. To find out which directories are using that space, run sudo du -xh -d 1 / and drill into the largest one, or browse interactively with ncdu.

Why does df show the disk as full while du cannot find the files?

It is almost always a deleted file that some process still has open, such as a log removed with rm while the service was still writing to it. Run sudo lsof +L1 to find the process and restart the service to release the space.

Can I delete the entire /var/log directory?

No. Some services, like Nginx, will not even start if their log directory is gone. Delete only the old rotated files, empty the active log with truncate and cap the journal size with the SystemMaxUse setting.

How do I free up the space used by Docker?

Check what can be reclaimed with docker system df and use docker image prune, docker builder prune and docker container prune. Be careful with volumes, which hold database data. To keep container logs from growing without limit, set a maximum log size in daemon.json.

What are inodes and why do they run out?

An inode is the entry the filesystem uses for each file and directory. Millions of small files, such as sessions, cache or a mail queue, can exhaust the inodes before the space runs out. df -i shows the usage, and the error you get is the same as a full disk.

Next step

See VPS plans

Root VPS in Brazil with NVMe and Anti-DDoS.

[See VPS plans](https://streethosting.com.br/en/vps)

[See Xeon VPS Xeon VPS for steady workloads, automation and long-running projects.](https://streethosting.com.br/en/vps/xeon)

## Related guides

[VPS Intermediate How to expand a Linux VPS disk after an upgrade The upgrade grows the virtual disk, but the partition and filesystem can stay at the old size. Learn how to check whether the image already expanded on its own and how to grow ext4, XFS and LVM with the VPS running. 9 min Read guide](https://streethosting.com.br/en/guides/vps/expand-linux-vps-disk) [VPS Intermediate How to analyze Linux VPS logs with journalctl and grep Almost every server problem leaves a trace in some log. See where each record lives on Ubuntu, how to slice by service, time and severity, and how to keep logs from filling the disk. 9 min Read guide](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs) [VPS Intermediate How to install Docker on Ubuntu 22.04 or 24.04 on a VPS (straight to the point) A stable Docker install on an Ubuntu VPS depends on the right package source and step by step validation. In this guide you set up the official repository, install Engine and Compose, test the daemon and apply basic security measures before deploying applications. 3 min Read guide](https://streethosting.com.br/en/guides/vps/install-docker-ubuntu-vps)

[← Back to the Guide Center](https://streethosting.com.br/en/guides)
