Recovery: how much time and data can you lose?

Your service is unavailable, and the latest usable backup is six hours old. Two clocks now matter: how far back the recovered data goes, and how long it takes to restore the service.

Recovery point objective: The target limit on data loss expressed as time.

Give the two clocks different names

The recovery point objective, or RPO, is the target limit on data loss expressed as time. The recovery time objective, or RTO, is the target duration for restoring service after a disruption. An objective is a requirement to design and test against, not proof the system can meet it.

A backup every hour does not guarantee a one-hour RPO if recent backups are corrupt or inaccessible. Agree how the organization measures disruption and restoration; different clocks produce misleading reports.

Restore the service, not just the files

A successful backup job says that a particular operation completed. Recovery may also need working keys, identity services, network access, software versions, configuration, and people with the right authority. Test a representative restore and validate the application’s integrity.

Protect recovery copies from the same accounts and failure modes as the primary system. Offline or appropriately immutable copies can help, but their actual isolation, retention, and access controls need verification.

Practice the decisions

Choose a recovery order based on business dependencies. A database may be intact while the identity service required to access it is unavailable. Document emergency access and communication paths that survive the normal systems failing.

The calculator assumes a usable backup and measures elapsed time from disruption to validated restoration. It excludes additional detection delay as a separate factor. Real incidents may involve uncertain compromise dates, reconciliation of lost work, and safety checks before reconnecting.

EXPLORE THE CONCEPT

Is this recovery evidence enough?

Explore three claims, then adjust the recovery clocks.

The backup job says success

This is useful operational evidence, but it does not prove that a complete, readable service can be restored.

A restore worked but missed the time target

The restore proves some capability. Investigate the delay and adjust the design or an agreed objective.

The backup shares unrestricted administrator access

One incident may affect both primary and recovery data. Review isolation and the authority to delete or alter copies.

A simplified learning model. It connects to no systems and uses no real data.

Work through the two clocks

The fictional Lantern bookings service agrees an RPO of thirty minutes and an RTO of sixty minutes. For this exercise, disruption begins at 14:00 and recovery ends only when staff can create, retrieve, and reconcile bookings. A validated recovery point contains committed data through 13:40. Full service passes its checks at 14:52. The recovery-point gap is twenty minutes and the measured recovery duration is fifty-two minutes: both fit the agreed objectives under these assumptions.

Those numbers answer different questions. Twenty minutes is not twenty lost bookings; there might have been no changes or hundreds during that interval. A reconciliation process must identify what is actually missing. Fifty-two minutes is not just the time spent copying files; it includes the work required to reach the agreed service endpoint. If the team started measuring when an engineer arrived at 14:15, it would hide fifteen minutes of disruption.

PredictThe database opens at 14:25, but staff cannot sign in until 14:52. Which time meets Lantern’s recovery endpoint?

14:52, assuming the other agreed booking checks also pass then. Opening a database is an intermediate milestone. A different service could define a useful limited operating mode, but its scope must be agreed and reported separately.

Find the dependency that controls the result

Write a short dependency chain: trusted recovery access → usable keys and configuration → consistent database → application → staff sign-in → booking validation. The arrows mean “needed before this particular recovery step,” not “all production traffic always follows this path.” Some tasks can run together; others cannot. If two parallel tasks take ten and twenty minutes, their combined delay may be twenty minutes, not thirty. A shared unavailable dependency can still block both.

Now imagine that backup files are available, but their decryption key can only be retrieved through the failed identity service. More backup copies do not solve that circular dependency. The recovery design needs an authorized, tested way to obtain the required access and keys under that failure scenario. Independent access also needs protection, ownership, and review; creating a forgotten all-powerful recovery account would introduce a different risk.

Turn the target into a testable agreement

NIST’s contingency-planning guidance connects recovery priorities to business impact. Ask which booking functions become harmful to lose first, what manual work remains possible, and how long that workaround lasts. A thirty-minute RPO may be affordable for published opening hours yet inadequate for payments. Different data and services can require different objectives; one impressive company-wide number can hide those differences.

Create a recovery acceptance card with the service and scenario, agreed start and end, target RPO and RTO, selected recovery point, dependency owners, and checks. Record actual times and unresolved reconciliation separately. Include a decision for a missed objective: accept a documented temporary limitation, choose another recovery option, or escalate to the service owner. None should silently redefine the original target after the event.

If compromise is suspected, the newest available copy may not be trustworthy. Choosing an older verified point can increase the data gap while reducing a different risk. Document what supports that choice and what remains uncertain. Try the service outage case to compare recovery progress with evidence about cause.

Turn the idea into a decision

Write the objectives in plain language, test the recovery path, and report actual results against those objectives.