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