Backup & Disaster Recovery: How to Set Realistic RTO and RPO Targets
If your backup strategy does not define recovery time and recovery point objectives, it is incomplete. Here is a practical framework to set and test both.
Backup & Disaster Recovery: How to Set Realistic RTO and RPO Targets
Many businesses say they have backups, but fewer can answer the two questions that actually matter in a crisis:
These aren't technical questions — they're business questions. And if your leadership team hasn't defined the answers, your backup strategy is built on assumptions that may not hold up when it matters.
Why These Two Numbers Matter
Without target recovery outcomes, backup planning becomes guesswork. When an incident happens — and it will — guesswork becomes extended downtime, lost revenue, customer frustration, and avoidable stress.
Consider a real estate firm that loses its transaction management server on a Friday morning. If their RTO is undefined, the IT team makes a best effort to restore. Maybe it takes 4 hours, maybe it takes 2 days. Meanwhile, closings are missed, contracts can't be accessed, and clients start calling competitors.
With a defined 4-hour RTO for that server, the backup solution is specifically designed to meet that target — cloud-based failover, pre-configured recovery procedures, and a tested playbook that gets the team back online within the window. That's the difference between a minor disruption and a business crisis.
Step 1: Identify Tier 1 Systems
Not every system deserves the same recovery investment. Start by listing the applications and data that directly impact revenue, operations, and customer response time.
Tier 1 — Business Critical (strictest RTO/RPO):
Tier 2 — Important but Survivable (moderate RTO/RPO):
Tier 3 — Low Impact (relaxed RTO/RPO):
This tiering exercise directly impacts your IT budget planning because faster recovery requires more investment. Not everything needs instant failover, and classifying systems correctly prevents overspending on low-priority recovery.
Step 2: Define Business Tolerance
For each Tier 1 system, sit down with your leadership team and ask two specific questions:
Max acceptable downtime?
Max acceptable data loss window?
Write these down. Get leadership to sign off. These numbers drive every technical decision that follows.
Typical Targets for SMBs
| System Type | Typical RTO | Typical RPO |
|---|---|---|
| Email / Microsoft 365 | 1-4 hours | 1 hour |
| Line-of-business app | 2-8 hours | 1-4 hours |
| File shares | 4-12 hours | 4-8 hours |
| Accounting / ERP | 2-4 hours | 1 hour |
| Phone system (VoIP) | 1-2 hours | N/A (config backup) |
Step 3: Map Technology to Targets
Different RTO/RPO targets require different backup technologies, and costs scale with speed.
For Aggressive RTO (under 4 hours):
For Moderate RTO (4-12 hours):
For Relaxed RTO (12-48 hours):
For Tighter RPO (under 1 hour):
For Standard RPO (4-8 hours):
Step 4: Test Recovery Quarterly
Backups that have never been tested are just files on a disk — you don't know if they actually work until you try to restore from them. We've seen businesses discover during an actual incident that their "backups" had been failing silently for months.
Build a quarterly test schedule that includes:
Document every test: date, what was tested, time to recovery, pass/fail, and any issues found. This documentation is also compliance evidence for HIPAA, CMMC, and cyber insurance requirements.
Step 5: Include Cyber Recovery Scenarios
Your disaster recovery plan should assume ransomware, not just hardware failure. Traditional backup-and-restore works when a disk dies. It doesn't always work when an attacker has spent days inside your network encrypting everything and deleting backup copies.
Cyber recovery requires additional protections:
Minimum Standard for SMBs
At a minimum, every business should have:
What Happens Without a Plan
We've seen the consequences firsthand working with businesses across the Victor Valley:
Every one of these was preventable with defined targets and tested recovery.
Bottom Line
A backup without a tested recovery process is just hope. Set clear targets, map technology to outcomes, test quarterly, and practice recovery before you need it. The conversation with your leadership team about RTO and RPO takes one hour. The cost of not having it can be measured in days of downtime and tens of thousands of dollars.
Need help building a practical BDR plan for your environment? Talk with our infrastructure team — we'll assess your current backup posture and build a recovery plan around your actual business requirements.
