A recuperação de desastres (DR) consiste em tecnologias de TI e melhores práticas projetadas para evitar ou minimizar a perda de dados e a interrupção dos negócios resultantes de eventos catastróficos, desde falhas de equipamentos e quedas de energia localizadas até ataques cibernéticos, emergências civis, ataques criminais ou militares e desastres naturais.

Muitas empresas, especialmente organizações de pequeno e médio porte deixam, por descuido, de desenvolver um plano de recuperação de desastres viável e confiável. Sem esse plano, elas ficam abertas ao impacto de eventos consideravelmente disruptivos.

Falhas de infraestrutura falha podem custar até USD 100.000 por hora (link externo à IBM) e os custos de falha de aplicativos críticos custam USD 500.000 a USD 1 milhão por hora. Muitas empresas não conseguem se recuperar dessas perdas. Mais de 40% das pequenas empresas não reabrem depois de passar por um desastre e, entre as que o fazem, outros 25% fecham no primeiro ano após a crise. O planejamento de recuperação de desastres pode reduzir drasticamente esses riscos.

O planejamento de recuperação de desastres envolve a criação de estratégias, o planejamento, a implementação de tecnologias adequadas e testes contínuos. A manutenção de backups de seus dados é um componente crítico do planejamento de recuperação de desastres, mas um processo de backup e recuperação por si só não constitui um plano completo de recuperação de desastres.

A recuperação de desastres também envolve garantir que quantidades adequadas de armazenamento e capacidade de computação estejam disponíveis para manter procedimentos robustos de failover e failback. Failover é o processo de transferência de cargas de trabalho para sistemas de backup, para que os processos de produção e as experiências do usuário final sofram o menor nível de interrupção possível. Failback envolve a recuperação para os sistemas principais originais.

Veja nosso artigo para ter mais informações sobre a importante distinção entre planejamento de backup e de recuperação de desastres.

O planejamento de continuidade dos negócios cria sistemas e processos para garantir que todas as áreas de sua empresa consigam manter as operações essenciais ou retomá-las o mais rápido possível em caso de crise ou emergência. O planejamento de recuperação de desastres é o subconjunto do planejamento de continuidade dos negócios voltado para a recuperação da infraestrutura e dos sistemas de TI.

Análise de impacto nos negócios

A criação de um plano abrangente de recuperação de desastres começa com a análise de impacto nos negócios. Ao realizar esta análise, você criará uma série de cenários detalhados de desastres que poderão ser usados para prever o tamanho e o escopo das perdas que você incorreria se certos processos de negócios fossem interrompidos. E se o seu call center de atendimento ao cliente fosse destruído por um incêndio, por exemplo? Ou se um terremoto atingisse sua matriz?

Isso permitirá que você identifique as áreas e funções mais críticas de sua empresa e determine o tempo de inatividade que cada uma dessas funções críticas pode tolerar. Com essas informações em mãos, você pode começar a criar um plano de como manter as operações mais críticas em vários cenários.

O planejamento de recuperação de desastres de TI deve seguir e servir de apoio ao planejamento de continuidade dos negócios. Se, por exemplo, seu plano de continuidade dos negócios solicitar que representantes de atendimento ao cliente trabalhem de casa no advento de um incêndio no call center, quais de hardware, software e recursos de TI seriam necessários para dar suporte a esse plano?

Análise de risco

Avaliar a probabilidade e as consequências potenciais dos riscos enfrentados por seu negócio também é um componente essencial do planejamento de recuperação de desastres. À medida que os ataques cibernéticos e o ransomware se tornam mais prevalentes, é fundamental entender os riscos gerais de segurança cibernética que todas as empresas enfrentam hoje, bem como os riscos específicos do seu setor e de sua localização geográfica.

Para diversos cenários, incluindo desastres naturais, falha de equipamentos, ameaças internas, sabotagem e erros de funcionários, você deve avaliar seus riscos e considerar o impacto geral em seus negócios. Faça a si mesmo as seguintes perguntas:

• Qual seria o prejuízo devido a oportunidades de vendas perdidas ou interrupções nas atividades geradoras de receita?
  
  
• Qual o nível de dano que a reputação da sua marca sofreria? Qual seria o impacto à satisfação de seus clientes?
  
  
• Como a produtividade dos funcionários seria afetada? Quantas horas mão de obra podem ser perdidas?
  
  
• Quais riscos o incidente pode representar para a saúde ou segurança das pessoas?
  
  
• Haveria algum impacto no progresso de iniciativas ou objetivos de negócios? Qual?

Priorizando aplicativos

Nem todas as cargas de trabalho são igualmente críticas para a capacidade da sua empresa em manter as operações; o tempo de inatividade é muito mais tolerável para alguns aplicativos do que para outros. Separe seus sistemas e aplicativos em três níveis, dependendo de quanto tempo seria possível que ficassem indisponíveis e quão sérias seriam as consequências da perda de dados.

1. Críticos: aplicativos cujo funcionamento é essencial para a sobrevivência do seu negócio.
   
   
2. Importantes: aplicativos para os quais você pode tolerar períodos de inatividade relativamente curtos.
   
   
3. Não essenciais: aplicativos que poderiam ser substituídos temporariamente por processos manuais ou que seriam até mesmo dispensáveis.

Documentando dependências

O próximo passo no planejamento de recuperação de desastres é criar um inventário completo de seus ativos de hardware e software. Nesta fase, é fundamental entender as interdependências entre aplicativos. Se um aplicativo de software ficar indisponível, quais outros serão afetados?

Projetar resiliência, além de modelos de recuperação de desastres, em sistemas nos estágios iniciais de desenvolvimento é a melhor maneira de gerenciar interdependências de aplicativos. É muito comum nas arquiteturas atuais, baseadas em microsserviços, descobrir processos que não podem ser iniciados quando outros sistemas ou processos estão indisponíveis e vice-versa. Esta é uma situação da qual é difícil se recuperar e, portanto, é essencial descobrir tais problemas quando ainda há tempo para desenvolver planos alternativos para seus sistemas e processos, ou seja, antes que ocorra um desastre.

Estabelecendo objetivos de tempo de recuperação, objetivos de ponto de recuperação e objetivos de consistência de recuperação

Ao considerar suas análises de risco e impacto negócios, você deve ser capaz de estabelecer objetivos para a quantidade de tempo necessária para disponibilizar seus sistemas novamente, o volume de dados necessário e a taxa de desvio ou danos aos dados que pode ser tolerada.

Seu objetivo de tempo de recuperação (RTO) é a quantidade máxima de tempo necessária para restaurar o funcionamento de aplicativos ou sistemas após uma interrupção de serviços.

Seu objetivo do ponto de recuperação (RPO) é a idade máxima dos dados que devem ser recuperados para que sua empresa retome as operações rotineiras. Para algumas empresas, perder até mesmo alguns minutos de dados pode ser catastrófico, enquanto negócios em outros setores podem tolerar janelas mais longas.

Um objetivo de consistência de recuperação (RCO) é estabelecido no acordo nível de serviço (SLA) para serviços de proteção contínua de dados. É uma métrica que indica a quantia tolerável de entradas inconsistentes em dados de negócios de processos ou sistemas recuperados em situações de recuperação de desastres, descrevendo a integridade dos dados de negócios em ambientes de aplicativos complexos.

Problemas de conformidade regulamentar

Todos os softwares e soluções de recuperação de desastre definidos por sua empresa devem atender a todos os requisitos de segurança e proteção de dados aos quais está obrigada a aderir. Isso significa que todos os sistemas de backup e failover de dados devem ser projetados para atender aos mesmos padrões de garantia de confidencialidade e integridade dos dados de seus sistemas primários.

Ao mesmo tempo, várias normas regulamentares estipulam que todas as empresas devem manter planos de recuperação de desastre e/ou continuidade dos negócios. A Lei Sarbanes-Oxley (SOX), por exemplo, exige que todas as empresas de capital aberto nos Estados Unidos mantenham cópias de todos os registros comerciais por no mínimo cinco anos. O não cumprimento dessa regulamentação (incluindo negligência em estabelecer e testar sistemas adequados de backup de dados) pode resultar em penalizações financeiras consideráveis para as empresas e até mesmo a prisão de seus líderes.

Escolhendo tecnologias

Os backups servem como a base sobre a qual qualquer plano de recuperação desastres é construído. No passado, a maioria das empresas dependia de fitas e discos rotativos (HDDs) para backups, mantendo múltiplas cópias de seus dados e armazenando pelo menos uma delas em um local externo.

No atual mundo de transformação digital always-on, os backups em fita em repositórios externos muitas vezes não conseguem atingir os RTOs necessários para manter operações críticas. Arquitetar sua própria solução de recuperação de desastres envolve a replicação de diversos recursos de seu ambiente de produção e irá gerar custos para equipes de suporte, administração, instalações e infraestrutura. Por essa razão, muitas organizações estão recorrendo a soluções de backup baseadas em cloud ou provedores completos de Disaster-Recovery-as-a-Service (DRaaS).

Escolhendo locais de sites de recuperação

Construir seu próprio data center de recuperação de desastres envolve equilibrar diversos objetivos que competem entre si. Por um lado, uma cópia de seus dados deve ser armazenada em algum lugar geograficamente distante o suficiente de sua matriz ou filiais, para que não seja afetada pelos mesmos eventos sísmicos, ameaças ambientais ou outros riscos de seu local principal. Por outro lado, os backups armazenados externamente sempre demoram mais para serem restaurados do que aqueles armazenados no local do site primário; além disso, a latência de rede pode ser ainda maior em distâncias maiores.

Testes e revisões contínuas

Em termos práticos, se o seu plano de recuperação de desastres ainda não foi testado, então ele não pode ser confiável. Todos os funcionários com responsabilidades relevantes devem participar do exercício de teste de recuperação de desastres, que pode incluir a manutenção de operações do site de failover por um período de tempo.

Se realizar um teste de recuperação de desastres abrangente estiver fora do seu orçamento ou capacidade, você também pode agendar uma reunião para fazer um passo a passo simulado dos procedimentos de teste, embora você deve estar ciente que esse tipo de teste tem menor probabilidade de revelar anomalias ou pontos fracos em seus procedimentos de DR, especialmente relacionados às interdependências de aplicativos não descobertas, do que um teste completo.

Como seus ativos de hardware e software mudam ao longo do tempo, é necessário garantir que seu plano de recuperação desastres também esteja atualizado. Recomenda-se revisar o plano periodicamente.

O IBM Knowledge Center fornece um exemplo de plano de recuperação de desastres.

O Disaster-Recovery-as-a-Service (DRaaS) é uma das soluções de serviços de TI gerenciados mais populares e de rápido crescimento disponíveis atualmente. Seu fornecedor documentará RTOs e RPOs em um acordo de nível de serviço (SLA), que descreve seus limites de tempo de inatividade e as expectativas sobre a recuperação de aplicativos.

Os fornecedores de DRaaS normalmente fornecem ambientes de failover baseados em cloud. Este modelo oferece economia considerável de custos em comparação com a manutenção de recursos de hardware dedicados em um data center próprio. Geralmente os contratos envolvem o pagamento de uma taxa para manutenção dos recursos de failover, mais os custos por uso dos recursos consumidos em uma situação de recuperação de desastres. Seu fornecedor normalmente assumirá toda a responsabilidade pela configuração e manutenção do ambiente de failover.

As soluções de serviços de recuperação de desastres diferem de fornecedor para fornecedor. Alguns fornecedores definem sua solução como uma solução completa e abrangente, enquanto outros oferecem serviços fragmentados, desde a restauração de aplicativos específicos até a replicação completa do data center na cloud. Algumas soluções podem incluir serviços de planejamento ou de teste de recuperação de desastres, enquanto outros cobrarão uma taxa adicional de consultoria por essas soluções.

Certifique-se de que todos os aplicativos de software corporativos necessários sejam suportados, assim como quaisquer provedores de cloud pública com os quais esteja trabalhando. Também recomenda-se garantir que o desempenho de aplicativos seja satisfatório no ambiente de failover e que os procedimentos de failover e failback tenham sido bem testados.

Caso já tenha construído uma solução de recuperação de desastres (DR) no local, pode ser um desafio avaliar os custos e benefícios de mantê-la em vez de mudar para uma assinatura mensal DRaaS.

A maioria das soluções de DR no local geram custos de hardware, energia, mão de obra para manutenção e administração, software e conectividade de rede. Além do capital inicial investido na construção de seu ambiente de DR, será necessário incluir o upgrade periódico de software em seu orçamento. Uma vez que sua solução de DR deve permanecer compatível com seu ambiente de produção primário, você deve garantir que sua solução de DR tenha as mesmas versões de software. Dependendo dos detalhes do seu contrato de licenciamento, isso pode efetivamente dobrar seus custos de software.

A migração para uma assinatura de DRaaS não só pode reduzir seus gastos com hardware e software, como também pode reduzir seus custos de mão de obra, transferindo o ônus de manter o site de failover para o fornecedor.

Se você estiver considerando soluções de DRaaS de terceiros, certifique-se que o fornecedor tenha capacidade para armazenar backups em diversas regiões e locais. Se um evento climático significativo como um furacão afetar seu escritório principal, o site de failover está longe o suficiente para não ser afetado pela tempestade? Além disso, o fornecedor teria capacidade adequada para atender às necessidades combinadas de todos os seus clientes em sua área, caso muitos deles fossem afetados ao mesmo tempo? Você está confiando no seu fornecedor de DRaaS para cumprir RTOs e RPOs em tempos de crise; sendo assim, procure um provedor de serviços com forte reputação em confiabilidade.

Veja o artigo "Disaster Recovery as a Service (DRaaS) vs. Recuperação de Desastres (DR): qual é ideal para você?⁣" para ter uma visão geral comparativa das duas soluções.