Designing a Disaster Recovery Plan

Loading...

Do curso por Google

System Administration and IT Infrastructure Services

1874 classificações

Google

System Administration and IT Infrastructure Services

1874 classificações

Curso 4 de 5 em Specialization Google IT Support Professional Certificate

This course will transition you from working on a single computer to an entire fleet. Systems administration is the field of IT that’s responsible for maintaining reliable computers systems in a multi-user environment. In this course, you’ll learn about the infrastructure services that keep all organizations, big and small, up and running. We’ll deep dive on cloud so that you’ll understand everything from typical cloud infrastructure setups to how to manage cloud resources. You'll also learn how to manage and configure servers and how to use industry tools to manage computers, user information, and user productivity. Finally, you’ll learn how to recover your organization’s IT infrastructure in the event of a disaster. By the end of this course you’ll be able to: ● utilize best practices for choosing hardware, vendors, and services for your organization. ● understand how the most common infrastructure services that keep an organization running work, and how to manage infrastructure servers. ● understand how to make the most of the cloud for your organization. ● manage an organization’s computers and users using the directory services, Active Directory, and OpenLDAP. ● choose and manage the tools that your organization will use. ● backup your organization’s data and know how to recover your IT infrastructure in the case of a disaster. ● utilize systems administration knowledge to plan and improve processes for IT environments.

Na lição

Data Recovery & Backups

In the fifth week of this course, we'll learn about data recovery and backups. In any tech role, it's important to know how to backup and recover data -- it's even more important for system administration. We will also learn about common corporate practices like designing a disaster recovery plan and writing post-mortem documentation. By the end of this module, you'll know the tradeoffs between on-site and off-site backups, understand the value and importance of backup and recovery testing, know different options for data backup (as well as the risks) and understand the purpose and contents of a disaster recovery plan.

What's a Disaster Recovery Plan?5:02

Designing a Disaster Recovery Plan6:13

Conheça os instrutores

Google

So, what exactly goes into an effective disaster recovery plan?

Well, it depends. Keep in mind,

there's no one-size-fits-all for disaster recovery plans.

The mechanisms chosen and procedures put in place will

depend a lot on the specifics of your organization and environment.

But we can't start by covering the three types of measures in more detail.

We'll also go over some examples to help give you an idea of what to think about.

A good way to understand what to plan for is to perform a risk assessment.

This involves taking a long hard look at

the operations and characteristics of your teams.

A risk assessment allows you to prioritize certain aspects of

the organizations that are more at risk if there's an unforeseen event.

Risk assessment can involve brainstorming hypothetical scenarios and analyzing

these events to understand how they'd impact your organization and operations.

When you look into preventive measures,

pay attention to systems that lack redundancy.

If it's something critical to permit operations,

they should probably have a redundant spare, just in case.

Make sure you have a sound backup and a recovery system,

along with a good strategy in place.

Ideally, you should have

regular but automated backups to backup systems located both on site and off site.

It's also critical that you have

data recovery procedures clearly documented and kept up-to-date.

Data recovery following a disaster is hopefully something you will rarely do.

It's important to make sure that these procedures are

updated since systems change and evolve throughout their lifetime.

Redundancies shouldn't be limited only to systems.

Anything critical to operations should be made redundant whenever possible.

This includes power delivery or supply,

communications systems, data links, and hardware.

Think through the impacts that a disaster affecting

each of these aspects would have on your day-to-day operations.

What would happen to your network if the building lost power?

Can you use continue to work at

the fiber-optic data line if the building gets damaged by a nearby construction work?

You call router for the office just burst into flames.

Okay. The last one is a little far-fetched,

but I think you get where I'm going.

Another super important preventive measure that should be

evaluated and verified is operational documentation.

Make sure that every important operational procedure is documented and accessible.

This includes things like setting up and configuring critical systems and infrastructure.

Any steps or specific configuration details that are needed to restore

100 percent functionality to core systems and services should be documented in detail.

It's also important that this documentation is kept up-to-date.

An effective way to do this is periodically

verify that the steps documented actually work.

You don't want to find yourself in a situation where

you need to reconfigure assistant following incident,

only to discover that the documentation is wrong.

When looking at detection measures,

you'll want to make sure you have a comprehensive system in place that can quickly

detect and alert you to service outages or abnormal environmental conditions.

If up-time and availability is important for your organization,

you'll likely have two internet connections;

a primary and a secondary.

You want to monitor the connection status of both of these links.

Ideally, they should be configured to automatically fail over if one goes down.

But you'll still want to be alerted when this happens,

so you can investigate why the link went

down and work on getting it back as soon as possible.

The way to think about designing detection measures is to evaluate

what's most critical to the day-to-day functioning of the organization.

What infrastructure services and access are absolutely vital?

Those are the ones you should be closely monitoring.

And it's not just outages or complete failures you should be watching for.

Of course, you want to monitor for those,

but you also want to monitor for

conditions that indicate that a problem is likely to occur.

If we can avoid a catastrophic failure by

being alerted to an overheating server before it fails,

that would be much better, wouldn't it?

So, you want to monitor conditions of service and infrastructure equipment.

Things like temperatures, CPU load and network load for

a service monitoring for error rates and requests per

second will give you insight into the performance of the system.

You should investigate any unusual spikes or unexpected increases.

These early warning systems allow you to head off

disaster before it brings operations to a halt.

And of course, you absolutely must test these systems.

Simulate the conditions your monitoring systems are designed to catch.

Make sure the detection thresholds actually fire the alerts like they're supposed to.

This testing goes beyond just the monitoring systems too.

You'll also want to test your reactions and responses to these alerts.

If you're monitoring systems reliably trigger alerts but everyone just ignores them,

they aren't super useful, are they?

You want to conduct regular disaster test to make sure systems are

functioning and that your procedures to handle them are also up to the task.

Corrective or recovery measures include actions that are taken to restore

normal operations and to recover from an incident or outage.

This includes taps like restoring a corrupted database from

a backup or rebuilding and re-configuring a server.

Your disaster plan should include reference or

links to documentation for these types of tasks.

Anything and everything that would be required to

restore normal operations following some disaster.

This is where the steps for restoring various systems and data from backups should be.

The disaster recovery doc doesn't need to contain the details of the operations.

Links and references are sufficient.

But it's important to be prepared for a situation where

typical documentation acts methods are unavailable.

Let's imagine you keep all your operational documentation

in a wiki on a dedicated server.

What happens when that server suffers an outage?

It's important that critical documentation is accessible

if an emergency scenario or disaster strikes.

In the next lesson, we'll cover what to do after a failure. See you there.

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play