Recovery on the Clock: Benchmarking Restore Throughput for Defensible RTOs

The number everyone quotes and nobody measures

Ask a UK technology leader for their recovery time objective and the answer usually arrives in seconds, and is usually a round number. Four hours for tier one. Twenty-four for tier two. Those figures typically originate in a contract, a service level schedule or a business impact analysis workshop, and they are rarely revisited against a stopwatch.

The reason is structural rather than negligent. Backup success rates are easy to produce: the console lights green, the job completes inside the window, the report is generated automatically. Restores are episodic, disruptive to arrange and require the cooperation of application teams who would rather not have a production-sized workload landing in a test environment. So the metric that gets reported is the one that is convenient, and the objective that gets signed is the one that has never been tested.

That gap matters more now than it did. Operational resilience expectations in the UK financial sector, in place since March 2025, require firms to demonstrate that they can remain within impact tolerances through severe but plausible scenarios. Demonstration implies measurement. An RTO that has never been exercised under realistic conditions is an aspiration wearing a commitment's clothing.

Why backup success is not restore capacity

A backup is a read from production and a write to a repository. A restore is a read from a repository, a transit across a network path that was designed for a different traffic profile, and a write to a target that is often not the tier the data came from. The two operations share a data set and almost nothing else. Throughput measured in one direction tells you very little about the other, and the asymmetry is not a small percentage — it is routinely an order of magnitude.

Four variables account for most of the collapse.

Contention. Real recovery does not happen on a quiet Sunday. It happens alongside a partially operational estate, with other restore streams in flight, replication catching up, and the target array simultaneously serving whatever production survived. Restore workloads are aggressive, sequential and unforgiving of shared bottlenecks — the backup proxy, the repository's read path, the SAN fabric and the deduplication engine all become contention points at exactly the moment they are needed most.

Encryption. Both directions cost something. Repository-level encryption imposes a key lookup and an AES operation per block, and software-based implementations can saturate a modest CPU long before the network does. Where keys are held in a central KMS or HSM, that service becomes a latent throughput ceiling, and its availability becomes a single point of failure in the recovery path that appears on no runbook. Measure with the encryption configuration you will actually be running, not the one used in the proof of concept.

Network. Restore traffic is frequently deprioritised by default. QoS markings, SD-WAN policies and security inspection paths built for north-south application traffic all treat bulk recovery as background noise, and the effective bandwidth available during an incident is rarely the provisioned bandwidth. This is particularly acute where recovery targets sit in a second UK site or a hyperscaler region reached over the same contended circuits that carry business traffic.

Object profile. Millions of small files behave nothing like a handful of large virtual disks. Metadata operations dominate, and the restore engine spends its time walking a catalogue rather than moving bytes. Any benchmark that uses a single large sequential dataset will produce a number that is both flattering and irrelevant.

Designing a benchmark that will survive scrutiny

The essential discipline is to test the thing the business actually needs, in the order it needs it. That means restoring a complete application stack in dependency order — database, then application tier, then the integration layer, then the identity dependency that everything else assumes — and timing the point at which the first genuine transaction is served, not the point at which the last byte lands.

Define the working set before you start. An RTO applies to the data the business must have in the first four hours, which is almost never the full estate. Negotiate that list with the process owners and write it down, because it will be the most contested assumption in the whole exercise.

Run at a minimum of three concurrency levels: a single stream, the concurrency assumed in your runbook, and one level beyond it to find the knee of the curve. Run both in hours and out of hours. Record the tooling versions, the source and target media, the network path, the encryption configuration and the runbook revision used. Capture p50 and p95 rather than averages, since the average is precisely the figure that will not describe your worst day.

Finally, account for the parts of recovery that are not transfer. The clock starts when the incident is detected, not when an engineer logs on. Detection, decision, declaration, authorisation and access provisioning routinely consume more elapsed time than the data movement itself, and they are the components most often omitted from the calculation.

From measurement to a statement you can defend

An honest RTO statement has a shape. It names the scenario, the working set, the assumed conditions, the measured transfer time at the relevant percentile, the fixed overheads and the validation period. Something closer to: for a full loss of the primary site, the payments platform returns to transactional service within five hours and forty minutes at the 95th percentile, assuming a working set of twelve terabytes, dual-site network availability and a declared incident within fifteen minutes of detection.

That sentence is longer, less comfortable and far more useful than a four. It also exposes the dependencies that a round number conceals, which is the entire point: the board can see what it is buying and what would have to change to buy less.

Where the measured figure exceeds the stated objective, say so explicitly and attach a remediation position with dates. A documented gap under a managed plan is a governance matter. A gap discovered during an incident is a different category of problem entirely.

Drift, and the obligation to re-measure

Restore throughput decays quietly. Repository growth, a change of backup product, a move to a new target tier, a key management migration, a network re-design or a consolidation of data centres can each move the figure materially, and none of them will announce themselves as a recovery risk. Re-baseline after any of those events and at least annually otherwise. Track a small number of stable metrics over time so that drift is visible as a trend rather than discovered as a surprise.

Recovery capability is not a property of the backup system. It is a property of the whole path from repository to served transaction, and it can only be stated with confidence when it has been timed end to end, under conditions that resemble the ones it will meet.