Backup and disaster recovery is sold as one product and it is two. Backup is copies of data, and it answers whether you can get a file back. Disaster recovery is the ability to run again somewhere else, and it answers whether the business can operate while the original is broken.
Two objectives separate them: the RPO, how much data you can lose, and the RTO, how long you can be down. Everything else in a quote is a means of hitting those two figures at a price.
- Backup is copies; disaster recovery is the ability to run again
- RPO is how much data you can lose, RTO is how long you can be down
- Both are promises until a restore test turns them into facts
- The gap between the contract and the measurement is where failures live
- Most quotes differ on the RTO, not on the RPO
On this page
Two productsThe two halves are different products
Providers sell backup and disaster recovery solutions under the short name BDR. Read a BDR quote and notice that most of it describes backup. Retention, schedules, encryption, storage tiers, immutability. All of that is about copies of the data, and copies are the easy half.
Backup answers a narrow question well. Somebody deleted a folder, a database is corrupt, a machine was encrypted, and there is a clean copy of the data from before. The 3-2-1 rule is a backup rule, and a business that follows it has solved the data protection half of the problem.
Backup vs disaster recovery becomes a real distinction when the question changes. The building is unreachable, the server room is under water, the hypervisor cluster is gone, or the encryption reached the production systems. Nobody wants a file. They want to recover operations: the critical business systems answering, today, from somewhere else.
The distinction is whether there is somewhere to run. A backup is data at rest in a second location. Disaster recovery is compute, storage, network and licensing standing ready to become production, plus the plan and the practice to move critical systems onto it.
That difference is why the two halves are priced so differently. Backups are cheap and getting cheaper. Standby capacity is not cheap, because somebody is paying for capability that produces nothing until the day it does.
It is also why cloud has changed the second half more than the first: renting the recovery capacity only at failover is a different cost shape from owning it.
The two numbersRPO and RTO, defined properly
RPO and RTO come from contingency planning rather than from marketing, and the formal definitions are worth reading because they are more precise than the vendor paraphrases, which usually describe RPO as tolerable data loss and RTO as tolerable downtime.
NIST SP 800-34 Rev. 1 defines the recovery point objective as "the point in time to which data must be recovered after an outage," and the recovery time objective as "the overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission or mission/business processes."
| RPO | RTO | |
|---|---|---|
| The question | How much data loss is tolerable | How long may we be down |
| Direction in time | Backward from the incident | Forward from the incident |
| Set by | Backup frequency | Standby capacity and the recovery plan |
| Reduce the objective by | Running backups more often | Paying for somewhere to run |
| Cost of halving the objective | Roughly linear | Often a step change |
| A typical RPO or RTO claim | 15 minutes to 24 hours | 1 hour to several days |
Read the last two rows together, because they are the whole economics of backup and disaster recovery. Improving the RPO is a schedule change and more storage. Improving the RTO usually means buying a second environment, which is why a provider will happily tighten your RPO in a negotiation and resist tightening your RTO.
The tiersWhat you are actually buying at each tier
| Tier | RPO, the data loss | RTO, the downtime | What is standing by |
|---|---|---|---|
| Backup only | Hours to a day | Days | Nothing, you rebuild first |
| Backup with local appliance | Hours | Hours | Enough to boot a few machines on site |
| Replication to a second site | Minutes | Hours | Hardware waiting at another location |
| Cloud recovery on demand | Minutes | Hours | Cloud capacity you rent at failover |
| Continuous replication | Near zero RPO | Minutes | A live second copy, always running |
The first row is where most small businesses actually sit, and it is a defensible choice as long as everybody knows the RTO is days. It stops being defensible when it is called disaster recovery in a business continuity document nobody reads.
The middle rows are what most backup and disaster recovery services deliver to an MSP client: an appliance on site that can run the critical systems, replicating that data to a second location for the case where the site itself is gone.
In the cloudCloud backup and disaster recovery
Cloud backup and disaster recovery moves one or both halves off your own hardware. Cloud backup sends the copies to a provider's storage instead of to tape or a second office.
Cloud based disaster recovery, usually sold as disaster recovery as a service or DRaaS, also lets you start the protected systems in the provider's infrastructure after a disaster.
The attraction for small organizations is the cost shape. A second site is hardware you own and power all year. In the cloud you pay for storage all year and for compute only during a test or a real event. That puts a usable RTO within reach of a business that could never fund a second site.
The AWS disaster recovery whitepaper sorts cloud strategies into four approaches, from cheapest and slowest to recover to most expensive and fastest: backup and restore, pilot light, warm standby, and multi-site active/active. Data backup and disaster recovery sold to small organizations typically sits at the first or second.
Three things stay your problem in any cloud strategy. A full restore runs at the speed of your internet connection. Security of the backup account needs separate credentials and multifactor authentication, because an attacker who reaches it can delete the copies.
The third is speed for the common event, which is one failed server. A hybrid design, a local appliance plus the cloud, still recovers from that fastest.
The planWhat a disaster recovery plan contains
A disaster recovery plan is the written half of the product, and it is the IT part of the wider business continuity plan. Continuity planning covers people, premises and suppliers. The DR plan covers how IT operations recover. A usable one is short and answers the following.
- Which disasters it covers. Ransomware, hardware failure, human error, fire or flood, a cloud or internet outage. Each event takes out different things.
- Which systems come back first. Workloads ranked in tiers by what the business loses per hour, taken from the business impact analysis.
- The RPO and RTO for each tier, and the backup strategy that meets them: what is copied, how often, and where the copies live.
- Where operations run during recovery: the local appliance, a second site, or the cloud.
- Who does what. Who declares the disaster, who runs the recovery, who talks to staff and customers, and how to reach them when email is down.
- When it is tested, and where the results are kept.
Keep a copy somewhere that survives the disaster. A plan stored only on the file server is part of the outage.
The argumentThe only number that counts is the measured one
Here is the argument the rest of the page exists for.
An RTO in a contract is a promise about a system nobody has operated under the conditions that make it necessary. An RTO measured in a real restore test is a fact. The two are routinely hours apart, and every hour of that gap is unbudgeted downtime that the business plan never accounted for.
The gap has ordinary causes, not dramatic ones. The data restore runs at the speed of the slowest link, which is often the internet connection nobody sized for a full recovery. The standby hardware is smaller than production and every system runs, slowly.
A system depends on a service on a machine that was not in scope. The person who knew the runbook has left. The credentials to start the recovery are in the system being recovered.
None of those appear in a proposal, and every one of them adds time to the real RTO. All of them appear in a test.
Which produces the one question worth asking a backup and disaster recovery provider above all others: when did we last restore, what did it actually take, and can I see the result.
A provider who tests quarterly and shows the numbers is selling something different from a provider quoting the same figures from a datasheet, and the price difference between them is usually smaller than the difference in outcome.
QuestionsWhat to ask before signing
What is the measured RTO, not the contracted one. If the answer is the same number as the contract, ask when that recovery time was last measured. MTTR is the number that answers it, and it is a measurement rather than a promise.
What does a full restore depend on? Bandwidth, hardware, licensing and people, named specifically.
Where do the recovery credentials live? Credentials stored inside the environment being recovered are the most common single point of failure in a plan that otherwise reads well.
What data is out of scope? Almost every plan excludes something: a SaaS platform, a line of business application, a workstation fleet, a phone system.
Who declares a disaster? A named role, reachable out of hours, or the plan starts with a meeting.
How often are the backups and the recovery tested, and can I see the last report? The answer to this one predicts the others.
PitfallsWhere people go wrong
Calling a backup product a disaster recovery plan. The backups are real and the recovery time is days. Both facts can be true, and only one of them is usually written down.
Negotiating the RPO because it is the easy number. A provider will tighten the backup schedule cheerfully, and a smaller RPO means less data loss for very little money. The objective that hurts during an incident is the other one.
Never running a full test. A file restore proves the data protection works. It proves nothing about the recovery time, which is the figure the business continuity plan depends on.
Leaving the recovery credentials inside the thing being recovered. Domain credentials, the password manager, the documentation platform. All three are commonly unreachable at exactly the moment they are needed.
Assuming SaaS data is covered. Microsoft and Google keep the service running. Protection of your data against deletion, ransomware or a departing administrator is a separate product with its own retention terms.
Buying to a compliance requirement rather than to an operational one. The regulation sets a floor. The business impact analysis sets the real RPO and RTO, and the two are rarely the same.
ComparisonBackup and disaster recovery, side by side
| Criterion | Backup | Disaster recovery |
|---|---|---|
| Answers | Can I get the file back | Can the business operate |
| What exists | Copies of data | Somewhere to run |
| The objective that measures it | RPO | RTO |
| Cost driver | Storage for the backups | Standby capacity |
| Fails because of | A data copy nobody verified | A dependency nobody listed |
| A test looks like | Restoring one file | Running critical systems elsewhere |
| Without the other | You have data and no operations | You have capacity and nothing to load |
The bottom row is why they are sold together despite being different products. Neither one is worth much alone, and a quote that is strong on one and silent on the other is not a disaster recovery quote.
FAQFrequently asked questions
What is backup and disaster recovery?
Two things sold as one. Backup is copies of data so a file or a system can be restored. Disaster recovery is the capacity, plan and practice to run critical business systems somewhere else while the original is unavailable.
What is the difference between backup and disaster recovery?
Backup answers whether you can get the data back. Disaster recovery answers whether you can operate. Copies alone leave you with data and no way to use it until something is rebuilt.
What does BDR stand for?
Backup and disaster recovery. It is the usual name for the bundled service an IT provider sells, covering both halves under one contract.
What is RPO?
The recovery point objective. NIST defines the RPO as the point in time to which data must be recovered after an outage, which in practice means how much data loss you can afford, set by how often backups run.
What is RTO?
The recovery time objective: how long systems may be in the recovery phase before the outage does unacceptable damage to the business. The RTO is set by what is standing by, not by the backup schedule.
Which matters more, RPO or RTO?
The RTO, in almost every real incident, because it is the expensive objective and the one providers resist tightening. An hour of data loss hurts; being down for three days is what closes businesses.
How much does backup and disaster recovery cost?
It depends almost entirely on the RTO. Data copies are cheap. Standby capacity that can become production is not, and the price steps up each time the recovery time objective comes down.
How often should disaster recovery be tested?
Often enough that the measured RTO is current and the people involved have done it before. Quarterly is a common standard, and annually is the point at which the plan is documentation rather than a capability.
Do backups protect against ransomware?
Only if the backups themselves cannot be encrypted or deleted by the same access. That is what immutable backups are for, and it is worth confirming rather than assuming.
Is cloud backup the same as disaster recovery?
No. Cloud backup puts copies of the data somewhere safe. Cloud disaster recovery adds the ability to start critical systems in that cloud, which is a different service with a different price.
Do I need disaster recovery for Microsoft 365?
The cloud platform stays up without you. Your data inside it is your responsibility against deletion, malicious action and retention limits, and third party backups for it are a separate purchase. In practice that data is mail plus whatever sits in SharePoint and OneDrive, which is worth knowing apart before you buy a backup for it.
What is a business impact analysis?
The exercise that produces the two objectives honestly, by asking each part of the business what an outage of a given length actually costs. Without it, the RPO and RTO come from a price list rather than from the business.
Who declares a disaster?
Whoever the plan names, and the plan should name a role with an out of hours contact path. Plans that leave this open lose their first hour to a discussion about whether this counts.
What is the most common failure in a recovery?
A dependency nobody listed. The data restore works and the application does not start, because it needed a service, a license server or a credential that was never in scope, and every minute of that adds to the RTO.
What should data backup and disaster recovery solutions include?
Backup and disaster recovery solutions should cover four things: automatic copies of servers, files and cloud data, at least one copy kept off site and out of reach of ransomware, regular restore tests, and a written recovery plan with target times. Data backup and disaster recovery sold without restore testing is only half a product.
Keep readingRelated concepts
Read next · Managed IT CapEx and OpEx in IT, and Why the Budget Line Shapes the Build The other side of the standby capacity question, since owning a second environment and renting one at failover are counted very differently. Open this next10 min- Backup · 13 min The 3-2-1 Backup Rule, and What Ransomware Did to It The rule that solves the copies half properly, and the places where following it still leaves a gap.
- Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work What stops the same access that encrypted production from reaching the backups, which is the assumption most plans quietly make.
- Network security · 9 min Cyber Security vs Network Security, and What the Firewall Does Not Cover Where this sits on the coverage map.
- Operations · 10 min Server Management, and the Routine Nobody Owns Until It Is Too Late Why a test restore is the only proof a backup works, and what else belongs on the same calendar.
- Managed IT · 10 min Google Workspace vs Microsoft 365, and What Actually Decides It What neither suite includes.
- Operations · 9 min MTTR, and Why Two Teams Quoting the Same Number Disagree The measurement that gets reported against that promise.