When that happens, your database can get corrupted, file uploads fail, caches break, and your entire site can go down. Suddenly, that project you spent months on is offline, and all eyes are on you to fix it. Understanding your Linux server’s disk space isn’t just a “sysadmin task.” It’s a fundamental, non-negotiable skill for any serious web creator. This guide will teach you how to monitor your disk space like a pro, from the basics to the advanced commands you need to pinpoint and solve problems quickly.

Key Takeaways

Here’s a quick overview of the essential commands and concepts we’ll cover.

  • df -h: Your go-to command. It shows the overall disk space usage for all mounted filesystems in a “human-readable” format (e.g., GB and MB).
  • du -sh *: The best command for finding large directories. It shows a “summary” (-s) in “human-readable” (-h) format for all files and folders (*) in your current location.
  • df -i: The “hidden” space checker. It checks inode usage. You can run out of inodes (from millions of tiny files) even if you still have disk space, which also breaks your site.
  • ncdu: A powerful, interactive disk usage analyzer. If you can install it, it’s the easiest way to navigate your filesystem and find what’s eating up space.
  • find: Your search tool for finding files by specific criteria, such as files larger than 1GB (find / -type f -size +1G).
  • Common Culprits: The most likely places to find space-hogging files are /var/log (log files), /var/www/html (your webroot, especially backup or cache folders), and /home (user files).

Why Monitoring Disk Space is Critical for Your Website

Before we jump into the commands, let’s establish why this is so important. A full disk isn’t a minor inconvenience. It’s a catastrophic failure that can lead to data loss.

Preventing Site Crashes and Downtime

The most immediate and painful symptom of a full disk is downtime. When the server’s root partition has zero bytes free, essential services can no longer write to their logs or pid files. The operating system itself can become unstable.

For your website, this means the web server (like Nginx or Apache) might fail. More critically, your database service (like MySQL or MariaDB) might crash. If it can’t write to its transaction logs or temporary files, it will stop, taking your entire site down with it.

Ensuring Successful Backups and Updates

This is a catch-22 that bites a lot of people. You need backups to protect your site, but backup processes themselves require disk space. A WordPress backup plugin like UpdraftPlus or BackWPup first creates a .zip archive of your site on the server’s disk before uploading it to an external location like Google Drive.

If your disk is 95% full and your site is 10GB, that 10GB backup file will fail to create. The process will error out, and you’ll be left with no backup, all because you didn’t have enough temporary space. The same goes for system updates (apt upgrade) or WordPress core, theme, and plugin updates. They all need to download and unpack files, which requires free space.

Maintaining Website Performance

Performance isn’t just about CPU and RAM. Disk I/O (Input/Output) is a major factor. When a disk is nearly full, the filesystem has a harder time finding contiguous blocks of space to write new data. This is called fragmentation, and it can slow down disk operations.

For a dynamic, database-driven website, this is bad news. Slow database queries mean slow page loads. For users, this means a sluggish site. For your business, it means higher bounce rates and lower conversions. Furthermore, caching systems (like W3 Total Cache or WP Super Cache) that write static HTML files to the disk will fail, reverting your site to slow, dynamic PHP processing for every single page load.

Identifying Security Issues

A full disk can also be a symptom of a security problem. If a hacker gains access to your server, they might use it to store large illegal files (warez) or create massive spam email queues.

More commonly, a runaway log file growing to 50GB in a few hours can be a sign of a Distributed Denial of Service (DDoS) attack or a bot aggressively scraping your site, with every single request being logged. Monitoring your disk space helps you spot these anomalies before they take you offline.

Understanding the Linux Filesystem: A Quick Refresher

To effectively manage disk space, you need to understand two or three basic concepts about how Linux organizes files.

Everything is a File (Even Devices)

In Linux, almost everything is treated as a file. A directory is just a special file that lists other files. Even your physical hard drive is represented as a file in the /dev directory (e.g., /dev/sda1).

This concept simplifies things. We can use the same set of tools to work with all of them. The entire system starts at the “root” directory, which is represented by a single slash: /.

Key Directories to Know

Every directory under / has a specific purpose. When hunting for large files, you’ll almost always end up in one of these:

  • / (root): The top of the entire filesystem.
  • /var: The “variable” directory. This is the most common place for disk space issues. It contains log files (/var/log), web server roots (/var/www), database files (/var/lib/mysql), and temporary files (/var/tmp).
  • /home: Contains the personal directories for each user on the system. If you give other users accounts, their Downloads or Documents folders live here.
  • /tmp: A general-purpose temporary directory. Files here are often (but not always) deleted on reboot.
  • /mnt or /media: Common locations where external drives (like USB sticks or network shares) are “mounted.”

What Are Filesystems and Mount Points?

This is the most important concept. You might have one physical 500GB hard drive in your server, but it could be partitioned into several “filesystems.”

  • A filesystem is a formatted partition that holds files (e.g., /dev/sda1).
  • A mount point is the directory where that filesystem is attached.

For example, your 500GB drive could be split:

  1. A 50GB filesystem for / (the root OS).
  2. A 450GB filesystem for /var/www (your websites).

If you run out of space on the 50GB filesystem, your OS will crash, even though you have 400GB free on the other partition! This is why simply knowing the “total disk space” isn’t enough. You need to know the space per mount point.

This is where our first command, df, comes in.

The Big Picture: Checking Overall Disk Space with df

The df command stands for “disk free.” It is the primary tool for checking the usage of all mounted filesystems. It tells you the high-level overview of all your “drives.”

Your First Command: df

If you just type df and hit Enter, you’ll get something like this:

Filesystem     1K-blocks      Used Available Use% Mounted on

/dev/sda1       51475068  40113836   8724788  83% /

udev               10240         0     10240   0% /dev

tmpfs             404184      1200    402984   1% /run

/dev/sdb1      460305884 210452312 226315668  49% /var/www

This output is functional, but not very friendly. The 1K-blocks column shows the size in 1-kilobyte blocks. Nobody wants to do that math.

Making df Human-Readable with df -h

This is the command you will use 99% of the time. The -h flag stands for “human-readable,” and it’s a game-changer.

Command: df -h

Output:

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda1        49G   39G  8.4G  83% /

udev             10M     0   10M   0% /dev

tmpfs           395M  1.2M  394M   1% /run

/dev/sdb1       439G  201G  216G  49% /var/www

This is so much better. Let’s break it down line by line.

  • Filesystem: The name of the underlying device partition. tmpfs is a temporary, in-memory filesystem.
  • Size: The total size of this filesystem.
  • Used: The amount of space currently used.
  • Avail: The amount of space still available.
  • Use%: The used space as a percentage. This is the most important column. You should start to worry when this hits 85-90%.
  • Mounted on: The directory where this filesystem is attached.

From this output, we can instantly learn:

  1. The main OS partition (/dev/sda1, mounted on /) is 49GB in size and is 83% full. This is getting high.
  2. The website partition (/dev/sdb1, mounted on /var/www) is 439GB and is only 49% full. There is no space problem here.

The problem is on the main drive, not the website drive. We are probably dealing with log files or system packages, not website media.

Advanced df Options for Deeper Insights

While df -h is your daily driver, a few other flags are essential for troubleshooting.

  • df -H: Use this if you prefer “metric” (powers of 1000) over “binary” (powers of 1024). This means 1G = 1000MB, not 1024MB. It can be slightly less confusing.
  • df -T: This shows the filesystem type (e.g., ext4, xfs, ntfs). This is useful for debugging or seeing if you’re working with a Windows partition.
  • df -i: This checks inode usage. This is the critical “hidden” disk space problem.

The Inode Problem: df -i

You can have a 500GB disk that df -h reports as “90% free” but your site is still crashing and giving “No space left on device” errors. How? You’ve run out of inodes.

What is an Inode? Think of a disk as a giant library. The books are your data (files). The inode is the card in the card catalog. Each inode is a tiny data structure that stores metadata about a file: who owns it, its permissions, and where to find it on the disk.

Every single file and directory requires one inode.

Why Can You Run Out of Inodes? You are allocated a fixed number of inodes when the filesystem is created. If you create millions and millions of tiny files, you can use up all your “index cards” (inodes) before you run out of “shelf space” (GB).

This is a very common problem with:

  • PHP session files (if not cleaned up)
  • Email queues (millions of tiny spam emails)
  • Badly configured caching plugins

How to Check Inodes: Command: df -i

Output:

Filesystem       Inodes   IUsed    IFree IUse% Mounted on

/dev/sda1       3276800 3276798        2  100% /

/dev/sdb1      28835840  584020 28251820    3% /var/www

Look at that!

  • Our main partition (/dev/sda1) has used 100% of its inodes (IUse%).
  • Even though df -h said it had 8.4GB of space free, it’s effectively full. It can’t create a single new file. This is our problem.
  • Our website partition (/dev/sdb1) is perfectly fine, using only 3% of its inodes.

Practical df Scenarios

  • How to check a specific filesystem: df -h /dev/sda1
  • How to check the disk a specific directory lives on: df -h /var/www/html (This won’t show the size of /var/www/html, but rather the size of the partition it lives on, which is /dev/sdb1 in our example).

Finding the Culprits: Pinpointing Large Files and Directories with du

df told us which partition is full (our / partition). Now we need to find out what is filling it up. For this, we use the du command, which stands for “disk usage.”

du works differently than df. It recursively walks through directories and sums up the sizes of all the files inside.

Your Second Core Command: du

If you just type du in a directory like /var, it will spit out the size of every single subdirectory in kilobytes. This is an overwhelming and useless flood of text.

The Essential du Flags: du -sh

Like df, du has a “human-readable” flag (-h). It also has a “summary” flag (-s) that, instead of showing every subdirectory, just shows you a single grand total for the directory you specify.

Let’s combine these.

Command: du -sh *

This is one of the most useful commands in Linux. It means:

  • s: Summarize the total size
  • h: in Human-readable format
  • *: for everything (all files and directories) in the current location.

Let’s cd to our /var directory (which lives on the full partition) and run it.

Command:

cd /var

du -sh *

Output:

4.0K    backups

12G     cache

4.0K    crash

16G     lib

4.0K    local

0       lock

22G     log

4.0K    mail

4.0K    opt

0       run

4.0K    snap

4.0K    spool

3.1M    tmp

Instantly, we have our suspects. The default files and directories are tiny (4.0K). But look at the big ones:

  • cache: 12GB
  • lib: 16GB
  • log: 22GB

Our 39GB of used space (df -h told us this) is almost entirely in these three directories.

Digging Deeper with du

  • du -h –max-depth=1: This is an alternative to du -sh *. It shows the size of the current directory (.) and all its children one level deep. It’s great for drilling down.
  • du -h –exclude=*.log: You can exclude certain file types.
  • du -a: This shows all files, not just directories.

Citation

As web creators, we often focus on the front-end, but a “black box” server is a liability. As Itamar Haim, a long-time web development expert, often says, “Knowing du and df is as fundamental to managing a modern WordPress site as knowing CSS. You can’t optimize what you can’t measure, and that starts with your server’s disk.”

The Power Combo: Sorting du Output

du -sh * is great, but what if you have 100 directories? The biggest one might not be obvious. We can “pipe” (|) the output of du directly into the sort command.

Command: du -h –max-depth=1 | sort -hr

Let’s break this down:

  1. du -h –max-depth=1: Get the disk usage, human-readable, for everything one level deep.
  2. | (the pipe): This magic character sends the output of the first command to be the input of the second command.
  3. sort -hr:
    • h: Sorts “human-readable” numbers (so it knows 2G is bigger than 100M).
    • r: Sort in “reverse” order (largest to smallest).

This single command is the number one workflow for hunting down space hogs.

Step-by-Step Example: Hunting Down a Bloated Log File

Let’s use this command to find our 22GB log problem.

Step 1: Start at the root of the problem partition.

$ cd /

$ du -h –max-depth=1 | sort -hr

55G     .

22G     ./var

16G     ./usr

12G     ./home

5.1G    ./lib

…

  • The total size . is 55G.
  • The biggest culprit is ./var at 22G.

Step 2: Drill down into /var.

$cd /var$ du -h –max-depth=1 | sort -hr

22G     .

21G     ./log

600M    ./lib

300M    ./cache

…

  • The total size . is 22G.
  • The vast majority is in ./log at 21G.

Step 3: Drill down into /var/log.

$cd /log$ du -h –max-depth=1 | sort -hr

21G     .

20G     ./nginx

500M    ./syslog

200M    ./mysql

…

  • Problem found. nginx is taking up 20G.

Step 4: Find the specific file.

$cd /nginx$ ls -lhS

-rw-r–r– 1 root root  20G Oct 29 09:30 access.log.1

-rw-r–r– 1 root root 300M Oct 29 09:50 access.log

-rw-r–r– 1 root root  50M Oct 29 09:50 error.log

  • (We used ls -lhS here, which lists files, human-readable, sorted by size S).
  • We’ve found the single file: access.log.1 is a 20GB monster. This is an old, rotated log file that can likely be deleted.

The Interactive Solution: Using ncdu for Easy Navigation

If you find the du | sort workflow a bit clunky, there is a much better way: ncdu.

What is ncdu?

ncdu stands for NCurses Disk Usage. It’s a command-line tool with a text-based graphical interface. It scans a directory and then lets you navigate through it with your arrow keys, sorted by size. It’s du and sort on steroids.

How to Install ncdu

It’s not installed by default, but it’s in all major repositories.

  • Debian/Ubuntu: sudo apt-get install ncdu
  • RHEL/CentOS: sudo yum install ncdu

Running ncdu

Just type ncdu and the directory you want to scan. It’s best to scan the partition you know is full.

Command: ncdu /

It will first scan the disk, which can take a few minutes. When it’s done, you’ll see an interactive screen:

— / ——————————————

   22.1 GiB [##########] /var

   16.2 GiB [#######   ] /usr

   12.0 GiB [#####     ] /home

    5.1 GiB [##        ] /lib

    …

You can use your arrow keys to move up and down. Press Enter to drill down into a directory. Press the left arrow to go back up.

You can also use these keys:

  • n: Sort by name
  • s: Sort by size (default)
  • d: Delete the selected file or directory (it will ask for confirmation).
  • i: Show information about the selected item.

ncdu is the safest, easiest, and most powerful way to find and clean up large files.

Other Useful Commands for Disk Analysis

df, du, and ncdu are the “big three,” but a few other commands are handy in your toolkit.

ls -lh: The Quick Look

We used this earlier. ls lists files, but with these flags, it’s more helpful:

  • l: Use a “long” list format (shows permissions, owner, size, date).
  • h: Show sizes in “human-readable” format.
  • S: Sort the list by file size, largest first. (Use ls -lhrS to reverse it).

This is great for seeing the largest files in a single directory.

stat: The File Investigator

The stat command gives you a brain dump of all metadata for a file. Command: stat /var/log/nginx/access.log Output:

 File: /var/log/nginx/access.log

  Size: 314572800   Blocks: 614400     IO Block: 4096   regular file

Device: 801h/2049d    Inode: 1310724     Links: 1

…

This shows you the exact size in bytes, how many blocks it’s really taking up on disk, and its inode number.

The find Command: Your Ultimate Search Tool

The find command is the most powerful search tool in Linux. It can scan the entire system for files matching complex criteria.

Finding Files by Size

This is its most useful function for us.

  • Find files over 1GB: find / -type f -size +1G
  • Find files between 100M and 500M: find / -type f -size +100M -size -500M

Explaining the syntax:

  • find /: Start searching from the root directory /.
  • -type f: Only find “files” (not directories d or links l).
  • -size +1G: Find files with a size greater than 1 Gigabyte.
  • -size -500M: Find files less than 500 Megabytes.
  • -size 100k: Find files that are exactly 100 Kilobytes.

Finding Files by Name

find /var/www -type f -name “*.log” (Find all files ending in .log inside your /var/www directory).

Finding Files by Time

find /tmp -type f -mtime +30 (Find all files in /tmp that were modified more than 30 days ago). This is great for finding old, stale files.

Combining find with Other Commands

The find command can execute another command on every file it finds.

  • Find and list: find /var/log -type f -name “*.log” -size +100M -exec ls -lh {} \; This finds all .log files over 100M and runs ls -lh on them.
  • Find and delete (THE DANGEROUS ONE): find /var/backups -type f -name “*.zip” -mtime +30 -exec rm {} \; This would find all .zip files in /var/backups older than 30 days and delete them. Double-check before you run any find … -exec rm command.

Common Culprits: Where Does All the Disk Space Go?

After years of managing WordPress servers, I can tell you that 90% of disk space emergencies come from these places.

Runaway Log Files

  • Location: /var/log/ (or /var/log/nginx/, /var/log/apache2/, etc.)
  • Problem: Every request to your site, every error, every system event gets written to a file. If your site is under attack or has a major PHP error, these logs can grow by gigabytes per hour.
  • Solution: Check this directory first. You are generally safe to delete rotated log files, which end in .1 or .gz (e.g., access.log.1, error.log.gz). For a live, active log file, you should truncate it (see next section). The long-term solution is configuring logrotate to automatically compress and delete old logs.

WordPress and CMS-Specific Issues

  • Location: /var/www/html/ (or your webroot)
  • Problem 1: Backups. Backup plugins that store the backups on the same server are a ticking time bomb. If you have 10 old backups, you are storing 10 copies of your site.
    • Solution: Check /wp-content/updraft/ or similar plugin-specific folders. Delete old backups and configure your plugin to only store backups externally.
  • Problem 2: Caching. Caching plugins like W3 Total Cache can generate hundreds of thousands of files.
    • Solution: Use the “Clear Cache” button in your WordPress admin. If that doesn’t work, you can rm -rf /wp-content/cache/ (be careful!). This is also a common source of inode exhaustion.
  • Problem 3: Media. Unoptimized PNGs, full-resolution JPEGs, and old video files.
    • Solution: Optimize your images. Check your wp-content/uploads/ directory with du -sh * to see which year/month folders are the largest.

User Home Directories (/home)

  • Location: /home/
  • Problem: If you or other users have accounts, their personal files (old site backups, large .zip files, desktop Downloads) live here.
  • Solution: Run du -sh /home/* to see which user is taking up the most space and investigate their directory.

Temporary Files (/tmp and /var/tmp)

  • Location: /tmp or /var/tmp
  • Problem: Aborted processes, file uploads, or session files can leave junk here.
  • Solution: It’s usually safe to delete files here, especially if they are very old. find /tmp -type f -mtime +7 -exec rm {} \; (delete files older than 7 days) is a common cleanup command.

Package Caches

  • Location: Varies, but accessible via a command.
  • Problem: Your system’s package manager (apt or yum) keeps a cache of all the packages you’ve downloaded and installed. This can grow to several gigabytes.
  • Solution:
    • Debian/Ubuntu: sudo apt-get clean
    • RHEL/CentOS: sudo yum clean all This is a safe and easy way to free up 1-2GB of space.

What to Do When You Find a Large File

You’ve used du and find and located a 30GB file: /var/log/nginx/access.log. What now?

To Delete or Not to Delete?

Be careful. Deleting the wrong file (like a database file from /var/lib/mysql) will destroy your website.

  • Safe to delete: Old log files (.log.1, .log.gz), old backups (.zip, .tar.gz), files in a cache directory (/wp-content/cache/), files in /tmp.
  • NOT safe to delete: Active database files, core system libraries, or any file you don’t recognize.

Safely Emptying a Live Log File

Do not run rm /var/log/nginx/access.log!

If a service is actively writing to a file, just deleting it with rm won’t free the disk space. The service holds an open “file handle,” and Linux won’t release the space until that service is restarted.

The correct way to empty a live log file is to truncate it.

Command: truncate -s 0 /var/log/nginx/access.log

This command instantly sets the file’s size to 0 bytes without deleting it. The service keeps its file handle and just starts writing to the new, empty file. The 30GB of space will be freed immediately.

Archiving and Compressing

If you find 10GB of old project files in /home/user/old-project/ that you don’t want to delete, you can compress them. Command: tar -czvf old-project.tar.gz /home/user/old-project/

  • This will create a single compressed file old-project.tar.gz.
  • A 10GB directory of text and code files can easily compress down to < 1GB.
  • You can then safely delete the original directory: rm -rf /home/user/old-project/.

Proactive Monitoring and Automation

You shouldn’t wait until your site is down to check your disk space.

Setting Up a Simple Bash Script

You can create a simple script that emails you when a disk gets too full.

Create a file named check_disk.sh:

#!/bin/bash

THRESHOLD=90

EMAIL=”[email protected]”

df -h | grep /dev/sda1 | awk ‘{ print $5 }’ | while read -r usage; do

  PERCENT=$(echo $usage | sed ‘s/%//g’)

  if [ $PERCENT -gt $THRESHOLD ]; then

    echo “Disk /dev/sda1 is at $usage! Host: $(hostname)” | mail -s “Disk Space Alert!” $EMAIL

  fi

done

You can set this script to run every hour using a cron job.

Using Monitoring Tools

For any professional or business-critical site, you should use a real monitoring service. Tools like Nagios, Zabbix, or cloud-based services like Datadog and New Relic can be configured to monitor disk space, inodes, CPU, and RAM, and send you alerts before it becomes a crisis.

Conclusion: Taking Control of Your Server

Your server is not a magical black box. It’s a system, and like any system, it needs to be monitored. By mastering these four simple commands—df, du, ncdu, and find—you’ve moved from being a simple “website builder” to a true “web professional.”

You now have the skills to diagnose and solve one of the most common and critical server problems. You can stop guessing, pinpoint the exact source of the issue, and fix it with confidence. This is what separates the amateurs from the experts.

Frequently Asked Questions (FAQ)

1. What’s the quickest way to see my overall disk usage? Use df -h. It gives you a human-readable summary of all mounted partitions, their total size, used space, and use percentage.

2. df and du show different sizes for the same directory. Why? df (disk free) reports on the filesystem as a whole. It shows how many blocks are allocated by the filesystem. du (disk usage) walks through and sums up the actual size of each individual file. They are measuring two different things and will almost never match perfectly. Trust df for the overall partition health and du for finding what’s inside a directory.

3. I deleted a huge file, but df -h still shows the disk is full. What’s wrong? A service is still holding that file open. You deleted the file’s name from the directory, but the data won’t be freed until the program writing to it (e.g., Nginx, MySQL) is restarted. You can use lsof | grep deleted to find the process. The correct way to free space from a live log file is to truncate it: truncate -s 0 /path/to/file.log.

4. What’s an inode, and why should I care? An inode is an “index card” for a file. Every file and directory on your disk needs one. You can run out of these “index cards” (from millions of tiny cache or session files) even if you still have gigabytes of “shelf space” free. Use df -i to check your inode usage.

5. How can I find the 10 largest files or directories? The easiest way is to use ncdu. But with du and sort, you can do this: du -h /home –max-depth=1 | sort -hr | head -n 10. This will show the top 10 largest directories in /home.

6. Is it safe to delete files in /tmp? Generally, yes, especially if they are old. /tmp is a temporary directory. A safe command is find /tmp -type f -mtime +7 -exec rm {} \;, which deletes files older than 7 days.

7. What’s the difference between df -h and df -H? df -h (human-readable) uses powers of 1024 (binary), so 1K = 1024 bytes, 1M = 1024K. df -H (metric) uses powers of 1000, so 1K = 1000 bytes, 1M = 1000K. This is why df -h might show 49G while df -H shows 53G for the same disk. Use whichever is more comfortable for you.

8. My /var partition is full. What’s the most likely cause? Almost certainly log files or database files. Use du -h –max-depth=1 /var | sort -hr to check. The problem will likely be in /var/log, /var/lib/mysql, or /var/cache.

9. What is ncdu and how is it different from du? du is a simple command-line tool that just outputs text. ncdu is an interactive tool that scans the disk and then provides a navigable interface. It’s much easier to use for “drilling down” into directories to find large files.

10. How can I clear my apt cache to free up space? If you are on a Debian-based system (like Ubuntu), run sudo apt-get clean. This is a very safe and easy way to free up space (sometimes gigabytes) used to cache downloaded packages. For RHEL/CentOS, use sudo yum clean all.