Backup appliance sizing looks simple and goes wrong reliably, usually because the conversation starts with how much usable capacity the box has rather than with what has to be protected.
1. Front-end capacity
How much primary data is in scope. Not how much storage is provisioned, not how much the array reports as used with thin provisioning, but the actual data to be protected.
This number is almost always wrong on the first pass, in both directions. Systems nobody mentioned are in scope, and systems everybody assumed were in scope turn out to be protected some other way. Get the list of what is being protected, by name, before doing arithmetic.
2. Daily change rate
What percentage of that data changes between backups. This drives the incremental size and therefore the ongoing capacity growth.
Vendors often assume something in the low single digits. Databases with heavy transaction volumes change far more. Archives and file shares change far less. A blended assumption applied to a mixed estate is how sizing goes wrong, and the error compounds over the retention period rather than appearing on day one.
Measure it if you can. Your existing backup product reports incremental sizes; that is your change rate, already observed, no estimation required.
3. Retention
How many days, weeks, months, years, and for which data. Retention multiplies everything. A move from thirty days to ninety is not a small adjustment to a quote.
Watch for retention driven by regulation that nobody has actually read. I have seen seven-year retention applied to everything because one system needed it, which tripled a purchase.
4. Ingest rate
Capacity tells you whether the backup fits. Ingest rate tells you whether it finishes.
Divide the nightly backup volume by the backup window in hours. That is your required sustained ingest in TB/hour, and it is a specification the appliance must meet. Note that vendor ingest figures are usually best case with an optimal stream count and a favourable data type.
If the window is eight hours and the arithmetic says ten, you have a problem that no amount of capacity solves.
5. Restore rate
The one that gets skipped, and the one that matters on the worst day. Its own post follows.
The multipliers people forget
Replication. A second appliance at another site, plus the bandwidth between them. Deduplicated replication sends far less than the full dataset, but the figure is not zero and it needs to fit in a window too.
Growth. Size for the end of the term, not day one. Three years of growth at even a modest rate changes the model.
Synthetic fulls and housekeeping. These consume capacity and I/O on a schedule. Ask how the appliance handles them and what the overhead is.
The first full backup. Often the hardest thing the appliance ever does, and frequently not planned for. Seeding a new appliance for a large estate can take days.
The question I would ask any vendor
Given my front-end capacity, my measured change rate, my retention and my window, show me the usable capacity calculation and the ingest calculation, with the deduplication ratio you assumed stated separately.
That last clause is the whole trick. The dedupe assumption dominates the result and it is the least defensible input in the model. Which is the next post.