Implementar uma soluo de

Recuperao de Desastre Disaster

Recovery depende de trs fatores:
Tempo
Recursos
Dinheiro
Muitas organizaes no pensam em Recuperao de Desastre
quando a infraestrutura de TI e os aplicativos esto sendo
executados sem quaisquer problemas. A maioria delas s pensa
sobre isto quando algo ocorre, causando um grande impacto
negativo sobre o negcio.
Se voc um administrador de sistema ou algum responsvel por
manter o funcionamento da TI, voc deve estar constantemente
trabalhando na recuperao de desastres. Se sua empresa aloca
tempo e oramento ou no, voc ainda pode trabalhar em alguns
aspectos da Recuperao de Desastre.
A seguir est uma lista de vrios itens que voc pode considerar ao
planejar uma Recuperao de Desastre. Esta lista no deve ser
considerada defi nitiva, mas sufi ciente para dar idias sobre como
comear um plano de Recuperao de Desastre.
Novo datacenter principal: Antes de planejar um datacenter
secundrio (remoto), voc deve certifi car se todos os componentes
em seu datacenter primrio so altamente redundante. Seu foco
deve ser em projetar um datacenter primrio to resistente quanto
possvel, que voc consiga se recuperar rapidamente da maioria
dos desastres (exceto desastres naturais) sem ter que usar sempre
o datacenter secundrio. Por exemplo, ter um banco de dados
standby no mesmo datacenter do seu banco de dados de produo,
confi gurar placas de rede e placas HBA dupla em todos os
servidores de produo, confi gurar servidores de web mltiplos
com balanceamento de carga, conectar o servidor em dois circuitos
de energia usando fontes redundantes, etc;
Datacenter secundrio (remoto): Se voc implementar um novo
datacenter primrio, o objetivo de um datacenter remoto
principalmente para as catstrofes naturais como terremotos,
incndios, inundaes, etc. Embora isso possa ser muito bvio,
vale dizer, j que eu j vi algumas empresas fazerem isso, que tem
tanto datacenter primrio quanto o secundrio na mesma cidade, o
que compromete o propsito da Recuperao de Desastre;
Replicar componentes de produo no datacenter
secundrio: Voc no precisa replicar todo o hardware e

aplicativos de datacenter primrio para o secundrio. Um

administrador de sistemas, tcnicos ou qualquer pessoa pode
rapidamente identifi car todo o hardware e software crtico que
precisa ser replicado no site remoto, mas voc pode precisar de
ajuda de outros departamentos para identifi car as aplicaes que
so crticas para o negcio. Voc tem de mapear as funes crticas
de negcios em funo dos componentes da infraestrutura de TI, se
certifi cando que realmente todos os componentes de infraestrutura
juntamento com a aplicao e os dados foram replicados para o
site remoto;
Plano de armazenamento Storage: Se voc tiver algum tipo
de storage SAN (ou storage NAS) que suporta a aplicao crtica no
datacenter primrio, voc precisa ter um soluo similar em seu
site remoto tambm. Por motivos de desempenho, os servidores no
datacenter remoto devem ter as mesmas caractersticas dos
servidores de produo do datacenter primrio. No entanto, para o
storage, se voc tiver um storage SAN high-end de um grande
fornecedor no site principal, pode-se considerar o uso de
um storage SAN high-end de um fornecedor de pequeno porte, que
pode custar-lhe muito menos, com confi gurao e desempenho
semelhante;
Replicar dados para o site remoto da base em
uso: Sincronizar os dados entre o datacenter primrio e o remoto
um aspecto crtico de uma implementao bem sucedida de
Recuperao de Desastre. Uma vez que voc listou todas as
aplicaes que precisam ser replicadas para o site remoto, voc
agora precisa descobrir como sincronizar os dados entre estes dois
locais para todas essas aplicaes. Por exemplo, voc pode replicar
o banco de dados Oracle usando as tecnologias de replicao
fornecidas pelo fabricante do storage ou voc pode usar
o dataguard para replicar estes dados. Ambas solues tem suas
vantagens e desvantagens e voc tem que analis-las
cuidadosamente e escolher aquela que se encaixa no seu
oramento e escopo do plano de Recuperao de Desastre;
Replicar os dados iniciais usando um mtodo manual: Quando
voc estiver confi gurando o site remoto pela primeia vez, voc tem
que decidir como ser a sincronizao inicial dos dados. Por
exemplo, se voc for replicar um banco de dados de tamanho
enorme, voc no pode copiar o backup do banco de dados atravs
da rede para o site remoto, pois ir utilizar toda banda de rede. Em
vez disso, voc poderia realizar um backup em fi ta no datacenter
primrio e us-lo no datacenter secundrio para confi gurar o banco
de dados. Uma vez que a confi gurao inicial feito, voc pode
implementar alguma forma de sincronizao automtica entre os
sites;
Tempo de Recuperao Recovery Time Objective: Voc deve
identifi car, junto com os gerentes de negcio, qual o Tempo de
Recuperao aceitvel. Por exemplo, sua organizao pode decidir

que o Tempo de Recuperao deve ser de 8 horas, ou seja, aps um

desastre, no prazo mximo de 8 horas todas as aplicaes crticas
devem estar plenamente operacionais no site remoto. O Tempo de
Recuperao tem um impacto direto sobre quanto valor deve ser
gasto na implementao da soluo de Recuperao de Desastre.
Por exemplo, um Tempo de Recuperao de uma hora pode exigir
uma soluo mais sofi sticada que ser muito mais cara do que uma
soluo com o Tempo de Recuperao de 24 horas;
Ponto de Recuperao Recovery Point Objective : Assim
como Tempo de Recuperao, voc deve decidir, junto com os
gerentes de negcios, um Ponto de Recuperao aceitvel. Por
exemplo, sua organizao pode decidir que o Ponto de Recuperao
aceitvel de 2 horas, ou seja, depois de um desastre, quando
voc recuperou o servio no datacenter remoto, 2 horas de perda
de dados aceitvel para o negcio. Por exemplo, se o desastre
aconteceu s 15:00h, depois de restaurar o sistema no site remoto,
este ir conter dados de produo somente a partir das 13:00h. O
que signifi ca que voc perdeu os dados desde s 13:00 at s
15:00h. Em termos simples, se seu Ponto de Recuperao de 2
horas, a sua empresa deve estar disposto a perder 2 horas de
dados durante um desastre;
Failover Transferncia em caso de falha automtico ou
manual? Voc tem decidir se voc quer que o failover ocorra
automaticamente ou manualmente aps um desastre. Na maioria
dos casos, uma interveno manual aceitvel, pois voc no quer
uma transferncia automtica para o datacenter remoto em caso
de um falso-positivo. Tenha em mente que, depois de um failover,
h muito trabalho para voltar para o datacenter principal;
Failover da rede: Tenho visto que os planos de Recuperao de
Desastres do muito foco para replicao de dados, mas menos
foco para os aspectos da rede. Junto com sua equipe de rede,
preciso identifi car todas as infraestruturas de rede que precisam
ser replicadas. Por exemplo, se certifi car de que os endereos de
produo (URL) esto apontando para o site remoto aps o failover.
Se voc tiver estabelecido conexes VPN com seus clientes,
identifi car como restabelecer estas conexes VPN. Quando voc
criar/modifi car as regras de fi rewall (ou qualquer coisa relacionada
a segurana) no datacenter principal, voc precisa identifi car como
estas polticas de segurana podem ser replicadas para o site
remoto de forma contnua;
Confi gurao no lado remoto: Voc precisa ter um plano
adequado para acessar o datacenter remoto para depurar todos os
problemas. Voc pode confi gurar um KVM no site remoto para
acessar o console do hardware remoto do seu escritrio. Ou, voc
precisa planejar algum tipo de manual de servios no lado remoto,
onde algum pode ir para o datacenter de contingncia e executar
suas instrues;

Testes anuais de Recuperao de Desastre: Vrias

organizaes gastam muito tempo e dinheiro na criao de um site
de contingncia apenas para descobrir que ele realmente no
funciona como esperado quando se est em uma situao real de
Recuperao de Desastre. Uma vez por ano, voc deve validar suas
confi guraes atuais para garantir que o site remoto funciona
corretamente e cumpre o objetivo original. Se tudo estiver
confi gurado corretamente, voc deve ser capaz de transferir
manualmente suas aplicaes crticas do datacenter principal para
o remoto, e deix-las funcionando por alguns dias. Isso tambm
ajuda a ver como o site remoto lida com uma situao com carga
em tempo real;
Datacenter remoto como uma plataforma de Garantia de
Qualidade Quality Assurance: Em vez de usar o site remoto s
para a situao de desastre, voc pode us-lo como uma
plataforma de Garantia de Qualidade, fazendo testes de carga e
desempenho de seus aplicativos. Isso pode ser til, pois voc no
precisa investir em infraestrutura de testes adicional no datacenter
primrio. Quando voc tomar essa atitude, voc estar
sincronizando os dados do site primrio para o site remoto de
forma contnua. No entanto, sempre que voc fi zer um teste de
carga, voc precisa implementar uma soluo adicional, onde voc
precisa marcar um ponto de verifi cao do estado atual do site
remoto, realizar seu teste de qualidade, e logo em seguida voltar a
situao anterior para continuar a sincronizao dos dados com o
site primrio;
Plano de resposta: Uma vez que voc implementou o site remoto,
voc precisa ter um plano de Recuperao de Desastre sobre como
voc e sua equipe devem agir em uma situao real. Colaborar com
vrios departamentos em sua organizao, identifi cando os
recursos chaves que faro parte da equipe de resposta a incidentes
e identifi car o seu papel especfi co no plano de resposta. O plano
de resposta a incidentes um simples passo-a-passo sobre o que
precisa ser feito quando h uma desastre, quem ir realizar as
tarefas e em que sequncia as tarefas sero executadas;
No tem um site de contigncia? Muitas organizaes no tm
um site remoto. Se voc est trabalhando para um delas e voc
responsvel pelas aplicaes crticas e infraestrutura de TI, de
sua responsabilidade elaborar um plano de Recuperao de
Desastre, orientar a sua gerncia sobre a importncia de gastar
tempo e dinheiro em Recuperao de Desastre e obter a sua
aprovao. Mostre trs diferentes planos, um que custa muito,
outro de custo razovel e um com custo pequeno. Como explicado
anteriormente, o plano de Recuperao de Desastre pode variar
dependendo de vrios fatores, onde o custo um deles. Depois de
ter apresentado o seu plano detalhado para a sua gerncia, e se
este plano no foi aprovado, pelo menos voc vai se sentir bem, j
que deu o seu melhor na preparao de um bom plano;

Quando declarar um desastre? Voc precisa identifi car

claramente isso o quanto antes. Voc precisa ter um critrio muito
claro, escrito, sobre quando voc vai mudar para o site remoto.
Quais os critrios que desencadeiam a transferncia? Quando voc
inicia uma Recuperao de Desastre? Em que ponto voc declarar
um desastre e comear a trabalhar na transferncia para o site
remoto? A resposta para estas questes devem ser claramente
defi nidas e revisadas por todos os departamentos em sua
organizao, e fi nalmente, esses critrios devem ser aprovados
pela alta administrao. Quando o ambiente de produo fi ca fora
do ar , porque algum excluiu algum arquivo por engano, este
evento pode ou no desencadear um desastre. Para algumas
empresas, a recuperao dos dados do backup no prprio
datacenter principal provavelmente ser a melhor soluo. Para
outras, que no podem esperar esta restaurao do backup,
necessrio mudar para o site remoto;
Backup, backup e backup: Backups so muito importantes em
um plano de Recuperao de Desastre. Como mencionamos
anteriormente, seu objetivo deve ser nunca usar o site remoto, a
menos que um desastre natural real acontea. Assim, uma forte
estratgia de backup em seu site principal muito crtico. Voc
deve fazer backup de todos os seus aplicativos crticos. Quando
fi zer o backup de seu banco de dados, deve armazenar este backup
em quatro locais. Backups so praticamente inteis se voc no
restaur-los em um servidor de teste para confi rmar que esto
funcionando corretamente;
Aplicao de patches: Quando voc aplica uma correo de
sistema operacional, atualizao de fi rmware ou realiza qualquer
tipo de gerenciamento de confi gurao do hardware no site
principal, voc precisa ter uma estratgia para fazer estas
mudanas no site remoto de forma contnua. Voc no quer uma
situao, onde a confi gurao do sistema operacional em seu site
principal diferente do site remoto;
O sucesso depende de muitos fatores: Gesto a partir do topo,
alocao adequada do oramento, envolvimento de todas as
divises de negcios, um forte plano de Recuperao de Desastre,
recursos tcnicos, teste total da soluo de desastre, etc. Mais
importante, um escopo bem defi nido de Recuperao de Desastre
alinhado com o objetivo de negcio o mais importante para uma
soluo de sucesso;
Documentao: Um planejamento de Recuperao de Desastre
adequado requer vrios processos estabelecidos. Todos estes
processos devem ser documentados de forma adequada. Por
exemplo, um documento que explica o processo de escalonamento
quando um desastre ocorre. A documentao tcnica que explica o
que precisa ser feito para fazer a transferncia em caso de falha
para o site remoto. Um documento de comunicao que listas todos
os membros da equipe envolvidos na Recuperao de Desastre,

suas responsabilidades e como eles podem ser contatados durante

o desastre. Um documento para a equipe de suporte ao cliente,
para saber o que precisa ser comunicado ao cliente e como
encontrar os clientes durante um desastre. Um documento que lista
todos os testes que uma equipe de qualidade precisa realizar
depois que o site remoto foi ativado, etc.
O que foi apresentado apenas uma pequena parcela do que
Recuperao de Desastre. H muito mais, alm dos itens acima. Se
voc um administrador de sistema ou algum que responsvel
pelas aplicaes de TI e infraestrutura e se no tiver um plano de
desastre, considere isto como um lembrete para comear sua
estratgia de Recuperao de Desastre.