Disk saturation detection on Linux is one of those quiet server-health habits that pays off before anyone opens an incident channel. A disk usually does not become full all at once. Logs grow, backups accumulate, temporary files linger, uploads increase, and database files expand until a normal deploy or nightly job suddenly has nowhere safe to write.
For developers and small business owners, the goal is not to memorize every storage metric. The goal is to notice practical warning signs early enough to clean up, resize, archive, or investigate calmly. A simple weekly storage review can prevent the familiar “the site is down because the disk filled up” outage.
Why disk saturation is more than percent used
Most people start with free space, and that is a good first signal. But disk saturation can show up in a few different ways. A filesystem may be nearly full by bytes, out of inodes, slowed by heavy I/O wait, or filling much faster than expected.
That distinction matters. A server with 82% disk usage and predictable growth may be fine for weeks. A server at 65% that grew 20 percentage points since Monday may need attention today. Disk saturation detection on Linux works best when you combine the current value with the recent trend.
Start with filesystem capacity
The most useful first command is still:
df -hThis shows mounted filesystems in human-readable form. Pay close attention to production data paths such as /, /var, /var/log, database volumes, upload directories, backup mounts, and application-specific storage locations.
For script-friendly output, use:
df -PThe portable format is easier to parse because each filesystem appears in a predictable layout. A practical first threshold is to review anything above 80%, investigate anything above 90%, and treat 95% as urgent unless you have a clear reason and a tested cleanup plan.
Check inode usage before it surprises you
A disk can have free space available and still fail to create new files if it runs out of inodes. This often happens on systems that create many small files: cache entries, sessions, mail queues, rotated logs, package metadata, or tiny uploaded objects.
Check inode usage with:
df -ihIf inode usage is high, do not only look for giant files. Look for directories with huge file counts. A useful starting point is:
sudo find /var -xdev -type f | awk -F/ '{print "/"$2"/"$3}' | sort | uniq -c | sort -nr | head -20Run broad find commands carefully on busy systems, especially very large filesystems. If you already know the likely area, narrow the path first, such as /var/log, /var/cache, or an application upload directory.
Find fast-growing directories
When free space is shrinking, the next question is where the growth is happening. Start with a shallow summary:
sudo du -xhd1 /var 2>/dev/null | sort -hThe -x option keeps the scan on the same filesystem, which helps avoid accidentally walking into mounted backup or network volumes. Repeat the check for the directory that looks suspicious:
sudo du -xhd1 /var/log 2>/dev/null | sort -hLook for categories, not just individual large files. Common causes include verbose application logs, unbounded debug output, repeated failed jobs, local database backups, old deployment artifacts, image/video uploads, and temporary export files that never expire.
Watch disk growth as a trend
A single storage snapshot is useful during troubleshooting, but disk saturation detection becomes much more powerful when you keep a small history. You can record a daily or hourly snapshot without installing a full monitoring stack.
#!/usr/bin/env bash
set -euo pipefail
OUT="/var/log/disk-saturation-snapshot.log"
TS="$(date -Is)"
HOST="$(hostname -f 2>/dev/null || hostname)"
df -P | awk -v ts="$TS" -v host="$HOST" '
NR > 1 { print ts " host=" host " filesystem=" $1 " mount=" $6 " used_pct=" $5 " available_kb=" $4 }
' >> "$OUT"
df -Pi | awk -v ts="$TS" -v host="$HOST" '
NR > 1 { print ts " host=" host " filesystem=" $1 " mount=" $6 " inode_used_pct=" $5 }
' >> "$OUT"Save the script as /usr/local/sbin/disk-saturation-snapshot.sh, make it executable, and test it once:
sudo chmod 0755 /usr/local/sbin/disk-saturation-snapshot.sh
sudo /usr/local/sbin/disk-saturation-snapshot.sh
sudo tail -n 20 /var/log/disk-saturation-snapshot.logThen schedule it with cron:
15 * * * * /usr/local/sbin/disk-saturation-snapshot.shHourly is enough for many small business servers. During an active investigation, you can temporarily sample more often, then return to a calmer interval once the issue is understood.
Separate capacity problems from I/O pressure
Free space and inode checks tell you whether the disk is running out of room. They do not always tell you whether the server is waiting on storage. If users report slowness and CPU looks calm, check I/O wait:
vmstat 5 3The wa column shows time spent waiting on I/O. Occasional wait is normal, but sustained high I/O wait can point to storage latency, noisy neighbors, heavy database activity, backup contention, or a disk that is struggling under the current workload.
If iostat is available, it can add more detail:
iostat -xz 5 3Look for devices with high utilization, long await times, or unusual write pressure. If the server is cloud-hosted, also compare these findings to the volume type and provisioned IOPS or throughput limits.
Use alerts, but keep them practical
Disk alerts should help you act early, not wake everyone for noise. A practical setup for smaller environments might use:
- Warning at 80% filesystem usage for important mounts.
- Critical at 90% or 95%, depending on workload and growth speed.
- Warning when inode usage crosses 80%.
- Trend review when usage grows unusually fast week over week.
- Separate checks for backup destinations and log-heavy partitions.
The trend rule is important. A filesystem that jumps from 45% to 75% in two days is often more interesting than one that has been steady at 82% for months with plenty of planned headroom.
Common causes to investigate first
When disk usage rises unexpectedly, start with the areas most likely to grow silently:
- Logs: application debug logs, web access logs, database logs, and failed rotation jobs.
- Backups: repeated local backups, failed offsite syncs, and old database dumps.
- Temporary files: exports, uploads, image processing work directories, and package caches.
- Databases: binary logs, write-ahead logs, table growth, indexes, and abandoned test data.
- Containers: unused images, stopped containers, overlay storage, and verbose container logs.
Always confirm what a file or directory is before deleting it. If you are unsure, move slowly: archive first, check application ownership, confirm retention requirements, and document the cleanup.
Build a weekly storage review habit
The best prevention is a small recurring review. Once a week, check which filesystems are above threshold, which ones grew the fastest, whether inode usage is changing, and whether any log or backup directory needs a retention adjustment.
For small teams, this does not need to be a formal meeting. A short report with current usage, growth since last week, top growing paths, and recommended next action is enough. Over time, that history helps you resize volumes before emergencies, tune retention before logs explode, and catch application behavior changes early.
Summary
Disk saturation detection on Linux starts with simple commands: df -h, df -ih, du, vmstat, and, when available, iostat. The real value comes from reviewing those signals as a trend instead of waiting for a filesystem to hit 100%. Watch capacity, inode usage, growth speed, and I/O pressure together, then turn the findings into calm maintenance work before they become outages.
If you would rather not build and review this process by hand, DMCloud Architect can help. Our weekly Infrastructure Health Reporting highlights storage growth, disk-warning patterns, and other server-health signals so you can act before small issues become customer-facing problems.
