A three year backup storage budget that consists of one purchase price and two years of silence will be wrong, and the error usually surfaces as an unplanned request rather than a forecast. Three years is the common horizon because it matches support terms and internal depreciation schedules, but the three year number is not the first year number multiplied by three. The line items behave differently over time, and several of the largest ones never appear on a quote at all.
The obvious approach is to take the winning quote, add a growth allowance, and call that the budget. It fails for a structural reason. A quote prices equipment or a license. It does not price the operation. Power draw, rack space, switch ports, support renewal in later years, the effort of moving data off the outgoing system, and the hours a small team spends administering the repository are all real spend, and none of them appear on the quote.
The second failure is timing. Capacity bought early sits idle until data arrives to fill it, and capacity bought late arrives after the backup window has begun to suffer. Which architecture is cheaper over its life is a separate question, and the comparison between an appliance and software defined object storage is not repeated here. What follows is the method for building the model, whatever sits underneath it.
A budget serves two audiences that want different things from the same inputs. Finance wants a figure per fiscal year that can be committed and defended. Operations wants to know how much capacity will be available on a given date. A model that produces only one of those views gets rewritten every time the other audience asks a question.
Building both from one set of inputs is what makes the model durable. The inputs are the capacity requirement as a curve over time, the unit cost of adding capacity, the recurring costs of running the equipment, and the one time costs at purchase and at retirement. Everything else is derived, so when a number changes the model is updated at the input rather than rebuilt at the output.
Start with the requirement, not with a product. The capacity the environment needs comes from protected data volume, change rate, retention and the number of immutable copies, and deriving it is its own piece of work; the mechanics are set out in backup repository sizing. For a three year budget the output has to be a requirement at the end of each year, because the difference between those figures drives the purchase schedule.
Second, translate the requirement into purchasable units. Quotes are written in different units, and raw capacity, usable capacity and capacity after data reduction are three different quantities. Until every option is restated in one unit, cost per unit cannot be compared and the budget inherits whichever unit the vendor preferred.
Third, attach recurring cost to the installed base rather than to the purchase event. Support, power, cooling and rack occupancy scale with what is running, not with what was bought in a given year. That distinction is what makes the later year figures come out correctly.
Fourth, add the one time costs at both ends of the life. Installation and integration sit at the start. At the end sits the effort of moving data onto whatever replaces it, which is rarely quick when long retention means the oldest restore points have to be carried forward. That decision is examined in the discussion of older restore points, and it belongs in the third year.
The pattern is consistent. The costs that get forgotten are owned by a different team or invoiced on a different cycle. Facilities pays for power and floor space, networking owns the switch ports, renewal arrives after the project closes, and staff time is never invoiced at all.
| Line item | Why it goes missing | Where the number comes from |
|---|---|---|
| Power and cooling | Billed to facilities, not the project | Draw of the proposed configuration, at the site rate |
| Rack space | Treated as free until the rack fills | Rack units consumed, and cost per unit at that site |
| Switch ports | Ordered separately by the network team | Port count and speed the configuration requires |
| Support renewal in later years | The first year is often bundled | Renewal terms in writing, including uplift after the initial term |
| Migration off the outgoing system | It falls in a later budget cycle | Volume to move, throughput available, and whose hours do it |
| Administration time | Never invoiced, so never counted | Hours per month for checks, patching, upgrades and support cases |
Power and rack cost deserve attention because they recur, they are rarely quoted, and they differ between designs that look equivalent. Reasoning about power and rack costs means asking for the draw and height of the configuration actually proposed.
Phasing is the decision about how much of the three year requirement to buy immediately. Buying all of it at the start is simple and usually the most expensive, since capacity purchased in advance is powered and supported long before it holds anything. Buying strictly to requirement is riskier, because a purchase cycle takes weeks and a repository that fills has immediate consequences.
The workable middle is to buy the first year requirement plus enough headroom to cover the lead time of the next expansion, then schedule later purchases against the requirement curve rather than the calendar. That turns headroom into a defined quantity rather than a proportion chosen by feel.
Some inputs cannot be known when the budget is written. Growth from workloads that do not exist yet, a retention change driven by a contract not yet signed, and the price of capacity two years out are all in that category. The honest treatment is to name each unknown, state the assumption standing in for it, and record what would trigger a revision.
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs, across a range of roughly 50 TB to 8.5 PB, with immutability provided through S3 Object Lock. For budget purposes the relevant consequence is that the cost structure separates into a software line and a hardware line, and the hardware line is priced by whoever supplies the servers and drives.
That separation changes where several of the line items above come from. Power draw, rack units and drive counts follow the server configuration rather than an appliance datasheet, so those figures can be requested from the hardware supplier and checked against the site. Network ports, physical location and operational access are budgeted alongside the rest of the infrastructure the organization already runs.
Capacity phasing works in the same terms. Adding capacity means adding nodes or drives against an existing deployment, so the purchase schedule can follow the requirement curve rather than arriving as one step at the beginning. Where a deployment is genuinely multi site or well beyond that capacity range, RING is the product that addresses it.
The model is worth revisiting on a fixed cadence rather than when someone asks. A quarterly comparison of actual consumption against the curve the model predicted is enough for most environments. Two or three quarters of that record turn growth from an assumption into a measurement.
Record, alongside the model, the unit every quote was normalized to, the protection scheme assumed behind the usable figure, the renewal terms including any uplift, the power draw and rack height of the installed configuration, and a named owner for every cost outside the storage budget. Those items make the budget defensible a year later.
Finally, write trigger conditions rather than dates. The next purchase becomes due when used capacity crosses a stated fraction of usable capacity, not in a nominated month, and the model gets revised when protected data outruns the curve, when retention changes, or when a renewal quote lands at a different number.