welcome to get cooking in cloud where we
shed best recipes to apply in your cloud
kitchen I am Priyanka Vergara and in
this episode oh my god that was some
serious earthquake wash disasters like
this can be pretty hard to deal with
when you have a huge online presence so
let's see the recipe to plan for a
disaster like that when things like this
this or this happen you need to make
sure the impact on your business is
minimal and for that you need a robust
disaster recovery plan
[Music]
a disaster typically means a service
interrupting event so what is disaster
recovery or dr well it's the amount of
impact of business can take during a
disaster we use two key metrics to
define the impact RTO or recovery time
objective which is the maximum amount of
time your application can be offline
this usually depends on SL A's you offer
to your customers an SLA is a promise
made by you as a service provider to
your customers about the availability of
your service and the ramifications of
failing to deliver the agreed-upon level
of service RP o or recovery point
objective is the maximum amount of time
during which the data might be lost
during an interruption typically smaller
RTO and RPO values mean that the
application must recover quickly from an
interruption how quickly a system can
recover after a disaster is defined by
high availability and disaster recovery
patterns also known as H a and D are
patterns let's consider this scenario
I'm making some cakes and cookies for a
party which requires a mixer I'm on my
first batch of cookies and the mixer
starts to make some weird noises the
manual says that the mixer will fail
with such a noise so I need to do
something to carry on with the party
preparations hmm what do I do now I can
call the mixer company to come fix it
which is obviously going to take time
and won't really work best given the
party is today or maybe I can try to fix
it myself
based on the instructions and the manual
well this will mean a small pause in my
preparation but hmm will bring me back
on track a little bit quicker than
waiting for the mixer repair guy ah what
else can I do well I could also keep
going at a slow mix option wait there
you know I can't really hear that
warning
in which case I have to slow down but
the mix are still working so I can
continue on and get it fixed later this
option would definitely have less impact
on my party preparations at least for
today so let's review our options and
the dr terminology now if we call the
mixer company for a fix we have to stop
making the cake till they turn up and
fix it it will be slow and
time-consuming but eventually we will be
back working so this scenario is closest
to what we could call a cold dr pattern
if we try and fix it ourselves it's a
bit faster than the cold pattern but
since we still need to pause making our
cake in order to fix the situation it is
still slower than normal so this
scenario is closest to what we would
call a warm dr pattern and the option
where we continue working at slow speed
and decide to fix later is the most
efficient as I am still making cakes
without stopping or pausing and as close
as to what we would call a hot dr
pattern well moral of the story we pick
a dr pattern that makes sense for the
business at hand in this case it was
really serious business of hosting a
party and look how amazing this cake
turned out if you use google cloud for
dr it can greatly reduce the costs that
are associated with achieving both RTO
and RPO values as compared to fulfilling
those requirements on premise for
example traditional dr planning requires
you to account for a number of
requirements including capacity security
network infrastructure support and
bandwidth google cloud has several
features that help i pass most of these
complicated factors and reduces the cost
of managing a dr solution global network
redundancy scalability security and
compliance are a few such factors keep
following the series for more on this
now let's see what are some of the best
practices for planning a dr strategy
that can apply to our business first and
foremost we want to define our RTO and
RPO values because they would indicate
an appropriate
DR pattern then we make sure that we
have a full end-to-end recovery plan
just backing up an archiving data won't
be enough make our tasks as specific as
possible so when the time comes to
execute the plan
it does not just say run the restore
script well from where what's the
command such information should be there
in the instructions implement control
measures monitor and send alerts when
something destructive happens like
spikes in traffic or deletion in data
prepare the software verify that you can
install the software from the source or
from a pre-configured image make sure
you have the appropriate licenses for
that deployment our continuous
deployment toolset is an integral part
of our application deployment make sure
it's available at the time of disaster
to recover the environment we should not
forget about security and compliance
configure security the same for dr and
production environments and last but
most important step make sure your dr
plan works maintain multiple paths for
data recovery and test it regularly
that's all for today on get cooking in
cloud whether you are struck by
lightning or an earthquake hopefully you
learned some tips to recover join us
next time because we will share the
recipe to implement dr in cloud for your
applications hosted on-premise if you
would like to see more such content
don't forget to Like and subscribe to
our Channel
you
[Applause]