O que é um plano de recuperação de desastres? Componentes, RTO/RPO, testes e lista de verificação

Um plano de recuperação de desastres (DR) é um procedimento escrito e testado para restaurar sistemas e dados de TI após uma falha grave, um ciberataque ou a perda de um local. Indica quem declara o desastre, que sistemas voltam primeiro, com que rapidez (RTO), que perda de dados é aceitável (RPO) e os passos para fazer failover e failback.

Pontos principais

• Um plano de DR restaura a tecnologia; um plano de continuidade de negócio mantém toda a atividade a funcionar. Precisa de ambos, e o plano de DR deve ser um subconjunto do plano de continuidade.
• Qualquer decisão de recuperação começa com dois números por sistema: o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO).
• O DR na cloud segue quatro estratégias padrão: backup e restauro, pilot light, warm standby e multi-site ativo/ativo. O custo e a rapidez de recuperação aumentam em conjunto.
• Um plano não testado é um palpite. Teste pelo menos uma vez por ano, e com mais frequência nos sistemas críticos, desde exercícios de mesa até ao failover completo.
• Na UE, o artigo 21.º da NIS2 inclui a "gestão de cópias de segurança e a recuperação de desastres" como medida de segurança mínima. Na Suécia, aplica-se através da lei de cibersegurança (Cybersäkerhetslagen) desde 15 de janeiro de 2026.

O que é um plano de recuperação de desastres?

É o guia técnico para repor os sistemas após um evento que a resiliência normal não consegue absorver. Os gatilhos típicos são ransomware, uma falha num centro de dados ou numa região cloud, uma base de dados corrompida, uma alteração falhada, incêndio ou inundação.

A NIST SP 800-34 define um plano de DR como "um plano escrito para recuperar um ou mais sistemas de informação numa instalação alternativa em resposta a uma falha grave de hardware ou software ou à destruição de instalações" (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). O mesmo guia sublinha que um plano de DR se centra nos sistemas de informação, enquanto um plano de continuidade de negócio abrange processos de negócio como o processamento salarial ou o apoio ao cliente.

Verá também os termos "plano de DR de TI" e "DRP". Significam o mesmo. Um bom plano é suficientemente curto para ser usado sob pressão: direitos de decisão, prioridades, runbooks, contactos e evidências de testes. Um documento de política extenso que ninguém abre desde a última auditoria não conta.

Recuperação de desastres vs continuidade de negócio

A recuperação de desastres restaura a TI. A continuidade de negócio mantém a organização a entregar os seus produtos e serviços enquanto a TI, as pessoas, as instalações ou os fornecedores estão perturbados. O whitepaper da AWS sobre DR di-lo sem rodeios: o plano de DR "deve ser um subconjunto do plano de continuidade de negócio (BCP) da sua organização, não deve ser um documento autónomo."

Para uma comparação mais longa, incluindo o BCDR na AWS, no Azure e no Google Cloud, leia o nosso guia sobre recuperação de desastres e continuidade de negócio na cloud.

Cópia de segurança vs recuperação de desastres

Uma cópia de segurança é uma cópia dos dados. A recuperação de desastres é a capacidade de voltar a pôr o serviço a funcionar. Pode ter cópias de segurança perfeitas e continuar parado durante dias se ninguém tiver criado scripts para reconstruir servidores, redes, identidades e DNS à sua volta. As cópias de segurança são um dos contributos para o plano de DR; a regra 3-2-1 (três cópias, dois tipos de suporte, uma externa) é uma base sensata para elas.

Qual é o objetivo de um plano de DR?

O objetivo é tornar a recuperação previsível. Quando ocorre um desastre, o plano substitui a improvisação por decisões tomadas com calma e antecedência.

• Limitar a inatividade. Os sistemas críticos regressam num prazo acordado e por uma ordem acordada.
• Limitar a perda de dados. As cópias de segurança e a replicação correm com a frequência aprovada pelo negócio.
• Eliminar ambiguidades. Todos sabem quem pode declarar o desastre, quem lidera e quem fala com os clientes e as autoridades.
• Controlar o custo. Nem todos os sistemas precisam de um standby ativo. O plano regista quais precisam e porquê.
• Demonstrar conformidade. Reguladores, auditores, seguradoras e grandes clientes pedem cada vez mais uma capacidade de recuperação testada, e não apenas uma política.

São também os benefícios por que os compradores perguntam. Um plano que foi exercitado encurta as falhas reais, porque as pessoas já praticaram os passos.

RTO e RPO: os dois números que determinam o plano

O objetivo de tempo de recuperação (RTO) é o tempo que um sistema pode estar parado. O objetivo de ponto de recuperação (RPO) é a quantidade de dados, medida em tempo, que pode perder. A AWS define o RTO como "o atraso máximo aceitável entre a interrupção do serviço e o restabelecimento do serviço" e o RPO como "o intervalo de tempo máximo aceitável desde o último ponto de recuperação de dados."

Exemplo prático. Uma loja online acorda um RTO de 4 horas e um RPO de 15 minutos para o seu sistema de encomendas. Se a base de dados falhar às 10:00, as encomendas têm de voltar a ser aceites o mais tardar às 14:00, e no máximo as encomendas feitas entre as 09:45 e as 10:00 poderão ter de ser reintroduzidas ou recuperadas por outros meios. Uma cópia de segurança noturna não cumpre esse RPO; a loja precisa de envio de logs ou replicação pelo menos de 15 em 15 minutos. A sua wiki interna, em contraste, pode aceitar um RTO de 3 dias e um RPO de 24 horas, que uma cópia diária cobre.

Duas regras práticas ajudam:

• Defina objetivos por sistema, através de uma análise de impacto no negócio, e não um único número para "a TI". O impacto também pode mudar ao longo do tempo: a AWS nota que uma falha no processamento salarial pouco antes do dia de pagamento custa muito mais do que uma logo a seguir.
• Mantenha o RTO abaixo do tempo máximo de inatividade tolerável do processo de negócio. A NIST SP 800-34 explica que o RTO "deve normalmente ser mais curto" do que esse limite, porque os dados ainda têm de ser reprocessados depois de os sistemas voltarem.

Para mais exemplos e um método passo a passo para definir ambos os objetivos, consulte RPO e RTO na recuperação de desastres explicados.

Estratégias de DR: do backup e restauro ao ativo/ativo

O whitepaper da AWS Disaster Recovery of Workloads on AWS agrupa o DR na cloud em quatro estratégias. Os mesmos padrões aplicam-se no Azure (onde o Azure Site Recovery replica máquinas virtuais para uma região secundária) e no Google Cloud.

A distinção entre pilot light e warm standby confunde muitas equipas. A AWS explica-a assim: um ambiente pilot light "não consegue processar pedidos sem que seja tomada primeiro uma ação adicional", ao passo que um warm standby "consegue tratar tráfego (com capacidade reduzida) de imediato." O nosso artigo sobre recuperação de desastres pilot light trata esse padrão em pormenor.

Dois pontos do whitepaper são muitas vezes esquecidos. Primeiro, um desenho multi-AZ dentro de uma região "pode já satisfazer grande parte das suas necessidades de mitigação de risco" para falhas ao nível do centro de dados; uma segunda região destina-se a eventos que afetam toda a região ou a exigências regulamentares. Segundo, o backup e restauro só é rápido se a infraestrutura estiver definida como código, porque é preciso voltar a implementar redes, servidores e configuração, além dos dados.

DRaaS e recuperação de desastres na cloud

A recuperação de desastres como serviço (DRaaS) significa que um fornecedor replica os seus servidores para a sua cloud e opera as ferramentas de failover. O AWS Elastic Disaster Recovery e o Azure Site Recovery são as opções nativas; os fornecedores de serviços geridos constroem à sua volta runbooks, monitorização e testes. O DRaaS transforma um projeto de capital (um segundo centro de dados) num custo corrente, mas não elimina a sua responsabilidade de definir o RTO/RPO, aprovar o plano e participar nos testes.

Sites hot, warm e cold

Antes das regiões cloud, as estratégias de DR eram descritas pela prontidão do site alternativo. A NIST SP 800-34 descreve os sites cold como espaço com energia, refrigeração e conectividade mas sem equipamento, os sites warm como parcialmente equipados com hardware e telecomunicações, e os sites hot como totalmente configurados com hardware, infraestrutura e pessoal. Um site cold é o mais barato, mas pode demorar dias ou semanas a ativar. Os equivalentes na cloud correspondem aproximadamente ao backup e restauro (cold), ao pilot light ou warm standby (warm) e ao ativo/ativo (hot). Saiba mais em o que é um site hot na recuperação de desastres.

O que deve incluir um plano de DR? Lista de verificação

Use esta lista de verificação para construir um novo plano ou auditar um existente. Cada linha deve existir como um artefacto nomeado e datado, e não como uma promessa.

Como criar um plano de DR em sete passos

1. Faça uma análise de impacto no negócio e uma avaliação de risco. É o primeiro passo em qualquer esforço de DR. Liste os processos de negócio, quanto custa uma falha por hora e de que sistemas cada um precisa.
2. Defina o RTO e o RPO por sistema. Agrupe os sistemas em três ou quatro escalões, para desenhar por escalões e não para centenas de servidores individuais.
3. Escolha uma estratégia por escalão. Associe cada escalão a backup e restauro, pilot light, warm standby ou ativo/ativo. Confronte o custo com o impacto medido no passo 1.
4. Construa a capacidade técnica. Cópias de segurança, cópias entre regiões ou entre contas, replicação, infraestrutura como código, monitorização e alertas também no ambiente de recuperação.
5. Escreva os runbooks. Passos curtos e numerados que um engenheiro de serviço consiga seguir às 03:00, incluindo o failback.
6. Teste e corrija. Comece com um exercício de mesa, depois testes de restauro e depois um failover. Registe o RTO e o RPO medidos.
7. Mantenha-o. Reveja pelo menos uma vez por ano e após cada alteração significativa de sistemas, fornecedores ou da organização.

Recuperação de desastres para incidentes cibernéticos e ransomware

Para muitas empresas, o desastre para o qual realmente têm de planear é o ransomware ou uma conta de administrador comprometida, e não uma inundação. Isso altera o plano de três formas.

• A replicação não basta. A AWS avisa que a replicação contínua "pode não proteger contra eventos de desastre como a corrupção de dados ou ataques maliciosos (como a eliminação não autorizada de dados) tão bem como as cópias de segurança pontuais." Mantenha cópias de segurança pontuais que os atacantes não possam eliminar, idealmente numa conta separada com credenciais diferentes.
• A recuperação começa após a contenção. O plano de resposta a incidentes decide quando o ambiente está suficientemente limpo para restaurar para ele. Restaurar para uma infraestrutura comprometida volta a infetá-la.
• A identidade é uma dependência. Se o seu fornecedor de identidade ou gestor de palavras-passe estiver em baixo ou comprometido, os runbooks têm de explicar como é que quem responde obtém acesso.

Quando é que um plano de DR é ativado?

O plano é ativado quando uma falha excede, ou vai claramente exceder, o que o tratamento normal de incidentes consegue resolver dentro do RTO. Escreva os critérios, por exemplo "região principal indisponível durante mais de 30 minutos" ou "dados de produção cifrados por ransomware", e indique quem decide. Veja quando se deve ativar um plano de recuperação de desastres para os gatilhos típicos.

Com que frequência se deve testar um plano de DR?

Teste pelo menos uma vez por ano e após cada alteração significativa. Os sistemas críticos merecem exercícios mais frequentes. A política de contingência de exemplo do NIST diz que as capacidades de recuperação "devem ser testadas anualmente", e o guia recomenda rever o plano "pelo menos anualmente" e após alterações significativas.

O NIST também ajusta a profundidade dos testes ao nível de impacto do sistema. Para sistemas de baixo impacto, basta um exercício de mesa; os sistemas de impacto moderado exigem um exercício funcional que inclua a recuperação a partir de cópias de segurança; os sistemas de impacto elevado exigem um exercício funcional em grande escala que inclua "um failover do sistema para a localização alternativa."

A coluna de frequência é a nossa recomendação para uma empresa típica de média dimensão; o seu regulador ou os seus clientes podem exigir mais. A AWS resume por que os testes importam: "a única recuperação de erros que funciona é o caminho que testa com frequência." Após cada teste, registe o tempo de recuperação e a perda de dados medidos, compare-os com os seus objetivos e atribua responsáveis a cada lacuna.

A NIS2 e a lei sueca de cibersegurança

Para as organizações abrangidas pela NIS2, a recuperação de desastres deixou de ser uma boa prática opcional. O artigo 21.º, n.º 2, alínea c), da Diretiva (UE) 2022/2555 (NIS2) exige que as medidas de gestão do risco incluam, no mínimo, "a continuidade das atividades, como a gestão de cópias de segurança e a recuperação de desastres, e a gestão de crises". O artigo 23.º acrescenta prazos de notificação de incidentes significativos: um alerta precoce nas 24 horas seguintes ao conhecimento e uma notificação do incidente nas 72 horas. O seu plano de DR e o seu processo de notificação de incidentes têm, por isso, de funcionar em conjunto.

Na Suécia, a NIS2 é transposta pela lei de cibersegurança (Cybersäkerhetslag, SFS 2025:1506), que entrou em vigor a 15 de janeiro de 2026. O capítulo 2, secção 3, inclui "kontinuitetshantering och krishantering" (gestão da continuidade e gestão de crises) entre as medidas de segurança mínimas. Conte com os supervisores a pedir evidências: um plano atual, relatórios de testes e constatações encerradas.

Como a Opsio ajuda

A Opsio desenha, opera e testa o DR de cargas de trabalho na AWS e no Azure no âmbito do seu serviço de recuperação de desastres na cloud.

Perguntas frequentes

Quais são os componentes essenciais de um plano de recuperação de desastres?

Os componentes centrais são uma análise de impacto no negócio e avaliação de risco, o RTO e o RPO por sistema, uma estratégia de recuperação por escalão, cópias de segurança e replicação, critérios de ativação, funções e contactos, runbooks passo a passo que incluam o failback, um plano de comunicação e um calendário de testes e manutenção.

Qual é o primeiro passo num esforço de recuperação de desastres?

O primeiro passo é uma análise de impacto no negócio combinada com uma avaliação de risco. Diz-lhe que processos e sistemas mais importam e durante quanto tempo podem estar parados, o que define o RTO e o RPO de que depende cada decisão seguinte.

Com que frequência se deve testar um plano de recuperação de desastres?

Pelo menos uma vez por ano e após cada alteração importante de sistemas ou fornecedores. Faça exercícios de mesa para todos os planos e testes de restauro ou de failover para os sistemas críticos, como a NIST SP 800-34 recomenda para sistemas de maior impacto.

Qual é a diferença entre recuperação de desastres e continuidade de negócio?

A recuperação de desastres restaura sistemas e dados de TI. A continuidade de negócio mantém a atividade a funcionar durante uma perturbação e abrange também pessoas, instalações, fornecedores e comunicação. O plano de DR deve fazer parte do plano de continuidade de negócio.

Quais são as quatro estratégias de recuperação de desastres na cloud?

Backup e restauro, pilot light, warm standby e multi-site ativo/ativo. Vão de horas de tempo de recuperação ao custo mais baixo até uma recuperação quase em tempo real ao custo mais elevado, segundo o whitepaper de DR da AWS.

A NIS2 exige planeamento de recuperação de desastres?

O artigo 21.º, n.º 2, alínea c), da NIS2 exige que as entidades essenciais e importantes abranjam a continuidade das atividades, "como a gestão de cópias de segurança e a recuperação de desastres, e a gestão de crises". Na prática, isso significa uma capacidade de DR documentada e testada que possa apresentar à autoridade de supervisão.