Immutability changes capacity planning in one specific way: the usual response to running out of space stops working. In a conventional repository, a capacity problem can be relieved by deleting older copies. In an immutable repository, those copies cannot be removed until their retention period expires, by design, and that design is the whole point of having it.
The consequence is that an immutable repository has to be sized for the steady state it will reach rather than for the volume it starts at, and the steady state is reached only after a full retention cycle has elapsed. A repository that looks comfortable in month three can be full in month fourteen with no change in backup volume at all.
Two effects combine. The first is that consumption keeps rising until the first copies begin to expire, which happens one full retention period after the repository starts filling. Until that point, every backup adds and nothing is released, so the curve is monotonic and an early trend line understates the endpoint.
The second is that the usual emergency levers are unavailable. Deleting old full backups, trimming a copy of a large but unimportant system, or shortening retention to release space all work in a conventional repository and none of them work here. A retention reduction applied today does not release anything already locked.
That is not a flaw. It is the property that makes an immutable copy worth having, since it is the same property that stops an attacker or a mistake from removing the copies. It simply means the forecast has to be right the first time, with headroom for the cases where it is not.
The calculation needs five inputs, and most environments can supply all of them from existing backup reports.
| Input | Where to get it | What it drives |
|---|---|---|
| Full backup size | Backup reports, after deduplication and compression | The base volume per full copy |
| Incremental or change rate | Daily change volume across the protected estate | Growth between fulls |
| Retention period per policy | Backup policies and compliance requirements | How long each copy occupies space |
| Protected data growth rate | Year on year growth of source systems | The slope that compounds across the cycle |
| Number of copies retained | Policy, including any long term monthly or yearly copies | Multiplier on everything above |
Multiply through to the end of one full retention cycle, then add the growth of the source estate over that same period, since the copies taken in month twelve protect more data than the copies taken in month one. Organizations that skip the second step usually undershoot by a wide margin.
Long term retention copies deserve separate treatment. A monthly copy held for seven years is a small recurring addition that accumulates into a large fixed base, and it behaves differently from the daily rotation. Modelling the two separately makes the forecast easier to explain and easier to revise.
Four assumptions account for most of the error. Deduplication ratios are assumed to hold as the estate changes, when a new workload with different data can move them significantly. Growth is assumed to be linear when a single new system or a new regulatory requirement can step it. Retention is assumed to stay where it is, when audit findings and contract changes routinely extend it. And the copies are counted once when a second immutable copy at another location doubles everything.
There is also a quieter effect in object storage repositories. Where versioning is enabled, previous versions and incomplete multipart uploads can occupy capacity that does not appear in a simple object listing. In an immutable repository these accumulate under the same locks, so they should be included in the forecast rather than discovered during a capacity review.
The practical response is headroom expressed as time rather than as a percentage. Knowing that the repository has nine months of runway at the current trajectory is more actionable than knowing it is 64 percent full, because it maps directly onto procurement lead times.
Every conversation about extending retention is a conversation about capacity, and it is worth making that explicit at the time rather than afterwards. Extending a policy from 30 to 90 days does not add a third; it adds whatever the change rate produces over the additional 60 days, compounded by growth, and it applies to every system in scope.
The reverse deserves care as well. Shortening retention releases nothing already locked and can create an exposure if the shorter window no longer reaches back beyond a plausible intrusion period, which is the balance that dwell time sets for retention. Capacity pressure is a poor reason to shorten a window that was chosen for recovery reasons, and where it is the only option the tradeoff should be recorded as a risk decision.
Tiering is often the better answer. Older immutable copies that are unlikely to be restored can sit on lower cost capacity while remaining locked, which relieves pressure without weakening the control.
Scality RING and ARTESCA present S3 targets with S3 Object Lock, so backup software can write copies that cannot be deleted or altered for their retention period. Capacity grows by adding nodes, which means the repository can be extended while it is in service rather than replaced when the forecast proves conservative, and the expansion does not require moving the locked copies.
That incremental growth path is what makes an immutable design practical over a long retention cycle, because it allows a forecast to be corrected without a disruptive migration. ARTESCA suits mid-sized repositories where the estate is measured in the tens or hundreds of terabytes, and RING covers the larger end where retention across a big estate reaches into petabytes. In both cases the number to plan against is the steady state after a full cycle, with the second copy counted if one exists.
A forecast made once and filed is a forecast that will be wrong by the time it matters. Compare the actual consumption curve against the model quarterly, and treat a divergence as a signal to investigate rather than to adjust the model. The cause is usually a change somebody made for good reasons without realizing it reached the repository: a new workload, a retention extension, or a second copy added for resilience.
Track runway in months alongside utilization, and set the alert threshold at the point where procurement and installation could still complete comfortably. In an immutable repository, the moment capacity runs out is the moment backups stop, and stopping backups to relieve a capacity problem is the one outcome the whole design exists to avoid.