Running out of disk space on a Linux server rarely happens all at once. It builds up gradually over days, weeks, sometimes months until one morning a service fails to write a log file, a database cannot create a temp table, or a backup job silently stops. By the time the alert fires, you are already in recovery mode.
Storage capacity planning for Linux is the practice of watching disk usage trends over time and using that data to make informed decisions before problems happen. It does not require expensive tooling or a full observability stack. It requires consistency: regular checks, historical data, and a reasonable forecast.
This guide walks through the core concepts and practical steps for building a solid capacity planning habit, whether you are managing two servers or twenty.
Why Disk Capacity Planning Is Easy to Ignore
Most Linux administrators have a rough sense of how full their disks are. The problem is that a rough sense is not enough when growth is gradual. A filesystem that is 60% full today might hit 95% in six weeks if a log rotation script breaks, user uploads spike, or a database table starts growing faster than expected.
Alert fatigue makes this worse. If your monitoring system pages you when disk hits 80%, 90%, and 95%, you start tuning it out or raising the threshold just to stop the noise. Either way, you lose visibility into the trend. You are reacting to thresholds instead of watching what is actually happening over time.
Disk problems are almost always predictable. The data is there. The growth pattern exists. Most of the time, you just have not been collecting or reviewing it consistently enough to act early.
Start With What You Already Have: Core Linux Disk Commands
Before adding any new tools, it is worth getting comfortable with the built-in utilities that give you disk usage data on any Linux system.
df - filesystem-level view
df -h gives you a summary of all mounted filesystems: total size, used, available, and percentage used. This is the starting point for understanding where you are right now.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 38G 12G 76% /
/dev/sdb1 200G 140G 60G 70% /data
tmpfs 3.9G 1.2G 2.7G 31% /runThe key number here is the trend. A snapshot is useful; a history of snapshots is what makes capacity planning possible.
du - directory-level breakdown
du -sh /path or targeting specific directories helps you understand what is using space, not just how much total space is used. This is critical when you are trying to figure out why a filesystem is growing faster than expected.
du -sh /var/log /var/lib/mysql /home /opt
4.2G /var/log
18G /var/lib/mysql
2.1G /home
6.4G /optIf you are running MySQL and /var/lib/mysql is growing by 1 to 2 GB per week, that tells you exactly where to focus your linux disk capacity planning.
Building a Simple Disk Usage History
The single most useful thing you can do for storage capacity planning is collect disk usage data regularly and store it somewhere you can query later. You do not need a time-series database or a dashboarding system to start.
A basic cron-based logging approach
Add a cron entry that saves df -h output to a log file each day:
# Collect disk usage daily at 6am
0 6 * * * /usr/bin/df -h >> /var/log/disk_usage_history.logAfter a few weeks, you have a simple time series you can review. You can search for a specific filesystem and spot the growth pattern in the output. This is low-tech, but it works. Many small infrastructure teams skip this step entirely and then scramble when a disk fills up.
Structured logging with timestamps
A slightly cleaner approach uses a shell script that prefixes each line with the date. Once you have that running, you can open the output in a spreadsheet, filter by filesystem, and immediately see a usage curve developing over time.
Forecasting Disk Growth: The Practical Approach
Once you have two to four weeks of data, you can start making reasonable forecasts. The math does not have to be complicated.
Simple linear projection
If your /data filesystem used 100 GB four weeks ago and uses 128 GB today, it is growing at roughly 7 GB per week. At that rate, you will hit around 156 GB in four more weeks and roughly 184 GB in eight weeks. With 200 GB total, that gives you about ten weeks to act before things get critical. That is enough lead time to add storage, clean up old data, or archive files before anything breaks.
Linear growth is not always accurate since workloads spike and retention policies change, but it gives you a meaningful baseline for disk forecasting on Linux.
Watch for acceleration
More concerning than steady growth is accelerating growth. If disk usage grew by 5 GB last month but 12 GB this month, something changed. A new job started writing more data, a log file stopped rotating, or a backup started being retained longer. Growth acceleration is a signal worth investigating immediately, not after it fills the disk.
What to Actually Track in a Capacity Plan
A practical storage capacity plan for a Linux server does not need to be a complex document. At minimum, it should answer three questions:
- How much space is currently used? Snapshot from
df - How fast is it growing? Derived from your usage history
- When do you need to act? Projected date when usage hits your threshold, say 85%
For multi-server environments, consolidate this into a simple weekly review. Even a spreadsheet with one row per server per week gives you enough data to spot which filesystems need attention soon and which have runway for months.
Pay extra attention to /var/log since log rotation failures cause fast unexpected growth, database directories like /var/lib/mysql or /var/lib/postgresql where growth follows data and query patterns, /tmp which is often overlooked and can fill quickly under certain workloads, and backup storage paths where retention policy drift can quietly consume large amounts of space.
Wrapping Up
Storage capacity planning on Linux is less about sophisticated tooling and more about building a consistent habit: collect disk usage data, review it regularly, and plan disk growth on your server before it becomes a crisis. A simple cron job and a log file are enough to get started. The goal is to stop discovering full disks during incidents and start catching them three weeks out, when you still have options.
If you want visibility into how disk usage and other infrastructure health metrics trend over time across your servers, you can learn how this fits into a broader approach through Infrastructure Health Reporting.
