Disaster Recovery Overview (Get Cooking in Cloud)

Disaster Recovery Overview (Get Cooking in Cloud)

to Get Cooking in Cloud where we share the best recipes
to apply in your cloud kitchen. I am Priyanka Vergadia. And in this episode– ha– [SIGHS] Oh, my god. That was some
serious earthquake. Gosh, 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 PLAYING] A disaster typically means a
service-interrupting event. So what is disaster
recovery or DR? Well, it’s the amount
of impact a 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 SLAs
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. RPO, 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 HA
and DR 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
in 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. Ha, what else can I do? Well, I could also keep
going at a slow-mix option where I can’t really hear that
warning noise, in which case, I have to slow down. But the mixer’s 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
in 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’ll
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’m still making cakes
without stopping or pausing and is closest 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 bypass 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 and 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. [MUSIC PLAYING]

5 thoughts on “Disaster Recovery Overview (Get Cooking in Cloud)”

  1. Hmm the weight scale with GCP cost vs On-Prem cost. It looks like the GCP cost is "heavier" which is easily interpreted as "more", while visually the GCP cost is "lower", which I am sure is intended here. Due to this confusion, the use of a weight scale is probably not the best choice here.

Leave a Reply

Your email address will not be published. Required fields are marked *