Disaster Recovery as a Service


“Enabling Business Continuity by flipping a switch.”

During the time period preceding Y2K, many organizations realized the importance of having a ‘’backup plan’’. Most embarked on journeys to outline, articulate and invest in Business Continuity Plans. The Technically Inclined faculties, pursued research to uncover simpler, faster and better ways to enable BCP in the face of DISASTER.
So where are we today? How are we successfully securing our shared interests both internally and for our stakeholders?
Disaster Recovery Planning seems to be the answer. And with the rise of web socket technology enabling the internet of things, it seems that “Keeping the lights on” has become critical to most.
How do we keep the lights on, continue to grow our business and modernize our existing infrastructure?
We say, by utilizing service providers and technologies that encompass As a Service Offerings. We say Disaster Recovery as a Service.
To understand and enable Disaster Recovery as a Service, let’s step back in time to what legacy techniques were used…

I have a “Server Room” with 10 Physical Servers and should there be a man-made or natural disruption I will relocate to a geographically separate site (>150KM) from my Production site.
The pros of this approach:
1. All my servers were backed up from Production and Restores were taken to the Failover / Disaster Recovery Site
2. There is no performance degradation as I got 10 Servers in my failover site
The cons of this approach:
1. Going to take some time to conduct those restores, based on the amount of data I have probably around 24hours
2. The initial purchasing of all 10 Servers would be costly.

At the present time with the ever evolving enhancements in technology, we have simplified solutions. We still have our 10 Physical Servers and should there be a man-made or natural disruption I will relocate my servers to the “Cloud”, via my DR as a Service enabling Technology.
The pros of this approach:
1. All my servers are replicated from Production to the cloud
2. There is no performance degradation as I got 10 Instances which are scaled exactly as my servers are.
3. It’s only going to take roughly 1 hour to get my servers up and running as my data to a Point in Time (also known as RTO – Recovery Time Objective & RPO – Recovery Point Objectives ) is replicated asynchrously.
4. The initial cost will vary based on what the BCP of the Organization is.
The cons of this approach:
1. You as an organization need to trust that the Service Provider is able to meet your RPO and RTO Objectives.
DR as a Service surely brings a diverse approach of protection, no longer do small to mid-sized companies not have a model to protect their core systems. Larger companies now have a means to balance the cost between Physical Failover for Physically Bound Systems against other Virtualized Systems which can be failed over to the cloud.

So what can I do with this Cloud Computing POWER?

I am now able to recover from disaster faster and more accurately. I am able to save valuable pennies for my small to mid-sized companies which I support. I am able to utilize the strengths of cloud computing without the hassle of tiresome admin. I am able to extend my network from inside to out with all the security necessary. I am able to upscale and downscale as my business grows and shrinks. I am able to rest assured that within a fixed period of time, my service provider will get my business back online.

I choose Disaster Recovery as a Service for my Business, I choose to remain online in whatever event. I choose that should my dedicated Annual “Server Room” clean-up go pear shaped – I’ll failover to the cloud. More importantly I choose to be a part of a trend which is going to drive business continuity UP and reduction in revenue streams DOWN.

Watch this space for an outlook on Modernization, and how we see the End of Server 2003 amongst other Sun-Setting Technologies….