RTO and RPO are the two targets that turn a backup into a recovery plan. RTO (recovery time objective) sets how fast systems must come back. RPO (recovery point objective) sets how much data you can lose. Set both per system, test them, and a failure stops being a business-ending event.
Backup and disaster recovery work only when two numbers are set in advance. The first is your recovery time objective (RTO), the maximum time a system can stay down. The second is your recovery point objective (RPO), the maximum amount of data you can afford to lose. A backup that runs every night with no defined RTO or RPO is a hope, not a plan. This guide explains both targets, shows how to set them for each system, and shows how to test that they hold when a drive fails or ransomware hits.
RTO and RPO are recovery targets, not backup settings. They describe the outcome your business needs, and the backup schedule and recovery infrastructure are then built to meet them.
The recovery time objective (RTO) is the longest a system can be unavailable after a failure before the outage causes real damage. If your RTO for email is 4 hours, your recovery process has to bring email back within 4 hours, so a nightly tape restore that takes a day fails the target on its own.
The recovery point objective (RPO) is the largest gap of data you are willing to lose, measured backward from the moment of failure. If you back up once every 24 hours, your RPO is 24 hours, so a crash at 4 p.m. can erase a full day of invoices, orders, and client notes. Shrinking that gap to one hour means backing up, or continuously replicating, at least every hour.
RTO measures time and RPO measures data. That single distinction is the whole difference, and mixing them up is the most common planning mistake.
Think of a failure at 3 p.m. RPO looks backward and asks how much work you lose between the last good backup and 3 p.m. RTO looks forward and asks how long from 3 p.m. until the system is usable again. A shop can accept losing an afternoon of data but not three days of downtime, or the reverse, so the two targets are set separately for every system that matters.
RTO and RPO are business decisions before they are technical ones, because the cost of downtime, not the capability of the hardware, sets the target. The stakes are measurable, and they are severe for smaller organizations.
Downtime carries a direct hourly price. For large enterprises, ITIC's 2024 survey found that 97 percent say a single hour of downtime costs more than $100,000, and 41 percent put the figure between $1 million and more than $5 million per hour (ITIC, 2024). Those are enterprise numbers, but the pattern scales down: any business that bills by the hour, ships on a deadline, or loses walk-in customers during an outage can put a dollar figure on each hour offline. That figure is what justifies a shorter RTO.
Set the target against that cost. A system whose downtime costs thousands per hour earns a short RTO and a small RPO, and the infrastructure spend that comes with them. A system nobody misses for a day earns a relaxed target and a cheaper design. Matching the two keeps you from overspending on low-value systems and underspending on the ones that pay the bills.
To set your RTO and RPO, rank each system by what its downtime costs, then match the target to that cost. The work is a short, repeatable sequence.
The rule underneath every step is simple. The lower the RTO and RPO, the higher the cost of the backup and recovery infrastructure, so you buy speed only where downtime is expensive.
A backup is a copy of your data, while disaster recovery is the tested process that turns that copy back into a running business. Businesses that own backups but skip the recovery discipline often discover the difference during the outage itself, when a corrupted file, a missing credential, or a slow transfer breaks a restore they assumed would work.
The baseline for reliable copies is the 3-2-1 backup rule, which means keeping 3 copies of your data, on 2 different types of media, with 1 copy stored off-site. The modern extension, 3-2-1-1-0, adds 1 offline or immutable copy and 0 recovery errors confirmed by testing. That last zero is the point, because an untested backup is an assumption, not a recovery capability. Test the restore at least once or twice a year, and again after any major system change, so your real RTO is a measured result rather than a guess.
Ransomware turned backup and disaster recovery from an IT chore into a survival control, because attackers now target the backups first. The threat is no longer rare.
Smaller organizations carry the heaviest share of that risk. The same report found that extortion-related malware is far more common in small-business incidents than in large-enterprise ones, which means an SMB backup design has to assume ransomware, not treat it as an edge case.
Ransomware breaks recovery plans that rely on connected backups, because malware that reaches a network share can encrypt the backups along with the live data. The defense is the immutable, offline copy in the 3-2-1-1-0 rule. An air-gapped or write-once backup cannot be altered by an intruder, so it remains a clean recovery point that lets you meet your RPO even after an attack. Without it, your RTO becomes whatever the attacker allows.
A managed IT partner sets your RTO and RPO, builds the backup and replication to meet them, and tests the restores on a schedule so the targets hold under real pressure. Compeint builds backup and disaster recovery into its managed IT services, pairing 24/7 monitoring with immutable, off-site backups and documented recovery targets for each system you depend on. The result is a plan you can measure, not a folder of backups nobody has ever restored.
RTO measures time and RPO measures data. RTO is how fast a system must be restored after a failure, while RPO is how much data you can afford to lose, set by how often you back up. A 4-hour RTO means email is back within 4 hours, and a 1-hour RPO means you never lose more than an hour of work.
A good RTO and RPO depend on the system, not the whole company. Critical systems such as email, line-of-business applications, and shared files often target an RTO of a few hours and an RPO of one hour or less, while low-priority systems can tolerate a full day. Rank each system by what its downtime costs, then match the target to that cost.
No. A backup is a copy of your data. Disaster recovery is the tested plan and infrastructure that restores that data and your operations within your RTO and RPO. You can have backups and still have no disaster recovery if the restore has never been tested.
The 3-2-1 backup rule means keeping 3 copies of your data, on 2 different types of media, with 1 copy stored off-site. Modern versions extend it to 3-2-1-1-0, adding 1 offline or immutable copy and 0 recovery errors confirmed by testing, which protects backups from ransomware that targets connected files.
Test a disaster recovery plan at least once or twice a year, and again after any major system change. A recovery target you have never tested is an assumption, and untested backups often fail during a real restore when a corrupted file, missing credential, or slow transfer only surfaces under pressure.
Recovery you can measure
We will review your systems, set the right RTO and RPO for each, and test that they hold, with no obligation.
Book a Consultation