Intelligent CIO Africa Issue 30 | Page 46

FEATURE: BUSINESS CONTINUITY //////////////////////////////////////////////////////////////////////// Corne du Preez, Technology Solutions Professional: Apps and Infra, Altron Karabina, looks at how organisations can implement an effective BCDR strategy. W hen 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 and we have backups. 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 or is just too much and this then never happens. There are some misconceptions when it comes to BCDR. Most organisations 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. Some of the key issues of BCDR in the pre-cloud era has been the workload if an organisation has two or more data centres, the lack of centralised 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 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 centre, extra hardware (including networking) and a lot of people investment to make sure that an organisation can recover from a disaster. The planning for a DR test could take months to plan. In some instances, these plans would To or not to 46 INTELLIGENTCIO Some more definitions… When taking to customers, most do not understand the terms RTO (Restore Time Objective) or RPO (Restore Point Objective). Let’s delve into this a bit more to really understand what they mean by RTO and RPO. According to Wikipedia, RTO is described as ‘the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. RPO, meanwhile, ‘measures the maximum time period in which recent data might have been permanently lost in the event of a major incident; it is not a direct measure of the quantity of such loss.’ For instance, if the BC BCDR www.intelligentcio.com