Two backup storage options are compared on hardware and software, a decision is taken, and the equipment arrives in a room somebody else pays for. The rack units it occupies, the power it draws, the heat it adds and the switch capacity behind its ports are all real costs. In a colocation contract they appear as line items. In an owned room they are usually invisible, which is not the same as absent.
The asymmetry distorts comparisons in a predictable direction. A colocation quote states the cabinet charge and the power commitment, so those numbers land in the model. An owned room absorbs the same costs into a facilities budget nobody on the project reads, so that option looks cheaper by exactly the amount never counted.
The fix is not an industry average. Rack and power costs vary by building, by contract and by how much headroom the electrical design still has, so a figure borrowed from a published study will be wrong in an unknown direction. The work is to obtain the numbers for the specific site, which is a short set of questions to people who already know the answers.
Rack units and what a unit actually costs
The first figure is the easy one: how many rack units the solution occupies, counted as it will be installed rather than as the density sheet suggests. That includes blank space left for airflow, the shelf for any gateway or management server, top-of-rack switches if the deployment brings its own, and cable management.
Converting units to cost differs by tenure. In colocation there is a written rate for a cabinet or part of one. In an owned room the honest question is whether the space is genuinely free. If there are empty cabinets and spare electrical capacity, the marginal cost is close to nothing. If the room is full, it is the next expansion divided across what that expansion provides, a large number hiding behind a small one.
Footprint compounds over a refresh cycle. A platform that grows by adding nodes consumes units on a schedule, and whether the room has space in year three is a different question from whether it has space today. That input helps decide whether a platform is expanded or replaced when it reaches its limit.
Power at idle and power during a restore
Power is where the guessing happens, because the number printed on a server is the rating of its supplies rather than what it draws. A backup target spends most of its life neither idle nor busy: ingesting a nightly window, running background verification or repair, otherwise waiting. That steady draw is what the annual energy cost is built from, and it is measurable.
The peak is a separate figure with a separate use. A large restore, a rebuild after a failure, or a migration reads across every device at once and draws more than a nightly backup does. Being rare, the peak does not drive the energy bill, but it does drive the circuit design, and a circuit sized for the average trips during the recovery it was bought for. Planning for a recovery that touches many systems at once is therefore also an electrical question.
Both come from the same place: metered outlets on the rack power distribution units, read over a period long enough to include a weekend and a full backup cycle. Where a restore test is already scheduled, reading the meters during it produces the peak figure at no extra cost.
Cooling, circuits and the redundancy assumption
Cooling follows from power, since essentially all the electricity drawn is rejected into the room as heat. Facilities converts that to a cost on whatever basis the building uses, and the useful thing a storage project can hand them is a watt figure they trust rather than a capacity figure to translate.
| Facility line item | Why it gets missed | How to obtain the figure for this site |
|---|---|---|
| Rack units and cabinet space | An owned room raises no internal charge for space | Colocation rate card, or the cost of the next cabinet build |
| Steady power draw | The supply rating is read as the consumption | Metered outlet readings across a full week |
| Peak draw during restore or rebuild | Sizing considers the ingest path, not the read path | The same meters during a restore test |
| Cooling load | Treated as part of the building rather than the deployment | Hand the measured watt figure to facilities to price |
| Circuit headroom and redundancy | A dual-fed cabinet has to survive on one feed | Breaker ratings, the derating rule in force, and draw per feed |
| Switch ports and the uplinks behind them | Ports are counted, aggregate capacity is not | Free ports, uplink utilization, and whether a new switch pair is implied |
The redundancy row most often turns a small addition into a project. A cabinet fed by two supplies is designed so either one can carry the whole load when the other fails, which means the usable capacity of the pair is the capacity of one. Equipment that fits comfortably across two live feeds can still exceed what one feed would carry, and that is discovered during maintenance rather than installation. Continuous loads are derated by electrical code as well, so the breaker rating is not the available capacity, and the question for the facilities contact is how many watts of continuous load the cabinet takes on one feed.
Network ports and the capacity behind them
A storage platform needs ports, and ports are cheap until the switch runs out of them. The cost that appears late sits behind the port: uplink capacity from the rack, and whether the aggregation layer can carry a restore at full rate alongside everything else on that path.
Backup traffic is unusual in shape. It is sustained rather than bursty, it runs in a window that may overlap other batch work, and during a recovery it reverses direction. A design comfortable for nightly ingest can be the constraint during a restore, and that fix costs more than a port.
Where a project consolidates several targets onto one platform, the ports freed at the old locations and those required at the new one rarely cancel out. Counting both sides is part of what makes consolidating separate backup targets produce a real saving rather than a relocated cost.
Where ARTESCA fits
ARTESCA is object storage software running on standard servers the customer owns and operates, in capacities from roughly 50 TB up into the petabyte range. Because the hardware is the customer's, the rack, power, cooling and network costs described here sit entirely on the customer's side of the boundary and are known once the server configuration is fixed.
That helps the modeling, since the figures come from the specific servers chosen and can be measured on the installed system rather than inferred. It also means they have to be gathered deliberately, because no invoice will itemize them.
Footprint matters mainly in how it interacts with an existing room. A deployment that fits into free units on existing circuits and free ports on existing switches has a different facility cost from one requiring a new cabinet, and which case applies is a site fact rather than a product fact.
What to measure and write down
Before the comparison is finalized, record four numbers per option: rack units as installed, steady draw in watts from metered outlets, peak draw during a restore, and ports required with the uplink capacity behind them. Each is obtainable quickly, and each can be put to the vendor to confirm against the configuration quoted.
Alongside them, record two site facts that do not change per option: the continuous load a single feed in the target cabinet can carry, and whether the room has spare cabinets. Those answers determine whether facility costs are marginal or whether the deployment triggers an expansion, and they come from facilities rather than the storage vendor.
After installation, read the meters again in the first quarter and compare against the estimate, then repeat annually and after any large capacity addition. Recording measured draw next to the original assumption is what makes the next comparison start from evidence, and it belongs with the maintenance record for the platform.