Disaster Recovery as a Service: What It Covers and Doesn't
DRaaS replicates your systems and runs failover when your primary site goes down. What it covers, what is on you, & how it differs from backups.
Published October 21, 2026 by Danish Rumane
6 Minutes to Read

A vendor has quoted you for disaster recovery as a service, or someone on the board has asked whether you have it. Before comparing prices, be clear on what you would be buying. DRaaS keeps a copy of your systems ready in a second location and moves you onto it when the first location fails. It does not protect you from every kind of bad day, and most of the disappointment with DRaaS comes from those gaps.
This article explains how DRaaS works, the three ways it is sold, what it covers, what it leaves with you, and how it relates to backups. If the terms are new, our glossary entries on disaster recovery and backup are a quick primer.
How disaster recovery as a service works
DRaaS is disaster recovery delivered by a third party. The provider keeps a recovery environment on its infrastructure and moves your workloads there when your primary environment fails. It runs in three stages.
Replication. Your servers, or the data on them, are copied to the provider's environment, either on a schedule or continuously.
Failover. When the primary site fails, the replicated workloads are started in the recovery environment and traffic is redirected to them.
Failback. Once the primary site is repaired, workloads and any data written during the outage move back.
Two numbers define what "recovered" means:
- Recovery point objective (RPO): how much data you can afford to lose, measured in time. An RPO of one hour means the recovery copy can be no more than an hour old.
- Recovery time objective (RTO): how long you can be down before the impact on the business is unacceptable.
A well-written DRaaS contract states both for each workload, rather than one number for everything.

RPO defines your acceptable data-loss window; RTO defines your target time to restore service.
Managed, assisted and self-service DRaaS
The label covers three different arrangements, and the split of work changes a lot between them.
Managed DRaaS. The provider runs recovery end to end. You declare the disaster, and the provider executes the runbook, starts the workloads and redirects traffic.
Assisted DRaaS. The provider supplies the platform and the expertise, and your team carries out some or all of the recovery plan with its help.
Self-service DRaaS. The provider supplies replication software and recovery capacity. Planning, testing and running the failover are your job. It is usually the cheapest model, and the one most likely to fail on the day if nobody has rehearsed it.
When two quotes look far apart, check which model each one is before comparing anything else.

Managed, assisted and self-service DRaaS divide planning, testing and recovery duties differently.
If you are still working out which parts of recovery you want to hand off, our managed services page lists what InMotion Cloud engineers already run on every plan.
What DRaaS covers
A well-scoped DRaaS service typically includes:
- Replication of the servers or data you name, at the frequency the contract sets
- Recovery capacity at a second location, either reserved or allocated when needed
- Failover orchestration, the tooling and runbook that start workloads in the right order
- Network redirection, through DNS changes, IP re-routing or a VPN into the recovery site
- Failover testing, with frequency and cost set in the contract
That list is narrower than it looks. Everything on it deals with infrastructure becoming unavailable.
What DRaaS doesn't cover
Data that was already wrong. Replication copies whatever is on the primary. If ransomware encrypts your database or a script drops a table, that change can reach the replica within minutes. Getting back to a clean state needs point-in-time copies kept long enough to predate the problem.
Application consistency. Replicating a database server and an application server separately does not guarantee they come back agreeing with each other. That has to be designed and tested.
Dependencies outside the replicated set. Identity providers, DNS, licence servers, third-party APIs and payment gateways all need to work from the recovery site. Leave them out of the plan and failover can finish with the application still down.
The decision to fail over. In every model, someone on your side decides when an outage has become a disaster. Failing over too early can cost more than waiting.
Software-as-a-service data. Email, CRM and file-sharing platforms you subscribe to usually sit outside infrastructure DRaaS.
The rest of business continuity. Who talks to customers, how staff work if the office is closed, and which processes run by hand all belong in your continuity plan. A DRaaS contract covers none of them.
DRaaS vs backups: you usually need both
The two answer different questions. DRaaS answers "how fast can we be running somewhere else?" Backups answer "can we get back to how things were last Tuesday?"
- Server or whole site lost: DRaaS gets you running quickly. Backups get you running too, more slowly, because something has to be rebuilt and restored.
- Data corrupted or encrypted: DRaaS may already have replicated the damage. Backups with enough retention take you to a clean copy.
- One folder deleted by mistake: DRaaS is the wrong tool. A backup restores just that folder.
Our article on why continuity depends on your last restore covers backup testing. Our guide to volume snapshots and backups explains a related distinction that trips teams up on OpenStack.

DRaaS gets workloads running elsewhere; backups restore earlier data when corruption or deletion is the problem.
Questions to ask before you sign
What RPO and RTO do you commit to for each workload, and what happens if you miss them? A single figure for the whole estate is a sales number.
Who declares a disaster, and how? Know the phone number, the authority and the hours.
How often is failover tested, who runs the test, and is it charged separately?
How does failback work, and how long does it take? Failback is often slower and less rehearsed than failover.
Is recovery capacity reserved, or allocated when needed? During a regional outage, on-demand capacity is what every other customer wants as well.
What does replication cost each month when nothing is wrong? Storage and data transfer for the replica are paid every month, not just on the day.
What happens to our IP addresses and DNS on failover? This is where many first tests fail.
Summary
DRaaS keeps a second copy of your infrastructure ready and moves you onto it when the first one fails. It covers replication, recovery capacity and failover. It does not fix data that was already damaged, does not decide when to fail over, and does not replace backups or a continuity plan. Set recovery objectives per workload first, then judge any offer against them.
Not sure whether you need DRaaS or better backups?
InMotion Cloud engineers will review your recovery setup and tell you plainly what our platform covers and where you need something else.
Frequently asked questions
What is disaster recovery as a service? A service where a third party replicates your systems to its infrastructure and runs, or supports, failover when your primary environment fails.
What is the difference between DRaaS and backup as a service? DRaaS aims to get you running elsewhere quickly. Backup as a service keeps point-in-time copies you restore from, usually more slowly but further back in time.
Does DRaaS protect against ransomware? Partly. It gives you somewhere to run, but replication can copy encrypted data across. You still need backups with retention that predates the attack.
What are RTO and RPO? RPO is how much data you can lose, measured in time. RTO is how long you can be down.
Is self-service DRaaS cheaper? Usually, because your team does the planning, testing and failover. The saving only holds if the team actually rehearses.
Does InMotion Cloud offer DRaaS? Not as a service with contracted recovery objectives. InMotion Cloud provides managed backups, restores, snapshots and load balancing, and our engineers can help you plan recovery around them.
Danish Rumane writes about hosting and cloud technology with a focus on what it means for businesses. His perspective draws on more than a decade in marketing, building brands and creating content across industries.
Keep reading
- Your Continuity Plan Is Only as Good as Your Last RestoreCan your backups actually restore your systems? Learn why restore testing, independent storage and retention matter for business continuity.Read
- What High Availability Options Are Available with InMotion Cloud?Downtime costs money. For e-commerce sites, a single hour of outage can mean thousands in lost revenue.Read
Let’s map your infrastructure to the right plan
A free 30-minute call with our cloud team. We review your current environment and show you exactly what a move to InMotion Cloud would look like: timeline, architecture, and cost.