Every backup sizing exercise I have reviewed models ingest carefully. Very few model the way back out, and the way back out is the entire point of the exercise.
Why restore is slower than backup
Deduplicating appliances are optimised for ingest. Incoming data is deduplicated and written efficiently. What lands on disk is a set of unique blocks plus metadata describing how to reassemble them.
Reading it back means gathering blocks that are scattered rather than sequential. This is rehydration, and it is fundamentally more work than writing was. On disk-based systems it involves a lot of seeking, which is why the restore rate can be a fraction of the ingest rate.
Architectures differ here, and it is one of the genuine technical distinctions in this market. Some appliances keep the most recent backup in an undeduplicated landing area specifically so that the most likely restore is fast. Others deduplicate inline everywhere and accept slower rehydration. Both are defensible designs and they produce very different worst days.
The number to compute
Take your largest single system. Divide its size by the appliance’s realistic restore rate. That is how long a full restore of that one system takes, assuming nothing else is competing.
Now consider a scenario where you are restoring many systems at once, because the event that destroyed one rarely destroys only one. Total data to recover, divided by aggregate restore rate, equals your actual recovery time.
Compare that against the recovery time objective in your policy document. In my experience the two numbers are rarely in the same neighbourhood, and nobody has noticed because nobody has multiplied.
What makes it worse in practice
Everything at once. A site-level incident means concurrent restores competing for the same appliance.
The network. Restoring at the appliance’s maximum rate requires the network between it and the target to carry it. Often it cannot.
The target. Writing restored data to primary storage that is itself busy, or degraded, or newly built and not yet tuned.
Cloud tiering. Data that has aged to a cloud tier restores at cloud egress speed, which is a different and much slower number, and possibly a billed one. If your retention strategy tiers old backups to object storage, model the restore from there specifically.
What to ask vendors
- Sustained restore rate in TB/hour, for a full restore, with the data type stated
- Whether the most recent backup is held undeduplicated for fast recovery
- Instant recovery capability: can a VM run directly from the appliance while it rehydrates in the background
- Concurrent restore behaviour: what happens to the rate with ten streams
- Restore rate from the cloud tier
Instant recovery is worth understanding properly. Running a workload directly off the backup appliance while it restores in the background changes the recovery conversation completely, because the recovery time becomes minutes for service availability even if full rehydration takes hours. Whether performance while running that way is acceptable is a question to test, not to accept on a slide.
The exercise
Once a year, restore something large and important, with the clock running, and write down the real number. Not a file-level restore of a test document. A system that matters, from the copy you would actually reach for.
Almost every organisation doing this for the first time finds that the real recovery time is several multiples of the policy figure. Better to find that on a Tuesday you chose.
Next: who is actually winning in this market, and why the answer has changed.