The date that matters is not the fill date
Everyone plans against the day the storage is full. The day that actually constrains you is earlier by the whole procurement chain: deciding, getting approval if there is any, waiting for hardware to arrive, and then getting it into service. That last part is the one people forget, because adding capacity to a running array is not an afternoon. Expanding, rebalancing or copying moves a very large amount of data, runs for days on a large array, and runs at reduced performance throughout.
Add those together and you get a notice period. Multiply the notice period by the growth rate and you get the amount of free space that must still exist on the day you decide. That is the trigger to watch. Everything else is bookkeeping.
Measure the rate, do not estimate it
Two readings of used space and the number of days between them is the whole measurement, and it takes a minute. What makes it unreliable is taking the readings too close together, because a short window measures whatever happened during that window. Import a project, run a large backup, or delete an old archive and a month of data will tell you a story about that event rather than about your growth.
Six months is a reasonable minimum and a year is better. Better still is a monthly reading kept in a text file, so the span is long and the intermediate points show whether the growth is steady, seasonal or lumpy. Lumpy is common and is not a problem to solve, only one to know about, because it means the average understates how close a bad month can bring you to the ceiling.
Linear or compounding, and why it matters so much
The default readings on this page, 32 TB to 41 TB over 180 days, can be described two ways that fit the data equally well. As a straight line it is 9 TB in six months, so 0.05 TB a day, and the 26.2 TB of headroom to an 80 percent target on 84 TB lasts about 524 days. As a compounding rate it is about 65 percent a year, and at that rate the same headroom lasts about 359 days. Same two readings, a difference of more than five months.
Neither model is correct in general and the data cannot choose between them. What can choose is knowing what the data does. Storage that grows because a fixed amount of new material arrives each month is linear: a camera system writing a constant bitrate, a household adding photographs at whatever rate the household takes photographs. Storage that grows as a proportion of itself is compounding: environments where new work generates derived copies of old work, where snapshots accumulate against a growing base, or where more capacity reliably attracts more use, which it does more often than anyone admits.
| Behaviour | Model that fits | Typical case |
|---|---|---|
| Fixed volume arrives per period | Linear | Camera recording, logging, a subscription of new material |
| New work derives from old work | Compounding | Editing, rendering, versioned datasets |
| Retention grows against a growing base | Compounding | Snapshots and backup repositories |
| Occasional large projects | Neither, until the window is long | Most home and small office storage |
The fill target is a decision, not a limit
The capacity figure is what the storage presents. The fill target is the level at which you consider it full, and it is well below 100 percent for reasons that are not squeamishness. Copy-on-write filesystems in particular slow down considerably as free space runs out, because finding contiguous space to write into gets harder, and a pool that is nearly full is one with no room to manoeuvre in: no space for a snapshot, no space to stage a copy, no space to absorb the one unusual week.
Where exactly that level sits depends on the filesystem, and the figure belongs to whoever documented yours rather than to this page. It is a field rather than a constant for that reason. What is general is that projecting growth against raw capacity rather than the target overstates how long you have by exactly the difference.
Where the capacity number comes from
The capacity field wants usable space, not the sum of what is printed on the drives, and those are far apart. Redundancy takes whole drives, and then the same bytes get counted twice in two different units. Drives are sold in decimal terabytes of a million million bytes; most systems report tebibytes of 1,099,511,627,776 bytes, which is 1,024 to the fourth power against 1,000 to the fourth. Dividing by that factor shrinks the number you see by 9.05 percent, which is why the 84 TB in the default above appears as 76.4 TiB on the same line. Nothing has been lost; it is the same storage counted in a bigger unit. The filesystem then takes its own overhead on top, and that part genuinely is gone. The storage array capacity calculator works that chain through from drive count to working space, and its output is what belongs in the capacity field here.
If what is growing is a backup repository rather than primary storage, the growth has a different driver: retention policy and change rate rather than new material, which the backup retention calculator sizes directly. And if the expansion you are planning would change how much data has to cross the network each night, the backup window calculator shows whether it still fits.
Questions people ask
How long should I measure growth over before trusting the number?
Six months at minimum and a year if you can wait, and the reason is that short windows measure events rather than trends. Import one project, delete one archive, or run one unusually busy month and a thirty day sample will confidently report a rate that has nothing to do with your normal behaviour. If you have not been recording, start now: a single line with the date and used space, once a month, in a text file, is enough to make every future version of this question answerable. If you need an answer today from a short window, take the projection as an order of magnitude rather than a date.
Why does the calculator give two different fill dates?
Because two readings are consistent with more than one growth model and the arithmetic cannot tell them apart. A straight line assumes a fixed amount arrives each month. Compounding assumes the growth is a proportion of what is already stored, so it accelerates. Both fit the readings you entered exactly, and they diverge afterwards, often by months. Deciding between them is a judgement about what drives the growth, not a calculation. Where they disagree sharply, planning against the earlier of the two dates costs you an early purchase and planning against the later costs you an overrun.
What should the fill target be?
Below 100 percent, and how far below depends on the filesystem, which is a question for its documentation rather than for this page. The general reason is that free space is not only storage, it is room to work: space to take a snapshot, to stage a copy, to absorb an unusual week, and on copy-on-write filesystems space to write efficiently at all rather than hunting for fragments. Whatever level you pick, project against it rather than against raw capacity, because the difference between the two is often a year of apparent headroom that does not exist.
Should I buy a bigger increment less often, or a smaller one more often?
The arithmetic favours larger increments because each expansion costs the same disruption regardless of size, and the calculator will show you exactly how many extra months a given increment buys. The counterweight is that capacity bought early sits idle and unused, and hardware bought later is generally cheaper per unit for the same money. Where that balance falls is a spending decision rather than a technical one. What is worth avoiding is the increment so small that you are back in the same conversation within the lead time of the next one.
Does deleting old data reset the projection?
It moves the starting point and usually does not change the rate, which is why cleanups buy less time than they feel like they should. Freeing 5 TB at a growth rate of 1.5 TB a month buys three months and then you are exactly where you were. That is worth doing when it delays a purchase past a budget boundary, and it is not a strategy. The exception is when the cleanup also removes whatever was generating the growth, such as retiring a snapshot policy or stopping a process that wrote derived copies, in which case take fresh readings afterwards because the old rate no longer describes anything.