On this page
Recovery time objective (RTO) is the time target for getting a system or process back. Recovery point objective (RPO) describes how far back you can afford to go when restoring data. If you need order entry working within four hours and can recreate only one hour of orders, those are two separate requirements. One concerns downtime. The other concerns work lost between the restored copy and the outage.
.jpg){kind=link}
Read a recovery timeline
Suppose an outage starts at 11 a.m. Your last usable copy was taken at 9 a.m. Staff can enter and look up orders again at 2 p.m. The observed recovery time is three hours, and the recovered data is two hours behind the outage. Against a four-hour RTO and one-hour RPO, the restore met the time target and missed the data target. The two-hour gap describes the state of the restored data. It doesn’t tell you how many orders were lost. If order confirmations also reached a separate mailbox, staff may be able to reconstruct some or all of the missing orders.
Set targets based on what staff can recover
| Business process | What counts as working again | How to judge tolerable data loss |
|---|---|---|
| Order entry | Staff can find customers, enter an order and confirm it | Count the orders that would need re-entry and find the source records |
| Payroll | An authorized employee can open payroll and prepare the next run | Check whether time records, changes and approvals can be reconstructed |
| Shared project files | Staff can open and save the current working files | Determine whether teams can reconstruct edits made after the restored copy |
Translate a target into capacity
Consider a scheduling team that can reconstruct about 12 bookings from email and phone notes in an hour. If the busiest hour produces 20 bookings, a one-hour recovery point might mean more re-entry than the staff can handle while taking new calls. Look at the busiest part of the day, find where the original booking information survives and decide whether you need fresher copies or a better fallback record.
Run the same exercise for downtime. A clinic may be able to confirm appointments from a printed schedule for an hour. That workaround buys time for one task while other tasks still depend on the live application. Write down which workflows can continue manually and which ones determine the recovery deadline.
Include the dependencies
The timer should reflect what employees need. A restored server can be running while users still cannot sign in, an application license is missing or a connection to a vendor is down. Define when you start timing, which dependencies are in scope and which employee action shows that work can resume. A partial workaround can have its own target if it lets the business keep serving customers while full recovery continues.
Run a restore test and record the evidence
Backup frequency describes when copies are attempted. The recovery point depends on the newest usable copy under the failure you are testing. During a ransomware incident, for example, the most recent copy might contain changes you cannot trust. Record the timestamp of the copy you actually restored. Record when a user completed the agreed task, how much work had to be recreated and where the restore stalled.
Record a test so someone else can reproduce it
| Field | Example entry |
|---|---|
| Scenario | Office server is unavailable and must be restored on replacement hardware |
| Start and finish | 11:00 a.m. outage marker, 2:00 p.m. successful order entry |
| Recovered data timestamp | 9:00 a.m. order database recovery point |
| Business validation | Employee created a test order and reopened an existing one |
| Scope and exclusions | Orders and customer lookup tested, overnight accounting export still pending |
| Observed results | 3 hours to resume order entry, with a 2-hour data gap |
Use timestamps from the restore and the application where possible. For example, a backup job that finishes at 9:15 may contain data as of 9:00. If a test restores into an isolated environment with pre-staged hardware, record that as well. Getting a replacement server delivered or arranging access after hours can add time in an actual incident.
Test a failure that challenges the target
An accidental deletion test can prove you can bring back one folder. It says little about rebuilding an entire environment. Test the scenarios that matter most to the business, such as a failed server, an unavailable cloud administrator account or having to select a known-good copy after a security incident. A different scenario may require a different recovery order or a different way to verify the restored data.
If the test falls short, capture the first delay that materially affected the result. A test that spent two hours locating encryption keys points to a different fix from a test that spent two hours copying data. Assign the fix, then repeat that part of the test under comparable conditions.
Use the numbers to make a decision
When a target is missed, identify which side needs work. In the order-entry example, check why the newest usable copy was two hours old. If copies are only taken every two hours, shorten the interval and test again. If an hourly job ran but the result couldn’t be restored, fix the reason that copy was unusable. In the next test, ask staff to reconcile the restored orders against confirmation records so you can measure the remaining work. A slow return to service may need a different restore method, a replacement system ready sooner or better documentation of dependencies. Put a named owner next to each target and revisit it when the work changes.