Capacity Growth Runway Calculator

August 8, 2026

HomeServerBlog storage planning tool

Capacity Growth Runway Calculator

Estimate when a NAS, ZFS pool, media server, backup target, or virtualization datastore will hit its reserve threshold after growth, snapshots, compression, RAID layout, and planned expansion are applied.

1Capacity growth presets
2Runway inputs
TiB is what most operating systems report; TB is the drive maker label unit.
Used for practical overhead notes in the results and comparison grid.
If you enter raw drive count and size below, this estimates new usable capacity.
Usable pool size after parity or mirrors, before reserve planning.
Actual used data on the pool today, using the same unit as usable capacity.
Average monthly ingest before compression, dedupe, deletions, and snapshots.
Applies realistic compression and churn defaults for the workload type.
Savings applied to new monthly data before snapshot retention is added.
Extra retained blocks from snapshots, backups, deleted files, or changed VM disks.
Runway ends when usable capacity minus reserve is consumed.
Per-drive size for the next expansion shelf, vdev, or array replacement.
Available slots for adding drives without replacing existing media.
Growth Runway
0
months to reserve
Time before planned reserve is reached.
Effective Growth
0
TiB/month
Monthly write load after savings and churn.
Usable Headroom
0
TiB before reserve
Capacity available above the safety floor.
Expansion Runway
0
months after add
Estimated runway after planned bays are used.

Capacity breakdown

Usable capacity entered0
Current used capacity0
Reserve floor0
Growth allowed before reserve0
Estimated expansion usable0

Growth model

Current pool fill0%
Compression savings0%
Snapshot/version churn0%
Planning date cueNow
Runway status will appear here.
3Equipment and workload comparison grid
4-bay NAS2-4 disksGood for mirrors, RAIDZ1, light media, and family backups.
8-bay NAS6-8 disksBetter parity efficiency and one clean expansion step.
12-bay shelf2 vdevsCommon ZFS layout for RAIDZ2 pairs or mirror stripes.
All-flash poolhigh IOPSCapacity may grow slower, but VM churn can be high.
NVR arraysteady writeRunway is driven by cameras, bitrate, retention, and motion.
Backup targetversionsRetention policy often matters more than fresh ingest.
Object node4+2 ECCapacity math is efficient but needs failure-domain margin.
Cold archivelow churnLong runway if data is append-only and rarely rewritten.
4Reference tables
Protection layoutUsable estimateExpansion noteBest fit
Single disk or JBODN disksNo parity lossScratch, replaceable data
Mirror or RAID 150%Add pairsSmall NAS, VM storage
RAIDZ1 or RAID 5N-1 disksAdd full vdevMedia with backups
RAIDZ2 or RAID 6N-2 disksAdd full vdevLarge home NAS
RAIDZ3 triple parityN-3 disksWide vdevsBig cold archive
Stripe of mirrors50%Add mirror pairIOPS-heavy VM pool
WorkloadTypical growthCompressionChurn risk
Media library0.5-4 TiB/moLowLow snapshots
VM datastore0.2-2 TiB/moMediumHigh snapshots
Photo vault0.1-1 TiB/moLowModerate edits
Backup target0.5-5 TiB/moHigh variesRetention-heavy
NVR archive1-12 TiB/moVery lowRetention fixed
Logs and text0.1-3 TiB/moHighIndex overhead
Runway bandPlanning signalCommon actionRisk
24+ monthsHealthyTrack trend quarterlyForecast drift
12-24 monthsPlanPick expansion layoutDrive lead time
6-12 monthsOrder soonFree bays or add shelfRushed migration
0-6 monthsUrgentReduce retention nowPerformance drop
Already pastCriticalDelete, move, expandWrite failures
Expansion choiceCapacity effectOperational effectWhen to use
Add matching vdevLarge stepBalanced layoutZFS pools with bays
Replace all drivesAfter resilverLong rebuild windowSmall NAS full bays
Add mirror pairMedium stepEasy growthVM or SSD pool
Prune retentionImmediateLess historyBackups and NVR
Move cold dataImmediateTiered restoreArchive-heavy NAS
5Planning tips
Reserve free space intentionally.ZFS pools, Btrfs volumes, and many NAS appliances can slow down or fragment badly when they run near full. Treat the reserve threshold as a planning limit, not spare space to consume.
Separate ingest from retained growth.A camera, backup job, or VM snapshot may write a lot of data every month while retention rules delete some of it later. The calculator models the net retained growth that actually fills disks.

Capacity runway is a forecasting model. Recheck it after big imports, camera bitrate changes, retention changes, new VM snapshots, dedupe setting changes, or any drive layout migration.

That’s why you purchased your NAS, right? You were looking for a solution to store things permanently. Photos, movies, backups, you figured they’d fit into this solid box. Sure, maybe the storage in that box isn’t so strong (but the box itself should of last), right?

The problem: data expands more quickley than you think. And running out of space are never convenient. This usually happens when you’re watching a movie. It happens when you try to run a backup job, only to discover there is no place left to save new files.

Why You Need to Plan Your NAS Storage

How much data do I have? That’s often not what the question is; it’s the rate at which that space becomes unusable that concern us. Maybe you’ve got lots of room; you can see huge numbers like “usable capacity” and breathe easy. But ease isn’t something that happens right away: it has a time dimension. How long does your current usage pattern last until it eats up your buffer and make the system unsafe again?

Knowing when you’ll eat up your runway is planning for runway. You know when you won’t have enough disk tomorrow, next month, or next year. Your storage systems aren’t empty bucket getting filled by a constant drip of data. They’re complex ecosystems with their own dynamics: snapshots, compression, and more. For example, the filesystem may save space by compressing new files (if you run ZFS or Btrfs). However, it will hold multiple versions of your files around for weeks or months in case you accidentalley delete something and need to restore. Those snapshots consumes physical blocks on disk. And they won’t go away until your retention policy eliminate them.

To determine your actual growth rate, the calculator factors in your snapshot churn plus compression savings on top of your monthly ingest. One terabyte of new data don’t mean one terabyte of disk usage. Secondly, you’ll have to determine what level of “free space” you want to maintain. At 99% capacity, your disk will fragment, perform slowly, etc. To avoid that, most people maintains a buffer of around fifteen or twenty percent (so there’s enough room for the filesystem to breathe). Think of that as your runway floor. When you reach it, then you’re technically out of space.

This is where the tool shows you: how long do I have until I run out of space (in months)? Until then you’ve got your safety net. It makes you aware of the moment that plenty turns into panic.

Adding capacity doesn’t always scale smoothly. Depending on the layout (RAID 5? Is it RAIDZ2? RAID 6?), expanding storage can require purchasing several matching drive and rebuilding a virtual device from scratch. It is not a nice gradual increase, but more like a step up. The table of references details how different protection schemes sacrifice space for security. Even though you might have four blank bays in your server’s chassis, that’s not necessarily a direct translation into additional gigabytes if you need three or even four disks for triple parity. Resilvering data onto fresh drives take both time and money, which further muddies the math.

What kind of data is it? Before adding another server, consider whether your data will grow slow but steadily (e.g., a photo vault) or rapidly but briefly (e.g., virtual machines used for testing or updates). You can’t simply erase last month’s video if your retention policy requires you to keep it, yet video doesn’t compress very well. By contrast, snapshots accumulate on VMs and lead to rapid, temporary spikes in usage; without cleaning things up, this appear as permanent growth. Security cameras also grow relentlessly, and predictably.

We want to get off the scramble-reactive treadmill and onto the plan-ahead proactive one. When the tool informs you that you have six months of runway, go ahead and order some drives. Book out the migration for a weekend and perform some tests. Do it all on your terms, with no urgency. And if the tool reports back that you’ve got 60 months of runway, sweet dreams: your current architecture has legs.

That’s what capacity planning is about, beyond simple math… Managing risk under the guise of a spreadsheet. It’s learning how fast your data grows so you transform that flashing light from a warning siren to a dashboard indicator. No longer will you guess at when the well goes dry, but instead fill it up on your own timetable.

Capacity Growth Runway Calculator

Related posts

Leave a Comment