Buying more storage does not define a recovery objective. An SME first needs to decide which business activities cannot wait, how much recently created information can reasonably be recreated, and when each service must be usable again after an interruption. RPO and RTO turn those decisions into recovery targets that can be designed and tested.
They are not numbers to borrow from another organisation. A business may accept a delayed return to a historic archive while requiring a fast recovery for order processing. Treating both as identical either wastes effort or leaves the critical process under-protected.
Put the two questions in plain language
Recovery Point Objective (RPO) asks how old the restored data may be after an incident. It represents the point in time to which the organisation needs to recover. In practice, it is a way to discuss the maximum amount of recent work that can be recreated or lost before the business impact is unacceptable.
Recovery Time Objective (RTO) asks how long the service may be unavailable. It is not merely the time required to copy backup data. It includes incident recognition, authority to start recovery, locating the selected recovery point, making hardware and access available, restoring dependencies and receiving business acceptance.
A shorter RPO generally drives more frequent capture of relevant data. A shorter RTO generally demands a more prepared recovery route. Both can raise operational effort and cost, which is why the targets must be justified by the process they protect.
Run a small business-impact workshop
For an SME, the workshop can be short and practical. Invite the owners of the three to five functions that would interrupt sales, customer service, delivery, production or another core obligation. Do not begin with a server list. Ask each owner:
- What happens after one hour, half a day and a full day without this function?
- Which recent data would have to be recreated if the last available point were older than expected?
- What people, applications, configurations, connections and equipment must be present before work can resume?
- Who can accept that the function is genuinely usable again?
The answers expose the difference between a technical asset and a business service. A database may be restored while the process remains unavailable because a linked application, account, network dependency or operational instruction has been forgotten. RTO must cover that complete return-to-service path.
Use a few recovery tiers, not a target for every file
Avoid creating a unique pair of numbers for every system. Start with two or three clear tiers, such as critical, important and deferrable. Each tier should have a provisional RPO, a provisional RTO, an owner and a recovery exercise that can validate the result.
This creates useful trade-offs. A critical function may need a frequent recovery point and a prepared restoration route. An important function may tolerate a longer recovery window. A deferrable service may be restored after the main business processes have returned. The point is not to rank technology; it is to put limited budget and attention where the business sees the greatest impact.
Convert targets into design questions
RPO affects the age of the recovery point that must be available. That leads to questions about backup frequency, application-consistent data, manual entries between scheduled runs and any information kept outside the usual backup scope.
RTO affects the entire recovery journey. Consider the amount of data to recover, the order in which dependencies must return, availability of a suitable medium, access to a separate copy, replacement hardware, backup-software access and the time needed for the process owner to test the result.
Only after that conversation should the team evaluate capacity, media rotation or an architecture. A removable medium can support a separated copy; it does not, by itself, guarantee a target RPO or RTO. The chosen design must be measured against the defined requirements in the real environment.
A fictional worked example
Consider an SME whose order-processing application depends on an application service and an associated data store. The business owner decides that no more than two hours of order entry should need to be recreated and that the service must be usable within four hours of a recovery decision. Those are working targets: RPO of two hours and RTO of four hours for that process.
The IT team does not infer from this that a particular product will meet the objectives. It measures a representative recovery set, identifies all dependencies, confirms which copy can be used, rehearses the recovery and measures the complete duration. If obtaining the media, preparing the environment and recovering the service take more than four hours, the target is not being met. The organisation must improve the process or reconsider the business target openly.
Its document archive may have a different profile: data from the previous business day may be acceptable and the service may be restored after core order processing. This is not a weaker design; it is a documented prioritisation of different business consequences.
Use a decision table that can be tested
The following table can be added as a Gutenberg Table block or used in the workshop. It records decisions and evidence rather than pretending to be an SLA.
| Business process | Impact of interruption | Target RPO | Target RTO | Recovery dependencies | Business owner | Latest test outcome |
|---|---|---|---|---|---|---|
| Order processing | Example: customer service stops | To be agreed | To be agreed | Application, data, access | To be named | Record after test |
| Document archive | Example: consultation can wait | To be agreed | To be agreed | Data, search, permissions | To be named | Record after test |
Review the table whenever a process, application, data volume, supplier or team changes. A target without a named owner and evidence from a test is an assumption, not a recovery commitment.
Measure the target through recovery, not backup completion
To test RPO, restore a representative point and compare its data age with the agreed tolerance. To test RTO, time every stage from the decision to recover until the business owner accepts the service. Include ordinary friction: locating a separated medium, accessing a replacement system and working without the usual administrator.
When the result misses the target, identify the reason instead of merely changing the number in the table. The cause may be inadequate capture frequency, an oversized recovery set, unavailable media, a missing dependency, access control or an unpractised procedure. The business and IT team can then decide whether to improve the recovery capability or approve a different target.
Use the restore-testing checklist and the 3-2-1-1-0 rule to make the assessment operational. Add the media-sizing and RDX/LTO guides to the internal links when their localised versions are published. If the calculated target requires a specific architecture or validation, invite the reader to scope the project with Tandberg Data.
Share this guide
