Home  ›  Glossary  ›  Restore Throughput

What is restore throughput?

Restore throughput is the sustained rate at which a backup system reads, rebuilds and writes recovered data back to production, measured in MB/s, terabytes per hour or virtual machines per hour. It sets how long a recovery takes, and the slowest stage in the restore path sets it, not the storage alone.

How does throughput become recovery time?

Recovery time follows directly from the volume of data and the rate it comes back. At 5 TB per hour, restoring 50 TB takes about 10 hours; at 2 TB per hour the same restore takes about 25. A recovery plan with a target in hours therefore assumes a throughput, and the open question is whether the system delivers it under real conditions.

Which metrics limit restore throughput?

  • Bandwidth: the MB/s or GB/s the repository can deliver for large, sequential reads, covered under storage throughput.
  • IOPS: the number of read operations per second the storage can serve when reads are small and scattered, which is typical of restores. See IOPS.
  • Rehydration and decryption: processing time to reassemble deduplicated chunks, decompress and decrypt data before it can be written out.
  • Concurrency: how many restore streams run at once, and whether they compete for the same disks.
  • Network: the bandwidth of the path between the repository and the restore destination.
  • Destination write speed: how fast the production storage can accept the incoming data.
  • Storage tier: data on a slower tier of backup storage adds retrieval delay before reads begin.

The lowest of these sets the rate for the whole restore. Faster storage does not help when the network or the destination is the limit.

Why is backup speed a poor guide?

Backups are mostly large sequential writes, which storage handles efficiently. Restores read a chosen set of workloads back, often many at once, in an order that differs from the order the data was written. The reads become closer to random, as described under sequential and random I/O, so they depend on IOPS more than on bandwidth. A system that finishes backups overnight can restore at a fraction of that rate.

What makes a measurement realistic?

A single virtual machine restored on a quiet system gives the most flattering figure. A realistic measurement uses the volume and concurrency of an actual incident: many workloads restored together, from older restore points as well as recent ones, while other jobs are still running. The figure that matters to users is time to the first usable workload, since services return in sequence. Restore testing is where that figure gets measured and re-measured after growth or platform changes.

Frequently asked questions

What units is restore throughput measured in?

MB/s or terabytes per hour for bulk data, and virtual machines per hour when the aim is to bring workloads back.

Is restore throughput the same as read throughput?

No. Read throughput is one input; restore throughput also includes rehydration, decryption, the network, the destination's write speed and how many restores run together.

Can restore throughput be increased by adding storage nodes?

On scale-out storage, adding nodes usually adds read bandwidth and IOPS when the restore runs several streams in parallel. A single stream is limited by its own path and does not speed up.