Guides

Step-by-step tutorials and practical fixes for servers, systems, email, and daily technical work.
Linux Guides

How to Check Disk Usage on Linux

Check filesystem usage, find large directories, and troubleshoot Linux storage problems step by step.

Before you start

You need shell access to the Linux server.
It is best to start at filesystem level first, then move into directories step by step.
Do not delete files immediately just because they are large. Confirm what the path is used for first.

Step-by-step instructions

1. Check overall filesystem usage first

Start with df -h. This shows which mounted filesystem is actually running out of space. Do not jump into random directories before confirming which filesystem is full.

Command 
df -h
What to look for

Check the Use% column. If a filesystem is close to 100%, that is your first target. Also note the mount point because the full filesystem may not be the root filesystem.

2. Check the size of major directories

Once you know which filesystem is full, move into the relevant path and check large directories with du. This is how you narrow the problem from filesystem level to directory level.

Command 
du -sh /var/* 2>/dev/null
Why this helps

On many servers, heavy usage often comes from /var/log, /var/lib, backups, cache, or uploaded files. This quickly tells you which branch is worth drilling into.

3. Drill down into the heavy path

If one directory is clearly large, move one level deeper. Repeat this until you find the exact path responsible for the usage.

Command 
du -h --max-depth=1 /var 2>/dev/null | sort -h
Practical tip

This is usually more useful than checking everything recursively at once. You want to move from big picture to exact location without getting buried in noise.

4. Check common storage trouble spots

On real servers, the biggest space consumers are often logs, backups, cache, uploaded files, database storage, and mail queue data. Check the obvious operational paths before assuming something unusual is wrong.

Examples 
du -sh /var/log 2>/dev/null
du -sh /var/lib 2>/dev/null
du -sh /home 2>/dev/null
du -sh /tmp 2>/dev/null
What usually happens

A log file grows unexpectedly, backups stack up, cache is not cleaned, or application uploads become larger than expected over time.

5. Confirm before cleanup or deletion

Once you find the heavy path, confirm what it contains and why it exists. Cleaning up safely is part of the diagnosis process. Do not remove files just because they look large.

Command 
ls -alh /var/log
Important

A large file may be a live log, a database file, an application asset store, or an active queue. Confirm ownership and purpose before you clean anything.

Real example

A server shows / at 96% in df -h. You then run du -h --max-depth=1 /var and find that /var/log is unusually large. Drilling deeper shows that one application log has grown to several gigabytes because log rotation is missing or broken.

This is the kind of workflow you want: filesystem first, major directory second, exact path third, cleanup decision last.

Possible causes

  • Large log files caused by missing or failed log rotation
  • Backups accumulating in a local directory
  • Application uploads or generated assets growing over time
  • Cache or temporary files not being cleaned
  • Database storage growth under /var/lib
  • Mail queue or spool directories increasing unexpectedly

Common mistakes

  • Running only du without checking df first
  • Checking the wrong mount point and missing the real full filesystem
  • Deleting large files before confirming what they are used for
  • Ignoring hidden operational paths like logs, cache, spool, or backup directories
  • Assuming root filesystem usage and directory usage always match perfectly

Environment tips

  • Use df -h for quick filesystem status and du for path-level breakdown.
  • On busy production servers, redirect permission errors with 2>/dev/null when scanning wide paths.
  • Check whether log rotation, backup retention, and cache cleanup are working as intended.
  • If numbers do not make sense, verify mount points and consider whether deleted files are still being held open by processes.