Storage Capacity Planning: Forecasting Before You Run Out
Storage runs out at inconvenient moments because growth is measured after the fact rather than forecast. The information needed to see it coming is usually already being collected and simply not looked at.
Measure the rate, not the level
"We are at 70 percent" is a snapshot and tells you very little on its own. What matters is how fast that number moves.
A volume at 70 percent growing slowly has years left. One at 70 percent growing quickly may have weeks. The same figure, entirely different situations.
Record consumption periodically and look at the trend. Most monitoring already collects this, and the useful output is a date — when will this volume be full at the current rate — rather than a percentage.
Two things distort a naive trend line. Growth is frequently not linear, particularly where a business is growing or a new system has been added. And one-off events — a migration, a bulk import — can make a rate look worse than it is. Look at the shape, not just two points.
Performance degrades before capacity runs out
The part that catches people, because the volume still shows free space.
On flash, write amplification rises as free space falls. The controller has less room to work with when consolidating blocks, so it does more physical writing per host write — which slows things down and consumes endurance faster. Our endurance guide covers the mechanism.
On mechanical drives, a nearly full volume fragments more and the drive spends more time seeking.
On any filesystem, allocation gets harder as free space fragments.
Practically: treat "full" as meaningfully below 100 percent, and leave headroom deliberately rather than treating it as waste. Headroom is what keeps performance predictable.
Plan against lead time
The trigger point is not when the volume fills. It is when the volume fills minus how long it takes to do something about it.
That lead time includes: getting approval, which in some organisations is the longest part; sourcing the parts, particularly for discontinued platforms where availability is uncertain; scheduling a maintenance window; and the expansion itself, including any rebuild.
On a platform where drives take weeks to source and expansion needs an outage window, a three-month warning is not generous.
Set alerts at a level that gives you that lead time, not at 90 percent because it is a round number.
Expansion is constrained by the array, not the chassis
Where capacity plans meet reality.
Empty bays are not free capacity. Adding drives to an existing RAID group requires the controller to support online expansion, and the process restripes data across the new configuration — which takes a long time and degrades performance throughout.
Larger drives do not help within a group. A RAID group uses the smallest member capacity, so adding a larger drive to a group of smaller ones strands the excess. Our RAID guide covers this.
A new group is frequently the better answer than expanding an existing one — faster, lower risk, and it lets you use current drive capacities rather than matching old ones.
Interface and carrier still constrain you. Expansion drives must match the interface, form factor and carrier generation of the chassis. Our compatibility guide covers this by platform.
Usable is much less than raw
The arithmetic that makes projects come up short.
RAID overhead takes a share, hot spares come off the top, unit conversion reduces the figure again, and filesystem overhead takes more. The number a user sees can be well below what appeared on the purchase order.
Always plan backwards: start from usable capacity required, add growth headroom, apply the RAID multiplier, add spares, then convert. Our capacity guide covers it in detail.
Before buying capacity, look at what is stored
Frequently the cheapest expansion available.
Growth is often not the business generating more data. It is retention policies nobody reviewed, backups accumulating on production storage, log files with no rotation, old virtual machine snapshots, or duplicate copies from a migration that was never cleaned up.
Reviewing that before ordering sometimes removes the requirement entirely, and it almost always reduces it.
The related question: is this data on the right tier? Data that is rarely accessed does not belong on performance storage. Moving it to nearline capacity storage frees expensive space and costs far less than expanding the fast tier.
A simple routine
Record consumption per volume periodically. Convert the trend to a projected date rather than a percentage. Set alerts against your actual lead time. Review what is stored before ordering capacity. Check whether cold data belongs on a cheaper tier. And plan expansion as a new group rather than growing an existing one where the platform allows it.
Send us your current configuration and growth rate and we will help size the expansion and confirm drive compatibility.
Common questions
At what point should I plan expansion?
When the volume will fill minus your lead time — approval, sourcing, a maintenance window and the expansion itself. On platforms where drives take weeks to source, a three-month warning is not generous.
Does a nearly full volume affect performance?
Yes, before capacity actually runs out. On flash, write amplification rises as free space falls, slowing writes and consuming endurance faster. On mechanical drives, fragmentation increases seeking. Leave headroom deliberately.
Can I just add larger drives to my array?
Not usefully within an existing group — a RAID group uses the smallest member capacity, so the excess is stranded. Creating a new group is frequently faster, lower risk, and lets you use current drive capacities.
Why does my new array hold less than I ordered?
RAID overhead, hot spares, unit conversion and filesystem overhead each reduce it. Plan backwards from usable capacity required rather than forwards from a raw number.
What is the cheapest way to add capacity?
Look at what is stored first. Unreviewed retention policies, backups on production storage, unrotated logs and old snapshots frequently account for much of the growth. Then check whether cold data belongs on a cheaper nearline tier.
Send us your current configuration and growth rate and we will help size the expansion and confirm compatibility.
