Backup & Disaster Recovery: How to Set Realistic RTO and RPO Targets
Business Continuity
January 13, 2026
7 min read

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.

Sonic Systems Team
Sonic Systems Team
Managed IT and cybersecurity specialists serving Southern California businesses

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:

  • RTO (Recovery Time Objective): How long can your systems be down before the business impact becomes unacceptable?
  • RPO (Recovery Point Objective): How much data can you afford to lose, measured in time since the last successful backup?
  • 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):

  • Email and communication systems
  • Line-of-business applications (EHR, ERP, CRM, accounting)
  • Customer-facing systems (websites, portals, phone systems)
  • Financial and payment processing systems
  • Tier 2 — Important but Survivable (moderate RTO/RPO):

  • File shares and document management
  • Internal collaboration tools
  • Reporting and analytics systems
  • Development and testing environments
  • Tier 3 — Low Impact (relaxed RTO/RPO):

  • Archive data
  • Historical records not needed daily
  • Non-critical internal tools
  • 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?

  • Can the business survive 1 hour without this system? 4 hours? 24 hours?
  • What's the financial impact per hour of downtime? (Use our guide on the real cost of IT downtime to calculate this.)
  • Are there contractual SLAs with your customers that define your obligations?
  • Max acceptable data loss window?

  • If you had to restore from backup, could you re-enter 15 minutes of work? 1 hour? A full day?
  • Is any data irreplaceable if lost (signed contracts, patient records, financial transactions)?
  • What's the manual effort to reconstruct lost data?
  • 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):

  • Cloud-based disaster recovery (DRaaS) — your server is replicated to the cloud in near-real-time. When the local server fails, a cloud instance spins up automatically. Recovery time: minutes to 1 hour.
  • Hot standby server — a secondary server mirrors the primary and takes over immediately on failure.
  • Cost: $500-2,000/month depending on the workload size.
  • For Moderate RTO (4-12 hours):

  • Image-based backups with local appliance — a backup appliance stores full system images locally with cloud replication. Recovery involves booting from the appliance or restoring to new hardware.
  • Cost: $300-800/month.
  • For Relaxed RTO (12-48 hours):

  • Cloud-only backup — data is backed up to the cloud on a schedule. Recovery requires provisioning new hardware and downloading data.
  • Cost: $100-300/month.
  • For Tighter RPO (under 1 hour):

  • Near-continuous replication or snapshots every 15-30 minutes
  • Requires more bandwidth and storage
  • For Standard RPO (4-8 hours):

  • Scheduled backups 3-6 times per day
  • Standard approach for most SMB workloads
  • 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:

  • File-level restore test — pick random files from different dates and restore them. Verify they open correctly and content is intact.
  • Full server/application restore test — bring up a complete server from backup in an isolated environment. Verify applications launch and data is accessible. Time the process — this is your actual RTO, not the theoretical one.
  • Documentation review — are recovery procedures current? Do they reference the right systems, credentials, and contacts?
  • Runbook walkthrough — walk through the disaster recovery plan with everyone who would be involved. Make sure people know their roles.
  • 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:

  • Immutable backups — backup data that cannot be modified or deleted for a defined retention period, even by administrators. This prevents ransomware from encrypting your backup copies.
  • Air-gapped or isolated backup copies — at least one copy of your backups should be stored in a location that is not accessible from your production network.
  • Separate recovery credentials — your backup system's admin credentials should not be the same as your domain admin credentials. If an attacker compromises Active Directory, they shouldn't also get your backup system.
  • Recovery in a clean environment — don't restore onto compromised infrastructure. Have a plan for recovering into a known-clean environment.
  • Minimum Standard for SMBs

    At a minimum, every business should have:

  • Documented backup policy and retention schedule
  • Offsite or cloud backup copy (the 3-2-1 rule: 3 copies, 2 different media types, 1 offsite)
  • Quarterly restore testing with documented results
  • Leadership-approved RTO/RPO targets for Tier 1 systems
  • Immutable backup protection against ransomware
  • Backup monitoring with daily success/failure alerts reviewed by your IT support team
  • Documented recovery procedures that someone other than the backup admin can follow
  • What Happens Without a Plan

    We've seen the consequences firsthand working with businesses across the Victor Valley:

  • A medical practice lost 3 days of patient records because their backup hadn't completed successfully in 2 weeks and nobody was monitoring it
  • A construction company paid $45,000 in ransomware recovery costs because their backups were on the same network as the encrypted servers
  • An accounting firm during tax season lost 8 hours of work across 15 employees because their RPO was 24 hours and nobody had considered the impact
  • 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.

    Tags:
    backup
    disaster recovery
    RTO
    RPO
    business continuity
    Published on
    January 13, 2026

    Ready for Predictable IT Support?

    Get proactive support, stronger security, and a roadmap aligned to your business goals.