The DRaaS Option

When natural, circumstantial, or man-made disasters strike, large corporations with considerable financial, physical, and human resources clearly have the edge over their smaller rivals when it comes to maintaining services, preserving application and network availability to subscribers and in-house users, and preserving the integrity of their systems and data.

 

But there’s an option available which levels the playing field to a considerable degree, extending these capabilities to small and medium-sized enterprises. It’s called DRaaS.

What Is DRaaS?

Severe weather conditions and natural calamities such as flooding and earthquakes are just one part of a spectrum of disasters including utilities outages, hardware failures, software glitches, and security breaches. Any and all of these can take out a network, corrupt or compromise essential data, and render applications and services unavailable to users and customers.

 

For smaller scale enterprises, disaster recovery or DR provisions have traditionally centered on file backups, and the storage of backup media off-site. Some larger corporations might allow for a “hot site”, or remote office which can be called upon to house workers with a limited data center infrastructure at short notice. Hardly fool-proof measures, and all too slow to get going in a business environment that demands real-time access to resources and data.

 

Disaster Recovery as a Service or DRaaS is a cloud-based option that enables organizations to establish alternate processing sites through the physical or virtual servers hosted by a third-party service provider.

The Mechanics

Virtualization techniques allow companies to set up servers as software instances running on disparate hardware, to the extent that each instance appears and acts like any other server as far as the network and its users are concerned. These virtual servers may be backed up in the same way as “hardware-based” data.

 

The backup of virtual servers to the cloud under DRaaS shifts data to a hosted infrastructure of shared data centers that’s capable of restoring client servers and also initializing and operating them at very short notice. DRaaS clients can configure their accounts to continually back up the most recent instances of their virtual servers and switch them on if the primary servers at their physical sites should fail.

 

Some DRaaS providers offer the ability to provide virtual machine (VM) replication based on server images, so that systems may be recovered by the booting up of hosts based on images sent from a client’s primary site. More advanced solutions offer agentless operations, with no software having to be present on individual virtual machines.

The As A Service Pricing Model

Service Level Agreements (SLAs) for a DRaaS deployment are typically constructed on a pay-per-use basis, or as an explicitly defined contract. In both cases, a third-party vendor/service provider agrees to provide failover (transfer of resources in the event of failure) to a cloud-based environment.

 

Some vendors offer all-in-one solutions, while others may segment their offerings in terms of DR options like the cloud resurrection of individual servers or a complete data center, or component-based backups (e.g. MS Exchange or SQL Server).

The Basic Package

Whatever other options may be on the table, a DRaaS solution should at the very least include the following:

 

· Facilities for backing up critical systems and data automatically

 

· Fast recovery from a disaster, with minimal user (client) interaction involved

 

· A range of recovery options, from the restoration of a single application to an entire infrastructure

 

· A transparent and easy to understand billing structure

 

· The ability to set Backup Target Options (BTO) for recovery

On The Plus Side…

Disaster Recovery as a Service allows organizations to avoid business disruptions and downtime without the high costs usually associated with provisioning and maintaining “hot sites”. Pay-as-you use options bring DRaaS well within the budgetary range of small and medium-sized businesses.

 

Cloud-based hosting ensures that the services are easy to implement, with the overhead associated with provisioning, configuring, and testing a disaster recovery plan removed from the organization and transferred to the service provider.

 

And since data doesn’t have to be physically restored on site or over the internet, an organization’s time to return applications and services to active production is greatly reduced.

However…

There may be some concerns about entrusting your organization’s recovery to a third party, who effectively has control over implementing your recovery plan in the event of a disaster, and meeting your objectives for recovery times and recovery points.

 

In some cases, there may also be performance declines for applications running in the cloud, or migration issues when restoring a client’s applications from the cloud to their data center.

Choosing A Service

Here’s a checklist of some of the factors to consider when choosing a DRaaS provider:

 

Backup Options and Capabilities

· Are all of your business-critical applications and platforms covered?

 

· Are local and cloud-based backups created?

 

· How often is data backed up or synchronized?

 

· What operating systems, databases, applications, and platforms are supported?

Recovery Options

· How long does it take to recover data, applications, or servers?

 

· How easy is it to move from a backup to a live state?

Temporary Recovery Environment (Failure-State)

· When applications are moved to the cloud during an incident, what performance levels can you expect?

 

· What’s the maximum number of virtual machines (VMs) supported?

 

· What guarantees does the host give regarding availability?

Failback (When your on-site capabilities return to normal)

· Any time limits on how long the provider will host a recovery environment?

 

· Any additional charges associated with long-term hosting?

 

· What conditions and techniques apply to restoration or failback?

 

· How much (if any) downtime is associated with the failback process?