Most backup storage decisions are still made on a single number: the quoted price per terabyte on the day of purchase. That number is easy to compare and defend, but it describes only the first of many cost lines a backup repository generates over its service life. The rest, from expansion and hardware refresh to support renewals and slow restores, are where the two main architectural choices diverge.
Those two choices are the purpose-built backup appliance, an integrated bundle of hardware and deduplication software sold and refreshed as a unit, and software-defined object storage, a storage licence that runs on standard servers and grows by adding nodes. Both are legitimate ways to hold backup data; they accumulate cost in different places and at different times.
This article offers a neutral five-year framework: the cost lines, why day-one pricing misleads, a comparison table, an illustrative example and a checklist for building the model.
Total cost of ownership (TCO) for a backup repository is the sum of every cost it causes between the purchase order and the day the data is moved off it: capital costs, recurring operating costs, and less visible costs such as staff time, restore downtime and migration at end of life.
The naive answer treats TCO as purchase price plus a support contract. That breaks down for backup storage because data grows continuously, retention lengthens, and the repository is expected to outlive at least one hardware generation. A model that ignores growth, refresh and exit is a day-one quote with extra decimals.
An appliance packages controllers, disk shelves and deduplication software into one product with one support contract. Capacity is bound to the model purchased: expansion means adding shelves up to the controller's ceiling, then a larger head unit or a second system. At end of life the whole unit is typically replaced in a forklift refresh, with data migrated to the successor.
Software-defined object storage separates the licence, usually priced per unit of capacity, from the hardware, which is standard servers with internal drives. It grows by adding nodes, and because servers are interchangeable, hardware generations can coexist in one cluster and old nodes can be retired individually.
These lines appear in almost every backup storage TCO model; their weight depends on growth rate, retention policy and staffing.
Three effects make the opening quote a poor proxy for five-year cost. First, quoted usable capacity rests on a data reduction assumption the buyer cannot verify until production. A quote built on a generous ratio looks cheaper per usable terabyte than one based on raw capacity, while delivering similar real space once already-compressed or encrypted backup jobs arrive.
Second, the quote captures one point in time; the price and granularity of expansion determine what years two through four cost. Third, the quote excludes the ending. A platform replaced wholesale, with a parallel-running migration, carries an exit cost that one capable of rolling node replacement does not.
The table is qualitative: it describes how each line typically behaves. The values belong in the organization's own spreadsheet.
| Cost line | Purpose-built appliance | Software-defined object storage |
|---|---|---|
| Acquisition | Often lower per quoted usable TB; depends on assumed dedupe ratio | Priced on licensed capacity; hardware sourced separately or as an appliance |
| Expansion increments | Shelf-based, larger fixed steps, capped by controller model | Node-based, sized to need, no controller ceiling |
| Hardware refresh | Forklift replacement of the whole unit, data migration required | Rolling node replacement, mixed generations in one cluster |
| Support renewals | Single contract, hardware renewals often rise in later years | Software subscription plus standard server support, quoted separately |
| Data reduction risk | High: usable capacity depends on achieved ratio | Lower: reduction typically handled by the backup application |
| Power and space | Depends on controller and shelf density | Depends on chosen server density; older nodes can be retired early |
| Operations time | Low day to day, concentrated in expansion and refresh projects | Low day to day, spread across incremental node additions |
| Restore performance | Rehydration can slow large restores | Native object reads, parallel across nodes |
| Immutability | Sometimes a licensed add-on or specific model | Frequently included through S3 object lock |
| Exit and migration | Full migration at each refresh cycle | Data stays in place while hardware turns over |
Suppose an organization holds 500 TB of backup data growing 25 percent per year, and compares an appliance against software-defined object storage quoted at roughly 30 percent more on day one for the same usable capacity. This example is illustrative only and uses relative terms rather than prices.
In the appliance scenario, the achieved dedupe ratio is about a third lower than quoted because much of the estate is already compressed at source. Usable capacity runs out a year early, pulling a shelf expansion into year two; the head unit reaches its ceiling in year four, requiring a controller upgrade; renewals rise in years four and five; and the year-five refresh adds a migration with months of parallel running.
In the object storage scenario, nodes are added in years two, three and four, each sized to about a year of growth. Year-one nodes begin retiring in year five with no migration, and immutability is in the base licence.
Under these assumptions, the 30 percent day-one advantage is consumed by the early expansion and the year-four upgrade, and year-five exit costs push the appliance total above the object storage total. Change the growth rate, achieved ratio or refresh timing and the answer moves; that sensitivity is the point of the model.
Scality ARTESCA is S3 object storage built for backup, available as software on standard servers or as a hardware appliance. Both form factors share the same scale-out architecture: capacity grows by adding nodes, and hardware generations can be mixed within a cluster rather than replaced as a unit.
Immutability through S3 object lock is part of the platform rather than a separately licensed feature, which removes one line from the model; details are on the security and cyber resilience page. ARTESCA is validated with major backup applications including Veeam, Commvault, Rubrik, Cohesity and HYCU, so data reduction and restore behavior can be modeled from the backup software's own figures. For translating growth and retention assumptions into node counts, see the earlier post on backup repository sizing.
Whatever platform is under consideration, ask the vendor to fill in all ten cost lines for each of the five years before comparing prices per terabyte.