What Is Restore Throughput?

Restore throughput is the rate at which a backup system can return data and workloads to a usable state, usually expressed in terabytes per hour or virtual machines per hour. It is the practical measure of how long an outage lasts.

The distinction that matters most is this: restore throughput describes recovery, not protection. Backup throughput — how fast data is written into the repository — is a scheduling concern, and it is the number most vendors publish. Restore throughput is the number that determines whether a business is down for two hours or two days, and it is usually far lower than the backup figure.

How restore throughput is measured

There is no single unit, and the unit you choose changes what the number means.

• Terabytes per hour. Useful for bulk recovery and capacity planning, but it hides the difference between one large sequential file and a million small ones.
• Virtual machines per hour. Closer to what the business experiences, because it counts usable systems rather than bytes.
• Concurrent workloads sustained. How many restores can run at once before the repository saturates — the figure that matters most during a site-wide event.
• Time to first usable workload. With instant recovery, this can be minutes even when full data movement takes hours.

A number quoted without its conditions — data type, concurrency, whether deduplication is being rehydrated — is not comparable to anything.

What actually limits it

Restore is not backup played backwards, and the bottleneck usually sits somewhere unexpected.

• Repository read performance. Restores are read-heavy and often random, which is the opposite of the sequential write pattern backup storage is frequently tuned for.
• Rehydration cost. Deduplicated and compressed data must be reassembled during restore, which consumes CPU and adds latency at exactly the wrong moment.
• Concurrency limits. Many environments restore one workload quickly but collapse when twenty run at once, because the repository cannot serve parallel streams.
• Network and target capacity. The production storage receiving the data can become the constraint once the repository is fast enough.
• Storage class. A copy sitting in a slow archive tier may have hours of retrieval latency before throughput even begins — one reason backup storage tiers should be chosen against recovery targets, not just cost.

Why it decides your RTO

A recovery time objective is a promise about elapsed time, and elapsed time is data volume divided by restore throughput. If you hold 200 TB and restore at 5 TB/hour, a full recovery takes forty hours regardless of what the RTO document says.

This is also why throughput and validation are linked. Finding a clean restore point after an attack means restoring several candidates and testing each one, whether into a clean room or by walking back through point-in-time recovery copies. Low throughput makes that search prohibitively slow, so teams take the risk of restoring an unverified copy. And because a throughput figure from a datasheet is a claim rather than a measurement, only restore testing at realistic scale tells you your real number.

Restore throughput and ARTESCA

Scality ARTESCA is backup-first object storage on standard servers, engineered for the read path rather than only the write path.

• Read performance by design. The architecture targets the random-read profile that live restores and instant recovery generate, not just sequential ingest.
• Parallelism at scale. Multiple concurrent restore streams are served without the repository becoming the bottleneck, so recovery of many workloads happens together rather than in sequence.
• Scales in the dimension you need. MultiScale architecture allows performance and capacity to grow independently, so adding retention does not slow recovery.
• Proven with backup applications. Validated interoperability with Veeam, Commvault, Rubrik and Cohesity means published throughput reflects the tools you actually restore with.

The effect is an RTO you can commit to because the repository is not the limiting factor.

Restore throughput FAQs

Why is restore slower than backup?

Backups are incremental, sequential and scheduled; restores are bulk, often random, and must rehydrate deduplicated data under time pressure. Backup throughput is measured on the happy path, while restore throughput is measured on the worst day. Expecting them to match is the most common planning error.

What is a good restore throughput number?

There is no universal figure — it depends on your data volume and your RTO. Work backwards: divide the data you must recover by the hours you are allowed, and that is your required throughput. Then measure whether your environment actually achieves it.

Does instant recovery make throughput irrelevant?

No, it makes it more important. Instant recovery runs the workload directly from the repository, so the repository’s read performance becomes the running system’s performance. It changes when throughput matters, not whether it does.

How do I measure my real restore throughput?

Run a restore of representative data at realistic concurrency and time it end to end, including any archive retrieval and rehydration. Testing a single small VM tells you almost nothing about recovering a hundred at once during an incident.