Guide · Recovery Planning

RTO vs RPO: What Small Businesses Should Actually Plan For

RTO and RPO are two numbers that decide how well your business survives a failure. RTO is how long you can be down. RPO is how much data you can afford to lose. This guide explains both in plain language, how to set realistic targets for a small business, and how they decide your backup frequency and recovery plan.

Last updated: 25 October 2026By Ktech Media Solutions

Data Recovery Backup Business continuity Explainer

2targets explained

16FAQs answered

10min read

Recovery targets

RPO: data you can loseWaiting✓ Defined

RTO: time you can be downWaiting✓ Defined

Test restoreTiming✓ Measured

Timeline showing a failure event with data loss measured backward as RPO and downtime measured forward as RTO

Quick answer

RTO: Recovery Time Objective, the maximum time you can be without a system after an outage.
RPO: Recovery Point Objective, the maximum data loss you can accept, measured in time.
Simple picture: RPO looks backward from the failure. RTO looks forward to when you are working again.
They drive your design: Backup frequency must fit your RPO; restore speed must fit your RTO.
Zero is unrealistic: Microsoft notes zero downtime and zero data loss are often unrealistic targets.
Test them: Targets you have never tested are guesses.

RTO and RPO in plain language

Timeline diagram showing RPO looking back from the failure to the last good copy and RTO looking forward to recovery

RTO: Microsoft defines it as the maximum amount of time available to bring resources online after an outage or problem.
RPO: Microsoft defines it as the point in time to which data should be recovered, equal to the maximum data loss the business will accept.
AWS wording: RTO is the maximum acceptable delay between an interruption and restoration of service. RPO is the maximum acceptable gap between the data on the recovery site and the latest data when disaster strikes.
Example: If your RPO is 4 hours, you can lose up to 4 hours of work. If your RTO is 2 hours, you must be back working within 2 hours.
Different for each system: Email, accounting and a website won't share the same targets.

Why they matter for a small business

They turn "we have backups" into a promise: A backup that restores in three days doesn't meet a two-hour RTO.
They set your budget: Tighter targets cost more.
They guide priorities: What gets restored first.
They show gaps: Often the real RPO is far worse than assumed.
They matter in ransomware: Ransomware can take systems down for days and may make recent backups unusable. See ransomware recovery.

How to set your RTO

List your systems: Email, accounting, customer records, file shares, website, phones.
Ask what stops without each one: Sales, invoicing, production, support.
Estimate the cost of downtime: Lost revenue, idle staff, missed deadlines, customer impact. Microsoft suggests using a cost per hour of downtime to set realistic targets.
Choose a time per system: Minutes, hours, a day or several days.
Remember the slowest part: Microsoft notes the overall RTO is set by the slowest component to recover.
Write it down: Agree it with whoever pays for it.

How to set your RPO

Ask how much work you can redo: An hour of invoices, a day of orders, a week of designs.
Check how data changes: Constantly, daily or rarely.
Choose a time per system: From near-zero to a week or more.
Match backup frequency: Microsoft's example: with a 15-minute RPO but 30-minute log backups, the RPO is missed.
Consider regulations and contracts: Some clients or rules expect specific recovery levels.
Review each year: Data and business change.

Measure what really happens: RTA and RPA

Targets compared with measured results in a restore test

RTA and RPA: Recovery Time Actual and Recovery Point Actual are what a real test measures. Compare them with your targets.
Time a test restore: Run it, time it and note what slowed you down.
Know when the clock starts: At the failure, or when someone notices it.
RTO is more than restoring: It includes detecting the problem, deciding what to do, validating the data and giving users access again.
Cost trade-off: Tighter targets cost more, so set them from the cost of downtime, not from what sounds good.

Typical target ranges

These are AWS example tiers for applications, not rules for your business.

Tier	Application type	Example RTO	Example RPO
Tier 1	Mission-critical	15 minutes	Near-zero
Tier 2	Important, not mission-critical	About 4 hours	About 2 hours
Tier 3	All other applications	8 to 24 hours	About 4 hours

Small business reality: Many small firms set targets of hours to a day for most systems and tighter targets for one or two critical ones.
Don't copy blindly: Use the numbers to start a conversation, then set your own.

Matching backups and recovery to your targets

Diagram linking tighter RTO and RPO targets to more frequent backups, faster restore options and higher cost

Backup interval must be shorter than RPO: Backing up daily means you can lose up to a day.
Restore time must fit RTO: Microsoft notes that if copying a backup takes three hours but the RTO is two, the RTO is missed.
Tighter targets cost more: More frequent copies, faster storage, standby systems and more testing.
Looser targets can use simple restores: Backups restored to rebuilt systems are cheaper but slower.
Include the ransomware case: If attackers destroy recent backups, your real RPO is the last clean copy.
Use an immutable copy: See immutable backups explained.

Start with your five most important systems

Five business-critical systems ranked by downtime impact

Identity and email: Sign-in and mail stop everything else.
Finance: Invoicing, payments and records.
Order or booking intake: How customers reach you.
One main business application: The system your staff cannot work without.
Customer data and files: Shared drives and key databases.
Do a simple business impact analysis: For each, ask what an hour of downtime costs and how much data you could afford to lose.
Put it in writing: If an IT provider supports you, the targets belong in the service agreement.

Common mistakes

Never writing the numbers down: If it isn't written, it isn't a target.
Assuming backup equals recovery: A backup that restores slowly misses the RTO.
Setting zero targets: Zero downtime and zero data loss are often unrealistic, and expensive.
One target for everything: Systems differ.
Ignoring dependencies: An application depends on identity, network and database being up first.
Never testing: Test restores and time them.
Not reviewing: New systems and growth change the answer.

India: what to watch for

Power and connectivity: Frequent power cuts and internet issues affect restore time, so plan for them.
Small-team dependency: Many Mumbai businesses depend on one person who holds the knowledge. Document the process.
Reporting duties: Incidents may need reporting under CERT-In and DPDP rules. Include that in your plan.
Local help: Our backup and disaster recovery service helps set targets and match backups.

Limits and honest caveats

Definitions from cloud vendors: Microsoft and AWS write for their own platforms, but the ideas are general.
Tiers are examples: AWS's ranges are illustrations, not standards for you.
No promised targets: We can't say what your RTO and RPO should be without knowing your business.
Costs vary: We don't quote prices.

How our services help

Backup and disaster recovery: Set targets and design backups to meet them.
Business data recovery: For servers and company data.
Ransomware data recovery: If an attack hit your systems.

Frequently asked questions

Still have a question? Ask our team

RTO is how long you can be down before the business is seriously harmed. RPO is how much recent data you can afford to lose. RTO looks forward from the failure to recovery, and RPO looks back to the last good copy.

Recovery Time Objective. Microsoft defines it as the maximum amount of time available to bring resources online after an outage or problem.

Recovery Point Objective. Microsoft defines it as the point in time to which data should be recovered, equal to the maximum data loss the business will accept.

It depends on how fast your data changes and how much work you can redo. Many small firms accept hours to a day for most systems and tighter targets for a few critical ones. Set it with the people who use the data.

At least as often as your RPO. If you can only lose two hours of work, back up at least every two hours. For slower-changing data, daily or weekly may be enough.

Add lost revenue, idle staff time, missed deadlines and customer impact for one hour. Microsoft suggests using an hourly cost to judge how much to spend on recovery.

Rarely, and it is expensive. Microsoft notes zero downtime and zero data loss are often unrealistic. Aim for the best target you can afford and test.

RAID can keep a system running through some disk failures, which helps availability. It is not a backup and doesn't protect against deletion or ransomware.

Ransomware can take systems down for days and can destroy recent backups, so the real RPO is the last clean copy. Immutable and tested backups protect both targets.

No. Set targets per system based on impact. Accounting and customer systems usually need tighter targets than archived files.

Restore a system from backup in a clean environment and time it. Check how recent the restored data is. Compare both to your targets and fix gaps.

The business, not only IT. IT can design for them, but the business decides what downtime and data loss it can accept.

No. RPO is the amount of data you can afford to lose. Backup frequency is how you achieve it. A daily backup can't meet a 1-hour RPO.

Yes. Cloud services have their own retention and recovery options, so check what your provider keeps and for how long, and set targets for your own data.

Recovery Time Actual and Recovery Point Actual. They are the times and data loss you actually achieved in a test or incident, to be compared with your RTO and RPO.

A short exercise that lists your key systems and estimates what downtime and data loss would cost for each. It tells you which targets to set first.

Go deeper: the guides in this series

Sources4 references

Ready to find out where you stand?

If you want clear recovery targets and backups that meet them, talk to our team. We'll help you set realistic numbers and test them.

Contact our backup and recovery team