When speaking to customers, I always ask what their BCDR strategies are. Sometimes I get good information from customers around their understanding of BCDR, but in most cases it seems that customers have given up on BCDR. Some of the feedback is that it is too costly, we don’t need it – we have backups (most of the times it is to tape).

What is BCDR?

There are some misconceptions when it comes to BCDR. Most organizations use the term interchangeably, but we do need to break this down. To understand BCDR, we need to quickly define Business Continuity and Disaster Recovery. In the simplest terms, business continuity is the proactive components of BCDR. This has to do with the processes and procedures that organisations need to implement so that mission critical servers and applications can function after a disaster. Disaster recovery is more the reactive side of BCDR. Disaster recovery is invoked when an organisation needs to resume operations after a major incident or outage. The time frame here can range from hours to days.

BCDR in the pre-Cloud era

Before the advent of cloud services (Private or Public Cloud) most organisations had to spend a lot of money to make sure that their BCDR strategies were in place. This meant they there had to be a second data center, extra hardware (including networking) and a lot of people investment to make sure that an organization can recover from a disaster. The planning for a DR test could take months to plan. In some instances, these plans would be project managed to make sure that all mile stones are achieved. Typically, the DR test would happen over a weekend with an army of people to make sure it happens smoothly and of course a lot of testing to make sure the DR test is a success. Most organisations would only be able to do a test once or maybe twice a year. For some organisations this cost of doing BCDR was / is just too much and this then never happens. Some of the key issues of BCDR in the pre Cloud era has been the workload if an organization has 2 or more data centers, the lack of centralized management as most of the resources were maintained and managed separately, the multitude of management platforms – vCD, SCVMM or vRealize and the most troubling of them all – data mobility. The amount and effort needed to make sure that the data is available for the DR test can only be termed as “Organised Chaos”.

BCDR in the Cloud Era

With the advent of hyperscale cloud service providers like Microsoft now available in South Africa, most organisations are relooking and rethinking their BCDR strategies. The importance here is that organisations can do as many BCDR tests as needed, without the need and cost of an army of resources to make this happen. BCDR in the cloud has the following advantages;

  1. Protection of all major IT Systems – and doing so more affordable. This means that RTO’s can be achieved in minutes instead of hours or days. Cloud BCDR also eliminates the extra cost for data centers. Organisations can now tap into near infinite cloud resources to assist with their BCDR
  2. Unification of Data Management, Security and Protection – Continuity and compliance throughout the application lifecycle is now possible. With cloud services, it is now possible to secure data at rest and in transit. Add to the fact that Microsoft provides industry leading security and protection solutions at a very cost-effective price point
  3. Applications work in Disaster Recovery – Organisations can now fail over their applications or full on premises data centers with automated recovery plans in a matter of minutes, instead of days, weeks or months.
  4. Perform BCDR Tests at ANY time – With Cloud BCDR organisations can now test their continuity plans any time, whenever they need to without having to affect their user community.

By Corne du Preez, Technology Solutions Professional: Apps and Infra at Altron Karabina 

Article first appeared on Intelligent CIO AfricaAltron Karabina expert on the having an effective BCDR strategy

Latest Tweets From @DUOMarketing

  • Error: You currently have access to a subset of Twitter API v2 endpoints and limited v1.1 endpoints (e.g. media post, oauth) only. If you need access to this endpoint, you may need a different access level. You can learn more here: https://developer.twitter.com/en/portal/product

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.