Even if a server is set up properly from the start, a lot of unnecessary data still accumulates on it over time. Log files keep growing, backup copies remain after tests, and old archives sit unused for years. Docker is capable of storing unused images, containers, and volumes for months on end, gradually eating up free disk space on your server.
And at some point, the disk ends up almost full, causing services to start malfunctioning, updates to fail, and writing new data to become a problem.
Of course, for any administrator, the cause immediately becomes more than obvious. All that remains is to figure out which files or directories are taking up the most disk space, and then decide what to do with them: delete them, move them to another storage location, or enable automatic cleanup.
In this short article, we’ll share a couple of methods to help you identify the biggest "disk space hogs" on a Linux server and figure out which files are taking up the most space. Let’s get started!
Start with an overall assessment of the disk’s status
Searching for large files blindly isn’t the best idea; first, you should get a general idea of how full the file systems are and which partition is running low on free space.
To do this, run the following command:
df -h
It will display the size of each partition, the amount of used and free space, as well as the disk usage percentage in a human-readable format, thanks to the -h (for "human") argument. It often turns out that the problem isn’t in the root partition /at all, but, for example, in /var, where logs and application data accumulate, or in /home, if multiple users are working on the server and storing files downloaded from the internet in their home directories.
If a particular partition is nearly full, it’s best to focus your further investigation on that partition specifically - and don’t put this off or wait until the free space runs out completely. Once the disk is 90–95% full, certain services - such as mail servers, databases, or logging systems - may begin to malfunction or slow down significantly.
Which Directories Take Up the Most Space
Once you’ve identified which partition is full, you can determine exactly what is taking up all the free space. The easiest way is to start with the top-level directories and then drill down into the one that’s the largest.
To do this, run the following command:
du -h --max-depth=1 /
This will calculate the size of each top-level directory. Most often, the directories that take up the most space are /var, /home, /opt, /srv, or /tmp, although the situation on a specific server may be quite different.
Once you’ve found a suspicious directory, continue digging down one more level. For example, if /var is taking up the most space, then run the command:
du -h --max-depth=1 /var
This way, you can gradually narrow down to the directory causing the disk space shortage, and it usually takes only a couple of minutes.
If there are too many directories, it’s most convenient to sort them by size right away:
du -h --max-depth=1 /var | sort -hr
The largest directories will appear at the top of the list, so you won’t have to manually review the results by scrolling through the output.
This approach is especially useful when working with a VPS or a remote dedicated server via SSH, when you don’t have convenient graphical utilities on hand for analyzing disk usage.
Searching for the Largest Files
Once the problematic directory has been identified, you can move on to searching for the largest files within it - files you may have long forgotten about but that can sometimes take up tens of gigabytes.
The following command will do the trick:
find / -type f -size +500M
This will find all files larger than 500 MB. If necessary, you can easily change the threshold by specifying, for example, +1G or +100M.
If you know which directory or partition is running out of space - as we determined above - it’s best to limit the search to that specific directory:
find /var -type f -size +500M
This way, the command will run significantly faster, since it won’t have to scan the entire file system.
Sometimes you need not just a list of files larger than a certain size, but a ranking of the largest files. In this case, a combination of find, du, and sort will help:
find / -type f -exec du -h {} + | sort -hr | head -20
This command will list the twenty largest files on the server. Typically, this list includes old database backups, ISO images, archives, memory dumps, application logs, or other files that have long since become unnecessary but continue to take up disk space.
When Logs Take Up All the Space
Very often, ordinary logs are the culprits. They grow imperceptibly and slowly, but steadily, if log rotation isn’t configured on your server. As a result, after a few weeks or months of active server operation, a single log file can easily take up tens of gigabytes.
So, first, you should check how much space all the logs take up in the /var/log directory:
du -sh /var/log/*
If the server uses systemd, it’s a good idea to check the size of the system log:
journalctl --disk-usage
Sometimes, journald takes up several gigabytes, especially on servers with a high volume of events or with verbose logging enabled.
You can delete old entries, keeping only the logs from the last seven days:
journalctl --vacuum-time=7d
This cleanup frees up space without the risk of losing recent logs, which may still be useful for diagnostics. If your server has been running for a long time, it makes sense to check or configure logrotate right away; otherwise, even after cleanup, the problem will inevitably recur after a while.
Docker can also quietly fill up your disk
If your server uses Docker, you should check more than just regular files, since containers often leave behind data that continues to take up space even after a project is deleted. This usually includes old images, stopped containers, unused volumes, and build caches. They gradually accumulate, especially on servers where new application versions are regularly tested, and over time they take up disk space.
To see how much space each type of data is taking up, use the following command:
docker system df
It will show the total space occupied by images, containers, volumes, and the build cache.
If unnecessary data has indeed accumulated, you can delete it:
docker system prune -a
!!!BUT, it’s best not to rush into using this command. Before cleaning up, check which objects will be deleted, especially if your server is used in a production environment, since an old image is often the only way to quickly roll back an application after a failed update.
Useful Tools for Analysis
Standard Linux utilities are usually sufficient to find the cause of low disk space. But there are programs that make this task significantly faster. One of the most popular is ncdu.
After installation, simply run:
ncdu /
An interactive interface will open in a few seconds. You can navigate through directories using the arrow keys, immediately see their sizes, and quickly find the largest directories. If necessary, you can delete unnecessary files and directories directly from ncdu (although on production servers, it’s best not to rush and to first make sure they’re truly no longer needed).
Many system administrators use ncdu almost every day, since when you need to quickly figure out where the free space has gone, this interface is more convenient than running du, find, and sort one after another.
It’s best not to let the disk become full
A one-time cleanup frees up space, but it’s obvious that the problem will recur after a while due to the ongoing accumulation of data.
Therefore, it makes sense to set up regular server maintenance once and for all. Log rotation via logrotate, deleting temporary files, monitoring backups, and periodically cleaning up Docker and other systems that generate caches will prevent most such situations in the future.
It’s equally useful to monitor free disk space so that the server sends a notification in advance when a partition is, say, 80-85% full - this gives you enough time to respond and prevents you from having to deal with the problem after services stop running or the database goes into error mode. For servers hosting websites, CRMs, databases, and other critical services, this approach is usually much more cost-effective than any emergency cleanup.
FAQ
How often should you check free disk space on the server?
On production servers, it’s best to use a monitoring system that will alert you to low disk space in advance. If you don’t have one, periodically check the status of your disks using df -h, especially after updates and backups. The frequency depends on how heavily the server is used.
Can you simply delete the contents of /var/log?
You shouldn’t. Some services continue to use open log files. The safest approach is to use logrotate or clear the logs via journalctl.
Which tool is best for finding large files?
ncduis great for manual analysis. But if you need to search within scripts or automate the process, it’s better to use find, du and sort.
Why isn’t free space available after deleting a large file?
Most likely, the file is still open by some process. You can check this with the command lsof +L1. Usually, restarting the relevant service is sufficient.
Is it safe to use docker system prune -a?
Not always. This command deletes all unused images and other Docker data. Before running it, make sure you won’t need them for rollbacks or redeployment.
How can you avoid constantly running out of disk space?
Set up log rotation, keep track of backups, periodically clean up unnecessary Docker data, and monitor free disk space. This is much more effective than regular manual cleanup.
Conclusion
Finding the files that take up the most space is one of the first tasks any Linux server administrator faces. In most cases, a few standard utilities are enough to quickly identify the source of the problem and free up disk space.
But it’s even better not to wait until you run out of space - instead, make a few adjustments to prevent the problem from occurring in the first place. Regular monitoring, configuring log rotation, and periodically cleaning up unnecessary data allow you to avoid most such situations before they arise.
If your data volume is constantly growing, you should consider the option of expanding disk space when choosing a VPS or dedicated server. This will simplify infrastructure scaling and prevent you from having to urgently migrate services at the worst possible moment.
