The idea is this: Your worst fears realized, you've got sites down, maybe all of your locations and data centers, and the clock has stopped ticking.
Except that it doesn't.
Business and people's lives need to continue. I won't go down the long tawdry list of what can kill you in the digital cloud age. Suffice to say that every exec needs to understand business continuity from the myriad angles of its internal ops, clientele, assets, and employees.
The idea behind DRaaS is to provide either failover or rapid recovery services. The services, in turn, range from site and transactional restoration to full data center/ops center parachute-in takeover. As dependency on operations and data centers can be diffuse, so are the DRaaS offerings by different vendors, most of which fall into the ISP/MSP classes for their connectivity and facilities investments and service renderings.
In my region, a number of organizations are applying thoughtfulness to how DRaaS needs to work. It's not simple, rather, a virtualization of organizational computational mechanisms and assets on a scale that keeps an organization alive during IT disasters, be they hurricanes, nine feet of snow, terrorism, cyberattack, major circuit loss, partnership loss, or subterfuge.
Well done, it's practiced and slick—if somewhat expensive. It's by no means free, but pooled risk in DRaaS may be the difference between living, being sick for perhaps a very long time, and business/organizational death.
DRaaS examples include, in my locale, Bluelock and Expedient. Caveat: Expedient hosts our NOC. Bluelock provides and supports multi-tiered recovery services surrounding well-known names, like VMware, and IBM, as well as storage basics via Acronis. Along the same lines, Expedient does Hyper-V and VMware replication for N+1—and the transaction tracking is up to decided skill sets. This is only the tip of the iceberg, in terms of services and asset infrastructure for both.
There are also concepts like virtual CoLo (co-location) that take two completely different cloud services vendors and then link cloud-based, internal cloud-based, or hybrid assets together into a joined, cohesive system for massive failover, replication, or (hopefully) rapid recovery from outage events—or geographic nexus moves, on-demand.
There are numerous devil-in-the-details to consider, ranging from expense through compliance with regulatory and compliance needs, to how varying lifecycles and employee skills can deal with disaster recovery as principle, let alone actuate recovery once a disaster trigger has occurred.
One of the trainings that ham radio operators go through to understand emergency services is to learn chains of commands, communications principles, how to take and execute orders, and even sustain themselves through the cycles of emergencies. Disaster recovery is a similar proposition. It requires planning, vendor intimacies you never thought possible, and not a small amount of imagination and creativity. At the end of the day, perhaps your business and fellow employees have a job. It's because someone thought things through, did the budget, and rose to the occasion. Neither the number of disasters nor our reliance on working IT infrastructure is diminishing.