SlideShare uma empresa Scribd logo
1 de 4
Baixar para ler offline
22/08/2016 Recuperação de Desastres
http://web.mit.edu/rhel­doc/4/RH­DOCS/rhel­isa­pt_br­4/s1­disaster­recovery.html 1/4
Red Hat Enterprise Linux 4: Introdução à Administração de Sistemas
Anterior Capítulo 8. Planejamento para Desastres Próxima
8.3. Recuperação de Desastres
Como um experimento rápido, na próxima vez em que você estiver no seu centro de dados,
olhe ao redor e imagine por um momento que este se foi. Não só os computadores, mas
imagine que o prédio todo não existe mais. Em seguida, imagine que seu trabalho é executar a
maior parte das tarefas que eram executadas no centro de dados da mesma forma, em outro
lugar, o mais rápido possível. O que você faria?
Ao pensar nisso, você tomou o pirmeiro passo da recuperação de desastres. A recuperação de
desastres é a habilidade de recuperar a sua empresa de um evento que impactou o
funcionamento do seu centro de dados o mais competente e rapidamente possível. O tipo de
desastre pode variar, mas o objetivo final é sempre o mesmo.
Os passos envolvidos na recuperação de desastres são diversos e abrangentes. Aqui está
uma visão geral do processo, juntamente a pontos­chave para ter em mente.
8.3.1. Criando, Testando e Implementando um Plano de
Recuperação de Desastres
Um local de backup é vital, mas é inútil sem um plano de recuperacão de desastres. Um plano
de recuperacão de desastres determina cada faceta do processo de recuperacão de desastres,
incluindo, mas não limitado a:
Quais eventos denotam possíveis desastres
Quais pessoas na empresa têm autorização para declarar um desastre e,
consequentemente, colocar o plano em ação
A sequência de eventos necessária para preparar o local de backup, uma vez declarado
o desastre
As funções e responsabilidades de todo o pessoal envolvido na execução do plano
Um inventário do hardware e software necessários para restaurar a produção
Um cronograma listando os membros da equipe que compoem o local de backup,
incluindo um cronograma de rotação para suportar a continuação das operações sem
estressar os membros da equipe
A sequência de eventos necessária para mover as operações do local de backup para o
centro de dados novo/restaurado
Os planos de recuperação de desastres frequentemente servem o propósito de juntar todos os
detalhes. Este nível de detalhe é vital porque, no caso de uma emergência, o plano pode ser a
única coisa que restou do seu centro de dados anterior (obviamente, além dos backups
externos) para ajudá­lo na reconstrução e restauração das operações.
Dica
 
Os planos de recuperação de desastres estarem prontamente disponíveis no
seu ambiente de trabalho, mas também é necessário ter cópias externas. Desta
maneira, um desastre que destrua seu ambiente de trabalho não atingirá todas
as cópias do plano de recuperação de desastres. Um bom lugar para guardar
esta cópia é o local de armazenamento dos backups externos. Se não for violar
22/08/2016 Recuperação de Desastres
http://web.mit.edu/rhel­doc/4/RH­DOCS/rhel­isa­pt_br­4/s1­disaster­recovery.html 2/4
as normas de segurança da sua empresa, as cópias também podem ser
guardadas nas casas de membros­chave da equipe, prontas para uso imediato.
Um documento importante como este merece seriedade (e possivelmente assistência
profissional para ser criado).
Uma vez criado este documento importante, o conhecimento nele contido deve ser
periodicamente testado. Testar um plano de recuperação de desastres significa percorrer os
passos do plano: ir ao local do backup e criar um centro de dados temporário, rodar aplicações
remotamente e retornar às operações normais após o fim do "desastre". A maioria dos testes
não tenta executar 100% das tarefas contidas no plano; ao invés disso, um sistema e uma
aplicação representativos são selecionadas e realocadas ao local do backup, colocadas em
produção por um período e retornadas à operação normal no fim do teste.
Nota
 
Apesar de ser uma frase batida, um plano de recuperação de desastres deve
ser um documento vivo; conforme o centro de dados sofre mudanças, o plano
deve ser atualizado para refletir estas alterações. De muitas maneiras, um
plano de recuperação de desastres desatualizado pode ser pior que não ter
plano algum, portanto se organize para executar revisões e atualizações
regulares (a cada três meses, por exemplo) no plano.
8.3.2. Locais de Backup: Frios, Mornos e Quentes
Um dos aspectos mais importantes da recuperação de um desastre é ter o local a partir do
qual a recuperação pode ser feita. Este local também é conhecido como um site de backup. No
caso de um desastre, um site de backup é onde seu centro de dados será recriado, e de onde
você estará operando durante o desastre.
Há três tipos diferentes de sites de backup:
Sites de backup frios
Sites de backup mornos
Sites de backup quentes
Obviamente, estes termos não fazem referência à temperatura do site de backup. Mas sim ao
esforço necessário para iniciar as operações no site de backup, caso ocorra um desastre.
Um site de backup frio é um pouco mais do que um espaço configurado apropriadamente num
prédio. Tudo o que é necessário para restaurar o serviço para seus usuários deve ser obtido e
entregue ao site antes de começar o processo de recuperação. Como você pode imaginar, a
demora na transformação de um site de backup frio numa operação completa pode ser
substancial.
Sites de backup frios são os mais baratos.
Um site de backup morno já é estocado com hardware parecido com o que você tem no seu
centro de dados. Para recuperar o serviço, os últimos backups do seu local de armazenamento
externo devem ser entregues e uma restauração do zero deve ser completa, antes de
realmente iniciar a recuperação.
22/08/2016 Recuperação de Desastres
http://web.mit.edu/rhel­doc/4/RH­DOCS/rhel­isa­pt_br­4/s1­disaster­recovery.html 3/4
Sites de backup quentes tem uma imagem espelho virtual de seu centro de dados atual, com
todos os sistemas configurados e aguardando somente os últimos backups dos dados de seus
usuários vindos do local de armazenamento externo. Como você pode imaginar, um site de
backup quente pode ser transformado num local de produção completo em apenas algumas
horas.
Um site de backup quente é a tática mais cara de recuperação de desastres.
Os sites de backup podem ter três origens diferentes:
Empresas especializadas em oferecer serviços de recuperação de desastres
Outros locais de propriedade de sua empresa e operados pela mesma
Um acordo com uma outra empresa para compartilhar as instalações do centro de dados
no caso de um desastre
Cada tática tem seus pontos fortes e fracos. Por exemplo: contratar uma empresa de
recuperação de desastres frequentemente lhe dá acesso a profissionais qualificados para
direcionar as empresas através do processo de criação, testes e implementação de um plano
de recuperação de desastres. Como você pode imaginar, estes serviços não são de graça.
Usar um espaço em outra localidade de propriedade e operada pela sua empresa pode ser
uma opção com custo zero, mas estocar o site de backup e manter sua prontidão ainda é uma
opção cara.
Desenvolver um acordo para compartilhar centros de dados com uma outra empresa pode ser
bem barato, mas geralmente não é possível tocar operações a longo prazo sob estes termos,
já que o proprietário do centro de dados ainda deve manter sua produção normal.
No final das contas, a escolha do site de backup é um balanço entre os custos e a necessidade
de sua empresa na produção contínua.
8.3.3. Disponibilidade de Hardware e Software
Seu plano de recuperação de desastres deve incluir métodos para obter o hardware e software
necessários para as operações do site de backup. Um site de backup gerido profissionalmente
talvez já tenha tudo o que você precisa (ou talvez você precise providenciar a obtenção e
entrega de materiais especiais que o site não tenha). Por outro lado, um site de backup frio
implica na identificação de uma fonte confiável para a obtenção de cada um dos itens.
Frequentemente, empresas trabalham com fabricantes para criar acordos para a rápida
entrega de hardware e/ou software no caso de um desastre.
8.3.4. Disponibilidade de Backups
Quando um desastre é declarado, é necessário notificar o seu local de armazenamento
externo por duas razões:
Para levar os últimos backups ao site de backup
Para organizar a retirada e entrega dos backups ao site de backup (como suporte aos
backups normais do site de backup)
Dica
 
No caso de um desastre, os últimos backups de seu antigo centro de dados que
você tiver são vitalmente importantes. Considere fazer cópias antes de mais
22/08/2016 Recuperação de Desastres
http://web.mit.edu/rhel­doc/4/RH­DOCS/rhel­isa­pt_br­4/s1­disaster­recovery.html 4/4
nada, e retirar os originais novamente da empresa o quanto antes.
8.3.5. Conectividade de Rede ao Site de Backup
Um centro de dados não tem muita utilidade se estiver totalmente desconectado do que resto
da empresa. Dependendo do plano de recuperação de desastres e da natureza do desastre,
sua comunidade de usuários pode estar localizada há quilômetros de distância do site de
backup. Nestes casos, uma boa conectividade é essencial para restaurar a produção.
Um outro tipo de conectividade para ter em mente é a telefônica. Você deve assegurar que há
linhas telefônicas disponíveis suficientes para suportar toda a comunicação verbal com seus
usuários. O que pode ter sido um simples grito por cima de uma divisória pode ser agora uma
conversa telefônica de longa distância. Portanto, planeje mais conectividade telefônica do que
pareça necessário numa primeira instância.
8.3.6. Funcionários do Site de Backup
A questão dos funcionários do site de backup tem diversas dimensões. Um dos aspectos é
determinar os funcionários necessários para rodar o centro de dados backup pelo tempo
necessário. Apesar de um número pequeno de funcionários poder manter as coisas
funcionando por um curto período, conforme o desastre se desenrolar, serão necessárias mais
pessoas para tocar as operações sob as circunstâncias extraordinárias que permeam um
desastre.
Isto inclui garantir que os funcionários tenham tempo livre suficiente para descansar e voltar
para seus lares. Se as consequências do desastre foram abrangentes de modo que afetaram
os lares e famílias das pessoas, é necessário alocar tempo para que elas possam lidar com
suas recuperações particulares do desastre. Também é necessária acomodação próxima ao
site de backup, assim como transporte para trazer as pessoas para o site de backup e levá­las
de volta.
Frequentemente, um plano de recuperação de desastres inclui representantes de todas as
partes da comunidade de usuários da empresa. Isto depende da habilidade da sua empresa
em operar com um centro de dados remoto. Se os representantes dos usuários devem
trabalhar no site de backup, também é necessário prover­lhes acomodação.
8.3.7. Voltando à Normalidade
Eventualmente, todos os desastres terminam. O plano de recuperação de desastres também
deve abordar esta fase. O novo centro de dados deve estar equipado com todo o hardware e
software necessário. Apesar desta fase não ter a mesma natureza crítica de tempo dos
preparativos quando o desastre foi declarado, os sites de backup custam dinheiro todos os
dias em que estão em uso. Portanto, devido às questões econômicas, devemos retornar à
normalidade o mais rápido possível.
Deve­se fazer os últimos backups do site de backup e enviá­los ao novo centro de dados. Após
serem restaurados no novo hardware, a produção pode ser iniciada no novo centro de dados.
Neste ponto, o centro de dados backup pode ser descomissionado, com a disposição de todo o
hardware temporário determinada pela seção final do plano. Finalmente, deve ser feita uma
revisão da eficácia do plano e integrar as alterações recomendadas pelo comitê revisor numa
versão atualizada do plano.
Anterior Principal Próxima
Backups Acima Informações Específicas do
Red Hat Enterprise Linux

Mais conteúdo relacionado

Destaque (12)

Netwerken for Young Professionals
Netwerken for Young ProfessionalsNetwerken for Young Professionals
Netwerken for Young Professionals
 
Comtes1
Comtes1Comtes1
Comtes1
 
Sky roamers 2by1ad
Sky roamers 2by1adSky roamers 2by1ad
Sky roamers 2by1ad
 
C02ex01, sign
C02ex01, signC02ex01, sign
C02ex01, sign
 
Patinaje en el hielo
Patinaje   en   el     hieloPatinaje   en   el     hielo
Patinaje en el hielo
 
La implementació de la llei del tabac en temps de crisi en l'àmbit de la salu...
La implementació de la llei del tabac en temps de crisi en l'àmbit de la salu...La implementació de la llei del tabac en temps de crisi en l'àmbit de la salu...
La implementació de la llei del tabac en temps de crisi en l'àmbit de la salu...
 
Feeliiz cuumplee
Feeliiz cuumpleeFeeliiz cuumplee
Feeliiz cuumplee
 
Giraldo
GiraldoGiraldo
Giraldo
 
Maestria
MaestriaMaestria
Maestria
 
Electricidad
ElectricidadElectricidad
Electricidad
 
percepcion e impresion
percepcion e impresionpercepcion e impresion
percepcion e impresion
 
MozTW 軟體自由日 2015
MozTW 軟體自由日 2015MozTW 軟體自由日 2015
MozTW 軟體自由日 2015
 

Semelhante a Recuperação de desastres em centros de dados

A24 paper - perfil business intelligence - o momento de sair da rotina por ...
A24   paper - perfil business intelligence - o momento de sair da rotina por ...A24   paper - perfil business intelligence - o momento de sair da rotina por ...
A24 paper - perfil business intelligence - o momento de sair da rotina por ...BIBrasil
 
A24 paper - perfil business intelligence - o momento de sair da rotina por ...
A24   paper - perfil business intelligence - o momento de sair da rotina por ...A24   paper - perfil business intelligence - o momento de sair da rotina por ...
A24 paper - perfil business intelligence - o momento de sair da rotina por ...Marcelo Krug
 
Tecnologia front end back-end
Tecnologia front end back-end Tecnologia front end back-end
Tecnologia front end back-end Andressa Silveira
 
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...Gleicon Moraes
 
os desafios de escalar SCRUM
os desafios de escalar SCRUMos desafios de escalar SCRUM
os desafios de escalar SCRUMDanilo Bardusco
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Taller Negócio Digitais
 
Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Jose Silva
 
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...Gleicon Moraes
 
Curso de Performance and Tuning - Linux
Curso de Performance and Tuning - LinuxCurso de Performance and Tuning - Linux
Curso de Performance and Tuning - LinuxDell Technologies
 
Desenvolvendo aplicações Web escaláveis
Desenvolvendo aplicações Web escaláveisDesenvolvendo aplicações Web escaláveis
Desenvolvendo aplicações Web escaláveiselliando dias
 
Merda Acontece
Merda AconteceMerda Acontece
Merda AconteceLuiz Borba
 
Technology Radar_ThoughtWorks_Vol_22
Technology Radar_ThoughtWorks_Vol_22Technology Radar_ThoughtWorks_Vol_22
Technology Radar_ThoughtWorks_Vol_22Hudson Augusto
 
curso-228532-aula-10-20e2-completo 1..pdf
curso-228532-aula-10-20e2-completo  1..pdfcurso-228532-aula-10-20e2-completo  1..pdf
curso-228532-aula-10-20e2-completo 1..pdfkassiocarlos
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azuretdc-globalcode
 
Infraestrutura como código Terraform aws openshift Ansible
Infraestrutura como código Terraform aws openshift AnsibleInfraestrutura como código Terraform aws openshift Ansible
Infraestrutura como código Terraform aws openshift AnsibleClaudemir de Almeida Rosa
 

Semelhante a Recuperação de desastres em centros de dados (20)

A24 paper - perfil business intelligence - o momento de sair da rotina por ...
A24   paper - perfil business intelligence - o momento de sair da rotina por ...A24   paper - perfil business intelligence - o momento de sair da rotina por ...
A24 paper - perfil business intelligence - o momento de sair da rotina por ...
 
A24 paper - perfil business intelligence - o momento de sair da rotina por ...
A24   paper - perfil business intelligence - o momento de sair da rotina por ...A24   paper - perfil business intelligence - o momento de sair da rotina por ...
A24 paper - perfil business intelligence - o momento de sair da rotina por ...
 
Tecnologia front end back-end
Tecnologia front end back-end Tecnologia front end back-end
Tecnologia front end back-end
 
Palestra microservice semanatic
Palestra microservice semanaticPalestra microservice semanatic
Palestra microservice semanatic
 
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...DNAD 2015  - Como a arquitetura emergente de sua aplicação pode jogar contra ...
DNAD 2015 - Como a arquitetura emergente de sua aplicação pode jogar contra ...
 
Apostila sobre sistema operativo
Apostila sobre   sistema operativoApostila sobre   sistema operativo
Apostila sobre sistema operativo
 
Apostila sobre sistema operativo
Apostila sobre   sistema operativoApostila sobre   sistema operativo
Apostila sobre sistema operativo
 
os desafios de escalar SCRUM
os desafios de escalar SCRUMos desafios de escalar SCRUM
os desafios de escalar SCRUM
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
 
the-hard-road.PDF
the-hard-road.PDFthe-hard-road.PDF
the-hard-road.PDF
 
Debugging node
Debugging nodeDebugging node
Debugging node
 
Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)Sistema Operacional de Tempo Real (vx works)
Sistema Operacional de Tempo Real (vx works)
 
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...
QCon SP 2015 - Advogados do diabo: como a arquitetura emergente de sua aplica...
 
Curso de Performance and Tuning - Linux
Curso de Performance and Tuning - LinuxCurso de Performance and Tuning - Linux
Curso de Performance and Tuning - Linux
 
Desenvolvendo aplicações Web escaláveis
Desenvolvendo aplicações Web escaláveisDesenvolvendo aplicações Web escaláveis
Desenvolvendo aplicações Web escaláveis
 
Merda Acontece
Merda AconteceMerda Acontece
Merda Acontece
 
Technology Radar_ThoughtWorks_Vol_22
Technology Radar_ThoughtWorks_Vol_22Technology Radar_ThoughtWorks_Vol_22
Technology Radar_ThoughtWorks_Vol_22
 
curso-228532-aula-10-20e2-completo 1..pdf
curso-228532-aula-10-20e2-completo  1..pdfcurso-228532-aula-10-20e2-completo  1..pdf
curso-228532-aula-10-20e2-completo 1..pdf
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
 
Infraestrutura como código Terraform aws openshift Ansible
Infraestrutura como código Terraform aws openshift AnsibleInfraestrutura como código Terraform aws openshift Ansible
Infraestrutura como código Terraform aws openshift Ansible
 

Recuperação de desastres em centros de dados