About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Time the restore until the agreed function works, on the copy and the path an incident would use. Compare that elapsed time with the recovery time objective you have already accepted. If the drill exceeds that objective, it identifies a gap under the conditions tested. A real incident may differ, so record those conditions and investigate the gap.
A throughput figure, in bytes per unit time, can explain the part of the drill that was spent moving and unpacking data. It cannot stand in for the elapsed time. Approvals, key retrieval, a queue for the only restore host, application startup, and a check that the data are the right generation all sit outside a naive byte rate and inside the recovery the business actually waits for.
No drill was run for this article. Any number below is a worked example of arithmetic, not a measured result from a system.
Why it matters
The controls discussed here apply where your organisation has selected or is required to meet them. They are not a blanket legal requirement for every business.
NIST SP 800-34 defines the recovery time objective as the maximum time a system resource can remain unavailable before there is an unacceptable impact on other resources, on the processes it supports, and on the maximum tolerable downtime. It defines maximum tolerable downtime as the total time the owner is willing to accept for the outage, including all impact considerations. The guide then makes the relationship explicit: the recovery time objective must normally be shorter than the maximum tolerable downtime, because work often has to be redone after the system is back, and that reprocessing has to fit inside the downtime limit.
That definition is useless if the only duration you have is a vendor brochure or a feeling that "the link is ten gigabits." SP 800-34 says tests use quantifiable metrics to validate that a system or component works in an operational environment. A metric you did not take is not a test result. SP 800-53 control CP-10 requires recovery and reconstitution to a known state within an organisation-defined time consistent with the recovery time and recovery point objectives. The discussion says those objectives are established in contingency planning, and that recovery operations reflect them. A plan that states four hours, and a drill that has never been timed, has not shown that CP-10's time period is available.
The same guide, in its backup policy questions, asks how quickly backups must be retrieved in an emergency. Retrieval time is part of the window. CP-9(5) addresses moving backups to alternate storage within recovery objectives. Recall from that store during recovery is a distinct operation, covered by the retrieval and recovery planning discussion. A restore that starts only after someone drives a disk across town has already spent recall time. If you start the clock when the bytes are local, you have timed the easy half.
ASD Essentials action PRO-10, published 15 October 2026, says restoration testing should show that backups can meet the defined recovery time and recovery point objectives. A test without a clock cannot show the time objective. A test that records only a byte rate can show the time objective only after you turn the rate back into elapsed time and add the stages the rate ignored.
There is a planning consequence when the numbers do not fit. SP 800-34 says that when the recovery time objective cannot be met and the maximum tolerable downtime will not move, a plan of action and milestones should document the gap and how it will be closed. CP-4 says test results are reviewed and corrective actions are started where needed. A missed window is that kind of result. It is not a reason to average it away.
How it works
Define the start and the stop before you start
Write both instants in the test plan. SP 800-34 wants objectives and success criteria before the test, so the criterion is not chosen after a flattering interval appears.
Record when service became unavailable, when the disruption was declared, and when the restore request was accepted. Under the RTO definition used here, total unavailability starts with the disruption; a clock beginning at declaration or request acceptance is only a sub-interval. State any earlier delay simulated or excluded from the drill. A start at "when the data began to move" drops the queue, the approval, and the search for the right backup generation. Those are often the long parts, and they are part of being unavailable.
A defensible stop is the success criterion for the function, the same kind of criterion a group restore uses: the report runs, the file opens and matches a known value, the service answers a defined request. SP 800-34's reconstitution language separates data testing (complete and current to the last backup you claimed) from functionality testing (the system can do its work). Stop at functionality if your objective is "users can work." If you stop when the hypervisor says the guest is on, you have timed a power-on. Record that as a waypoint if it helps the diagnosis. Do not record it as the recovery time.
Also record the latest application-consistent data point actually recovered, which may differ from backup job completion time. The interval between that data point and the incident is the potential data loss to compare with the recovery point objective, which PRO-10 treats as a separate objective from the recovery time. A fast restore of a week-old copy can pass a time test and fail a point-in-time test. Write both.
Split the elapsed time into stages you can argue about
A single total is the decision number. The stages tell you what to change if the total does not fit. For a drill, record at least these stages. They are an editorial breakdown so a team can talk about one drill. They are not a NIST taxonomy.
- Decide and identify the generation. This includes finding the backup that matches the recovery point, and rejecting a newer copy you do not trust.
- Recall. This is retrieval from storage if the bytes are not already where the restore will run; distinguish it from CP-9(5)'s outbound transfer to alternate storage. SP 800-34's alternate-site discussion expects the site to be able to use the backup configuration, which includes being able to get the media or the stream.
- Read, decode, and write. This is the stage a byte rate describes. Note the volume of data actually restored, not the volume the estate holds. Note whether the figure is compressed size or restored size, and use the same one every time.
- Rebuild enough to start. Platform checks, application start, and settings. SP 800-34's recovery sequence example puts platform verification before application and data. That time counts.
- Prove the function. The criterion itself takes time. A report that runs for forty minutes is part of the window if users are waiting on that report.
SP 800-34 section 4.3.1 says procedures should include escalation when an action is not completed in the expected time. Give each stage an expected time in the plan. When a stage blows it, the record shows which stage, which is the only way a byte rate stops being a slogan.
What a byte rate is, and how not to misuse it
If you restored 8 terabytes of uncompressed data in a stage that lasted 4 hours, the stage rate is 2 terabytes per hour. That sentence is arithmetic on your own measurements. It is not a benchmark, and it is not portable. It depends on the store, the path, the restore host, how much was incremental versus full, and whether anyone else was using the system. SP 800-34's test definition ties the metric to an operational environment. A rate taken on an idle lab host with the data already on a local disk is a metric about that lab.
Use the rate for two narrow questions.
First, scaling inside the same path. If this drill restored a sample and the incident would restore four times as much data through the same read-and-write stage, the stage will not get shorter by hope. CP-9(2) allows a sample. The discussion says the sample size follows the assurance you need. Assurance about the window is weak if you do not say how the sample's stage time would grow. Linear scaling is an assumption. State it. Neither an idle nor a saturated host establishes whether linear scaling is conservative. Caches, small-file work, concurrency limits, throttling and changing data shapes can make a larger restore scale differently. Use larger representative trials and an explicit allowance for uncertainty. Either way, label it as an assumption, not as a measurement.
Second, separating a slow path from a slow procedure. If the read-and-write stage was thirty minutes and the total was five hours, buying a faster link will not fix the five hours. The finding is in the other stages. Teams that publish only the peak transfer rate hide that.
Do not compare your rate with a published speed from a different design. This article contains no such comparison because none was measured, and a borrowed number would pretend to be your drill.
A worked window budget
The following is hypothetical arithmetic, not a measured benchmark. Suppose an 8 TB restore spends four hours in read, decode and write, while detection, approval, recall, startup and validation together consume another 75 minutes. Total service recovery is five hours and 15 minutes, against a four-hour objective.
| Part of the example | Duration | What it means |
|---|---|---|
| Data movement and reconstruction | 240 minutes | Effective restored-data rate is 2 TB per hour |
| Other sequential stages | 75 minutes | These stages do not disappear when the link improves |
| Total unavailable time | 315 minutes | Misses a 240-minute objective by 75 minutes |
| Transfer budget if other stages stay fixed | 165 minutes | Requires about 2.91 TB per hour for this data volume, before any safety margin |
That last rate is a planning requirement, not evidence the system can deliver it. It assumes the stages are sequential, the restored size remains 8 TB and the other stages remain 75 minutes. If stages overlap, use the actual critical path instead of adding overlapping durations twice. If the data grows or contention worsens, repeat the calculation and then verify it in a representative test. Improving the slowest measured stage may help; merely buying bandwidth does not establish that storage, decoding or application recovery will use it.
For database-specific recovery-point measurement and transaction checks, see Proving RPO and RTO. This article concentrates on allocating the recovery window and diagnosing stage delays.
One drill is a single observation
A recovery time objective is a maximum you intend to live within, not an average you hope to beat. One drill that finishes in three hours against a four-hour objective is evidence that it happened once. It is not a demonstration that the next drill will. SP 800-34 says testing varies with impact, goal, and the plan, and CP-9(1) asks for backup information to be tested at a frequency you define, because reliability is not a one-time property.
When you have several drills, keep the slow one visible. Averaging a fast sample with a slow full restore produces a number neither drill achieved. The decision number for window risk is the drill that matches the incident you are planning for: similar data volume, similar path, similar time of day if the store is shared with backups that still run at night. If you have only one relevant drill, say "one observation" in the report. CP-4's review can still start corrective action on one miss. It should not convert one success into a guarantee.
Where the window actually breaks
Compare three numbers, all of which SP 800-34 distinguishes.
- Maximum tolerable downtime: the business limit on the outage.
- Recovery time objective: the limit on how long the resource itself may be down, normally shorter, because reprocessing has to fit as well.
- Measured time to the criterion, plus a stated allowance for the reprocessing you did not rehearse.
If the measured time already exceeds the recovery time objective, the drill missed. If the measured time fits the recovery time objective and leaves nothing for the reprocessing the guide warns about, you have not shown that the maximum tolerable downtime is safe. Write the reprocessing allowance as an estimate if you did not rehearse it, and mark it as an estimate. An estimate is not a test metric. It is a reason to rehearse that stage or to hold margin.
CP-10's "known state" also takes time that a byte rate skips. Returning to a known state includes the data being the generation you intended and the function being the function you intended. A restore that loads the wrong day's data quickly has failed CP-10 even if the rate was high.
What to choose and why
Time every drill you intend to use as evidence for PRO-10 or for CP-10, even the small samples. A sample's elapsed time does not prove the full window. It does show whether recall and identification are slow before you discover that in a full exercise. SP 800-34 Table 3-6 expects an actual recovery component in the exercise for moderate and high impact. That is the drill whose total you compare with the objective. Use samples to keep the stages honest between exercises.
Exercise recall on the real storage path at your documented test frequency, separately from checking delivery to alternate storage. If the alternate copy is offsite, at least some timed drills must start from that copy. A drill from a local cache times the cache. SP 800-34 asks that backup copies be tested at the alternate site, where you have one, so the site's configuration is part of the result. The site's speed is part of its configuration.
Set the expected stage times in the plan so escalation under section 4.3.1 has a threshold. Expected times are planning figures. Measured times replace them. After the drill, either update the expected time or record a corrective action. Leaving last year's expected time in the plan after a drill that blew it by an hour is how the next team thinks they are on track.
If the drill misses, the choices SP 800-34 leaves you are the real ones: reduce the data that must move inside the objective, shorten a stage you measured, or change the objective and accept the business impact, documented where the downtime will not move as a plan of action. This article cannot tell you which data you may stop protecting. It can tell you not to close the gap by redefining the stop instant until the number fits.
Risks and limits
The first risk is a clock that starts late and stops early. Both edits make the window look safer. The test plan's instants, written beforehand, are the control.
The second risk is a byte rate from the wrong path. Local disk, idle host, already-decrypted data, and a sample of the smallest files will produce a rate the incident cannot have. CP-9(1)'s discussion example starts by retrieving from the alternate or backup site, including decrypt. A rate that skipped decrypt is a different test.
The third risk is treating linear scaling as a measurement. It is an assumption about a stage. The total window includes stages that do not scale with bytes at all, such as a change-approval meeting or a single-threaded application start.
The fourth risk is one successful drill becoming policy. Reliability in CP-9(1) is tied to a frequency because copies and paths change. A storage migration invalidates the old rate. SP 800-34 says to repeat test and exercise activity after system changes.
The fifth risk is publishing a precise throughput as if this research had measured one. It did not. Use your drill's own volumes and times. If a stage's volume is unknown because the product does not report it, time the stage anyway and leave the rate blank. A blank rate is honest. An invented one is not.
Industrial control and safety systems raise a further limit SP 800-34 already notes: some systems cannot be fully exercised in one event. A partial timing is still worth recording if the report says which stages were not run. Do not fill those stages with a guessed rate.
This article was written with AI assistance. It is source research only. The factual claims have been independently checked against the cited sources. It is not a capacity-planning certificate and it states no product's speed.
Sources
- NIST SP 800-34 Rev. 1, 11 November 2010, https://doi.org/10.6028/NIST.SP.800-34r1 — RTO, MTD, and the reprocessing relationship; quantifiable metrics in section 3.5.1; backup retrieval question in section 3.4.2; alternate-site testing; section 4.3.1 escalation; section 4.4 validation. Opened 11 November 2026.
- NIST SP 800-53 Rev. 5, https://doi.org/10.6028/NIST.SP.800-53r5 — CP-10, CP-9(1), CP-9(2), CP-9(5), CP-4. Opened 11 November 2026.
- NIST SP 800-84, September 2006, https://doi.org/10.6028/NIST.SP.800-84 — tests in an operational environment, and protection of live systems. Opened 11 November 2026.
- ASD, Essentials for enterprise IT, 15 October 2026, https://www.cyber.gov.au/publication/essentials-for-enterprise-it — PRO-10. Opened 11 November 2026.
This article was originally published on .