Your Backups Are Not a Recovery Plan
A green backup dashboard tells you data was copied. It says nothing about how long you would be down. Build real RTO and RPO numbers with a free worksheet.
The short answer
Recovery time objective is how long you can be down before damage becomes serious; recovery point objective is how much data you can afford to lose, measured in time. Both are business decisions set per system, not company-wide, because the input is what an hour of downtime costs in your busiest week.
Every business we assess has backups. Almost none of them can tell us how long a restore takes.
Those are different questions, and the gap between them is where companies lose weeks. A backup is a copy of data. A recovery plan is a documented, tested answer to the question of how you resume operating. The dashboard that shows green every morning is reporting on the first thing while owners read it as evidence of the second.
The two numbers
Recovery time objective is how long you can be down before the damage becomes serious. Recovery point objective is how much data you can afford to lose, measured in time.
Both are business decisions, not technical ones. Your IT provider cannot set them for you, because the input is what an hour of downtime costs your specific company in a specific month.
Set them per system, not for the company as a whole. Setting a four-hour RTO for everything is expensive and unnecessary. A dental practice needs its practice management and imaging systems back in hours. Its marketing site can be down for two days without material harm. Blanket objectives cause you to overspend on the trivial and underspend on the critical.
How to actually calculate downtime cost
Take one system. Ask what stops if it is unavailable, in your busiest week rather than an average one.
Direct revenue that cannot be recovered. A restaurant cannot sell Saturday's covers on Tuesday. A law firm can bill the hours later. That distinction changes the number by an order of magnitude.
Idle labor. People being paid to wait, at loaded rates, including the ones who could work but cannot because the system they need is the same one.
Recovery labor. Overtime, contractors, the manual reconstruction of transactions that happened during the outage.
Contractual exposure. Service level penalties, missed regulatory deadlines, and in construction, delay claims.
Customer loss. The hardest to quantify and the one that dominates in the long run. Estimate conservatively rather than skipping it.
Do this for your top five systems and the priority order will be obvious. It usually surprises people. The system everyone assumed was most critical is frequently third.
What the technical plan has to include
Once you have objectives, they translate into requirements.
A local copy for fast restores and an offsite copy for site loss. The offsite copy needs to be immutable, meaning it cannot be altered or deleted for a set retention window even by a compromised administrator account. Ransomware operators now specifically target backup infrastructure before they encrypt, and a mutable backup accessible with domain credentials is not a backup during the only event that matters.
Coverage for cloud data. Microsoft 365 and Google Workspace replicate for their own availability, which is not the same as backing up your data against deletion, ransomware, or a departing employee clearing a mailbox. Their own terms recommend third-party backup. Most small businesses have not read that far.
Documented restore procedures that someone other than the author has followed successfully. If your recovery depends on one person's knowledge, your RTO is however long it takes to reach them, plus travel.
Testing, which is the whole point
Quarterly, restore a single file and a single mailbox. This catches configuration drift and takes fifteen minutes.
Semi-annually, restore a full server or workload to isolated infrastructure and confirm the application actually starts and the data is coherent. Restoring files is not the same as restoring a working system, and databases in particular fail in ways a file-level check will never reveal.
Annually, run a tabletop for a full site loss with the leadership team and time it honestly.
Write down the actual elapsed time every time. That number, not the vendor's marketing figure, is your real RTO. In our experience the first honest measurement is typically three to five times longer than what people assumed.
The uncomfortable finding
The most common discovery when a client first runs a real recovery test is not that the backups failed. It is that the backups worked and the recovery still took four days, because nobody had documented the order of operations, the license keys were in a system that was itself down, and the person who knew the environment was on a plane.
Backups are a technology purchase. Recovery is an operational capability. You can buy the first and only build the second.
Get the worksheet
The Recovery Objectives Worksheet has a downtime cost calculator by system, an RTO and RPO register, a dependency map so you catch the systems that have to come back before others, a restore test log, and a test result tracker with your measured times against your targets.
Fill it in once with your leadership team, in one meeting. It is the most useful two hours of continuity work available to a small business.
Frequently asked questions
What is the difference between RTO and RPO?
Recovery time objective is how long you can be down before the damage becomes serious. Recovery point objective is how much data you can afford to lose, measured in time. Both are business decisions rather than technical ones, because the input is what an hour of downtime costs your company.
Do I need to back up Microsoft 365 or Google Workspace?
Yes. Both platforms replicate for their own availability, which is not the same as backing up your data against deletion, ransomware, or a departing employee clearing a mailbox. Their own terms recommend third-party backup, and most small businesses have not read that far.
How often should backups be tested?
Quarterly, restore a single file and a single mailbox, which takes about fifteen minutes. Semi-annually, restore a full workload to isolated infrastructure and confirm the application starts and the data is coherent. Annually, run a full site-loss tabletop and time it honestly.
What is an immutable backup and why does it matter?
A copy that cannot be altered or deleted for a set retention window, even by a compromised administrator account. Ransomware operators now specifically target backup infrastructure before encrypting, so a mutable backup reachable with domain credentials is not a backup during the only event that matters.
Related reading
- Score Your IT Provider: The 40-Point 3AM Test Audit
- Run a 60-Minute Ransomware Drill With Your Leadership Team
- Build an IT Budget From Operating Priorities
- How to Switch IT Providers Without a Bad Month
- Read Your Cyber Policy Before You Need to Use It
- The Quarterly Technology Review Every Owner Should Demand