Disk space rarely disappears all at once. On most servers, it fills gradually — a growing log directory here, an expanding database there — until one day the disk is full and something breaks. The frustrating part is that when you’re only checking disk usage reactively, the problem always feels sudden, even though the warning signs were there for weeks.
Tracking disk space usage over time on your Linux server changes that completely. Instead of knowing only what’s used right now, you build a picture of how fast storage is actually growing. That context is what lets you act before there’s a problem — not after.
This guide walks through practical approaches for tracking disk growth trends on Linux, what to measure, and how to turn raw data into something actionable.
Why Point-in-Time Checks Aren’t Enough
Running df -h tells you how much space is used today. That’s useful, but it doesn’t tell you whether today’s 60% usage is stable, slowly creeping up at 2% per month, or accelerating after a recent deployment. Without the trend, the number doesn’t mean much.
Here’s the thing: most disk-related outages on small infrastructure are entirely predictable. The disk didn’t fill overnight. It filled over days or weeks, and nobody noticed because the team was only checking when something felt wrong. A simple growth trend would have shown the trajectory clearly.
Disk usage trends are especially important for:
- Database servers — MySQL data files and binary logs grow continuously
- Log-heavy applications — application logs, access logs, and error logs that aren’t rotated aggressively
- Backup destinations — incremental backups that stack up quietly
- Upload or media directories — user-generated content with unpredictable growth
How to Capture Disk Usage Over Time
The approach is straightforward: record disk usage at regular intervals and store those readings somewhere you can query or review them later.
Option 1 — Log to a File with Cron
The simplest method requires no extra tools. Add a cron job that appends a timestamped df snapshot to a log file:
0 * * * * df -h >> /var/log/disk_usage_history.log 2>&1This runs every hour and appends output to a log file. Over time you build a readable history. The downside is that parsing it later takes some work — you’re looking through plain text, not structured data.
A cleaner approach logs just the numbers in CSV format:
0 * * * * df --output=source,size,used,avail,pcent | tail -n +2 | while read line; do echo date_placeholder; done >> /var/log/disk_usage_history.csvThis gives you a structured file you can later import into a spreadsheet or feed into a simple script to identify trends.
Option 2 — Write to a Local SQLite Database
If you want something queryable without standing up a full monitoring stack, SQLite works well. A small Python script can handle both collection and basic analysis. Schedule it via cron, then query it whenever you want to see the trend for a specific mount point. You can pull weekly averages, calculate growth rate per month, or export to CSV for reporting.
Option 3 — Use a Lightweight Monitoring Agent
If you’re already running something like Netdata, Prometheus node_exporter, or collectd, disk metrics are almost certainly being collected. The gap is usually on the visualization and trend analysis side — the data exists, but nobody is looking at week-over-week or month-over-month growth patterns.
Pull that data into a regular review process. Even a simple weekly query against stored metrics gives you the trend information you need without any additional tooling.
What to Actually Measure
Raw disk usage numbers are a start, but more useful metrics for trend analysis include:
- Used space per filesystem — absolute growth in GB per week or month
- Percentage used — useful for alerting thresholds, less useful for growth rate
- Growth rate — how many GB per day or week is each filesystem growing?
- Projected fill date — at the current growth rate, when does this filesystem hit 90%?
The projected fill date is particularly useful. If your /var partition is at 55% and growing at 4 GB per week, you can calculate exactly when you need to take action — long before it becomes urgent.
A Real-World Example
Consider a small web server running MySQL. The team runs df -h during a weekly check and sees /var/lib/mysql at 62%. Looks fine. But nobody has been tracking growth.
Three weeks later, the server runs out of disk space overnight. MySQL stops writing. The site goes down.
If that team had been recording disk usage history, they would have seen that /var/lib/mysql was growing about 8 GB per week — binary logs were accumulating because the log rotation policy hadn’t been updated after a schema change doubled the write volume. At 62% with 8 GB/week growth on a 200 GB disk, they had maybe five weeks before hitting 90%. The trend would have made that obvious. But this is where it matters: the insight doesn’t come from a louder alert. It comes from looking at the growth pattern over time.
Turning Disk History Into a Regular Health Check
Collecting disk usage history is only half the job. The other half is actually reviewing it. A weekly summary that shows growth per filesystem — even if it’s just a table in a text file or spreadsheet — is enough to catch problems early on most small infrastructure setups.
Look for any filesystem that grew more than expected this week, growth rates that are accelerating compared to the previous period, and filesystems already above 75% that are still growing. You don’t need a complex dashboard to do this. You need consistent data and a habit of reviewing it.
Putting It Together
Tracking disk space usage over time on a Linux server doesn’t require expensive tools or complex infrastructure. A cron job and a log file can get you started today. The key is consistency — recording snapshots regularly enough to show real growth trends, and actually reviewing that data before a problem develops.
When disk growth becomes visible as a trend rather than a sudden surprise, you gain time to plan capacity expansions, adjust log rotation policies, or clean up large directories — on your schedule, not in the middle of an outage. You can explore how systematic disk trend tracking fits into a broader approach with Infrastructure Health Reporting.
