O que é recuperação de desastres na nuvem?

O objetivo da recuperação de desastres na nuvem é minimizar o downtime e reduzir o impacto que crises como falhas de sistema, desastres naturais ou ataques cibernéticos podem ter sobre uma organização.

Uma organização pode recorrer a várias estratégias para implementar a recuperação de desastres na nuvem, mas todas foram pensadas para dar resiliência aos negócios em meio ao caos. De acordo com o Relatório do custo das violações de dados de 2026 da IBM, o custo médio global de uma violação é de 4,99 USD milhões, e a média nos Estados Unidos chega a 11,5 USD milhões. Estima-se que o downtime custe às organizações 1.100 USD por hora enquanto dura o incidente, e depois ele ainda pode causar danos à reputação e perda de negócios futuros. A recuperação de desastres na nuvem ajuda a mitigar parte desse risco.

A diferença em relação às estratégias tradicionais de recuperação de desastres é que ela usa infraestrutura na nuvem em vez de um data center físico. Uma solução de recuperação de desastres na nuvem pode oferecer alguns benefícios importantes, entre eles mais flexibilidade e escalabilidade do que um backup físico, menor investimento inicial e proteção contra a falha de uma localidade.

As duas métricas mais importantes de qualquer programa de recuperação de desastres são o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO). Juntas, essas métricas servem para projetar uma estratégia de recuperação de desastres na nuvem e medir sua eficácia.

Em geral, uma grande organização usa uma estratégia em vários níveis, na qual cada tipo de dado tem metas próprias de RPO e RTO. As organizações podem recorrer a uma análise de impacto nos negócios (BIA) para definir as metas dos diferentes departamentos e tipos de dados.

O RPO indica o volume máximo de perda de dados que uma organização pode tolerar. Ele serve para definir com que frequência replicar dados como arquivos, bancos de dados e aplicações e, por isso, é medido em tempo. Com um RPO de uma hora, o sistema atualiza os backups de hora em hora e, portanto, pode perder no máximo uma hora de dados novos. É algo parecido com o salvamento automático de um documento ou de um jogo: quanto menor o RPO, menos progresso se perde.

O RPO fica mais caro à medida que diminui, porque os dados precisam ser enviados com mais frequência. Felizmente, nem toda operação de recuperação de desastres na nuvem precisa de metas de RPO muito baixas, que vão de um minuto a poucos segundos.

Por exemplo, uma grande operação de e-commerce pode precisar de um RPO muito baixo para garantir que os dados de vendas se mantenham atualizados, mas essa mesma operação talvez só precise de um RPO de 24 horas para outros dados, como registros de funcionários ou arquivos de dados analíticos. Esses RPOs mais longos não exigem muita largura de banda de rede nem conexões ultrarrápidas e, por isso, custam menos.

Alguns softwares de DR na nuvem incluem mecanismos de recuperação pontual, que transmitem continuamente pequenas alterações nos dados para um log rotativo com prazo de expiração. Com isso, as organizações podem “voltar no tempo” até o segundo imediatamente anterior ao desastre.

Optar por um sistema na nuvem permite aproveitar essa flexibilidade: manter um RPO próximo de zero para os dados críticos e, ao mesmo tempo, recorrer a uma replicação mais barata, com RPO mais longo, para os dados arquivados, tudo isso sem se preocupar com provisionamento excessivo. Essa elasticidade traz eficiência e economia.

O RTO define por quanto tempo, no máximo, um sistema ou processo pode ficar fora do ar após uma interrupção antes que o downtime cause prejuízos inaceitáveis. É o intervalo que vai do segundo em que ocorre um desastre até a empresa estar em pleno funcionamento. Embora o RPO e o RTO sejam medidos em tempo (minutos, horas ou dias, por exemplo), o RPO é a meta de perda máxima de dados, enquanto o RTO é a meta de downtime.

“Em pleno funcionamento” nem sempre é tão bem definido quanto parece. Reiniciar o hardware, por si só, não deve marcar o fim da medição do RTO. Várias verificações precisam ser feitas antes que a empresa esteja totalmente recuperada e disponível para os clientes: além de reiniciar o hardware, é preciso que os serviços de back-end, o roteamento de rede e o DNS estejam todos operacionais.

A recuperação de desastres na nuvem ajuda a reduzir o RTO ao terceirizar boa parte do trabalho de recuperação para provedores especializados. Em uma configuração local de recuperação de desastres, os engenheiros talvez precisem se deslocar até o prédio e reiniciar ou trocar o hardware manualmente; com o DR na nuvem, isso não é necessário. Com a escalabilidade imediata, novos servidores ou mais armazenamento ficam disponíveis sempre que necessário.

Embora a recuperação de desastres na nuvem reduza o RTO, o valor efetivamente alcançável ainda depende de fatores como o volume de dados, o método de replicação e a forma como o sistema de failover é estruturado (por exemplo, se é uma configuração warm standby ou se tudo precisa ser ativado do zero, a frio). A próxima seção analisa essas estratégias em mais detalhes.

A recuperação de desastres na nuvem conta com quatro estratégias principais, que variam conforme o uso de largura de banda, os requisitos de velocidade e as metas de RPO e RTO.

A mais simples das estratégias de recuperação de desastres na nuvem, a de backup e restauração, cria uma cópia básica de imagens de servidor, arquivos e outros dados e a salva periodicamente na nuvem. Em caso de desastre, scripts de automação restauram os dados a partir dos backups e colocam os servidores em operação.

Os backups podem ser mutáveis ou imutáveis; os imutáveis têm proteção contra gravação e, por isso, não podem ser editados, excluídos nem sobrescritos. Os backups imutáveis são especialmente úteis na proteção contra ransomware, já que não podem ser alterados.Em geral, a estratégia de backup e restauração tem RTO e RPO mais altos que os das demais.

O RTO de um sistema de backup e restauração é alto porque ainda não há nenhuma infraestrutura de computação em funcionamento; esse sistema apenas armazena os dados para que sejam restaurados depois. Essa restauração pode envolver a cópia de grandes volumes de dados para novos servidores e exigir muito provisionamento, roteamento e indexação até que o sistema esteja em pleno funcionamento.

O RPO de um sistema de backup e restauração também é alto, porque os backups são feitos periodicamente, e não de forma contínua. Os dados registrados no intervalo entre um backup e outro são justamente os que se perdem. Esses sistemas costumam recorrer ao armazenamento frio, em que os dados são gravados em hardware como discos rígidos (HDDs) ou fitas magnéticas, que depois são desligados. Essa abordagem é econômica porque consome pouca energia ou largura de banda durante longos períodos, mas pôr esses discos para funcionar e acessar os dados pode levar tempo, o que aumenta o RTO.

A estratégia pilot light tira o nome da chama-piloto (em inglês, pilot light) de sistemas de calefação a gás, aquecedores de água ou lareiras: uma pequena chama sempre acesa, que consome o mínimo possível de combustível e, ainda assim, permite a ignição imediata. No contexto da recuperação de desastres na nuvem, a estratégia pilot light consiste em manter um elemento ativo, em geral uma réplica do banco de dados que se atualiza continuamente a cada alteração feita no banco de dados principal.

Os outros elementos, entre eles as imagens de servidores de aplicações e de servidores web e os modelos de contêiner, ficam em um armazenamento na nuvem mais barato, às vezes chamado de armazenamento morno. O armazenamento morno é um nível de armazenamento (que recebe nomes diferentes conforme o provedor) com preço pensado para acesso pouco frequente, mas imediato. Essa opção sai mais barata do que manter esses itens em atualização constante e, mesmo assim, garante acesso muito rápido, ao contrário do armazenamento frio, em que a leitura dos dados é mais lenta.

Em geral, as imagens e os modelos só são atualizados quando o código subjacente sofre alterações. Quando ocorre um desastre, o provedor de nuvem pode iniciar com rapidez novos servidores conectados ao banco de dados, o que reduz ao mínimo o downtime.

A estratégia pilot light aproveita os preços mais baixos dos níveis de armazenamento de acesso pouco frequente e, ao mesmo tempo, mantém o banco de dados ativo e em constante atualização: para muitas organizações, costuma ser o “meio-termo” ideal.

O warm standby fica um degrau acima do pilot light: custa mais, mas tem um RTO menor. Enquanto o pilot light mantém os servidores de aplicações como imagens que podem ser reconstruídas, uma configuração warm standby deixa esses servidores em execução contínua, só que em escala reduzida, para economizar energia e custos.

Uma forma de entender a diferença: na estratégia pilot light, a recuperação de desastres usa instruções armazenadas para recriar os ambientes; no warm standby, uma instância menor fica sempre pronta para receber o tráfego, enquanto, em segundo plano, a capacidade escala com mais servidores. Essas instâncias costumam rodar em máquinas virtuais (VMs), tanto nos sistemas warm standby quanto nos hot standby.

Escalar ou ampliar o uso dos servidores existentes é mais rápido do que criar e inicializar servidores novos, porque elimina a etapa de reconstrução. Isso pode reduzir o RTO a apenas alguns minutos, com um RPO próximo de zero (porque sempre há uma instância em funcionamento). Esses números, no entanto, têm um custo maior.

O warm standby também exige cuidados adicionais para evitar o problema do “estouro da manada”: um volume enorme de tráfego que sobrecarrega os servidores menores em standby. Os provedores de nuvem têm algumas formas de lidar com isso, como escalar os servidores antes de redirecionar o tráfego. Isso gera um breve downtime inicial, mas evita sobrecarregar as unidades centrais de processamento (CPUs).

O hot standby usa duas ou mais instâncias paralelas em diferentes localidades físicas, todas em funcionamento ao mesmo tempo. Funciona como os motores de um avião a jato: se um ambiente cai, os que continuam operando assumem a carga enquanto o dano é reparado. Em geral, as organizações limitam a carga de cada instância para que qualquer uma delas consiga assumir toda a operação se for a única a continuar funcionando.

O hot standby costuma ser combinado com algum outro tipo de sistema de backup; trata-se de um sistema projetado para manter a alta disponibilidade em situações como falhas de hardware. Em ataques de malware contra a integridade dos dados, o hot standby não basta, porque todos os dados ficam comprometidos. Por isso, as estratégias pilot light, warm standby e hot standby costumam vir acompanhadas de algum tipo de backup com snapshots pontuais.

Embora o DR na nuvem, o backup na nuvem e a recuperação de desastres como serviço (DRaaS) tenham um objetivo semelhante, o de proteger os dados em caso de emergência, diferem em dois aspectos: quanto do ambiente e da automação o backup abrange e quem fica responsável pela gestão.

Backup na nuvem é um termo genérico que designa a cópia dos dados para um armazenamento na nuvem. O backup na nuvem mantém uma cópia segura de todos esses dados, mas não inclui ambientes de aplicações, servidores nem capacidade de computação; por isso, a equipe interna de TI responsável pela recuperação de desastres terá de baixar os dados e reconstruir o sistema manualmente.

O DR na nuvem acrescenta automação e orquestração ao backup na nuvem. Ele captura todo o ambiente de aplicações, além dos scripts de automação e das regras usadas para provisionar servidores, restaurar dados e redirecionar o tráfego. Isso permite recuperar o sistema com muito menos esforço manual do que no backup na nuvem, que é mais limitado.

Em essência, a DRaaS é uma versão do DR na nuvem gerenciada por terceiros. Em vez de criar os próprios scripts e regras de replicação de dados e failover, a organização pode terceirizar esse trabalho para um provedor de DRaaS. Algumas ofertas de DRaaS consistem em um dashboard de autoatendimento para testes e acionamento, enquanto outras plataformas são totalmente gerenciadas por terceiros.

A recuperação de desastres na nuvem é um segmento em rápido crescimento; segundo a H2Vantix, o mercado de DR na nuvem deve passar de 12,1 USD bilhões em 2025 para 14,46 USD bilhões em 2026. Cada vez mais, as organizações optam por sistemas totalmente na nuvem ou de nuvem híbrida para a recuperação de desastres. De acordo com a Global Growth Insights, 59% das empresas migraram pelo menos parte da infraestrutura de recuperação para a nuvem. Vários motivos explicam a popularidade crescente da recuperação de desastres na nuvem.

Uma das maiores vantagens da recuperação de desastres na nuvem em relação às estruturas físicas tradicionais de DR é a economia nos custos iniciais. Em uma configuração tradicional de recuperação de desastres, o proprietário precisa pagar antecipadamente por todo o hardware e pela instalação, além das despesas recorrentes com contas de consumo e manutenção. A recuperação de desastres na nuvem permite que a organização pague apenas pelo que usa.

Na computação de uso geral, o consenso é que a nuvem barateia a configuração inicial, mas, no longo prazo, as soluções locais costumam sair mais em conta para cargas de trabalho previsíveis e de alto volume. Isso porque o investimento inicial se amortiza com o tempo e se converte em um custo fixo previsível, sem contar as taxas de transferência de dados, as assinaturas e os demais custos associados à computação em nuvem. Na recuperação de desastres, a questão não é tão simples e, no fundo, depende da taxa de uso e da propriedade dos recursos.

Em muitos casos, o custo total de propriedade da recuperação de desastres também pode ser menor no longo prazo, porque os recursos de DR ficam ociosos na maior parte do tempo, e a nuvem dispensa a organização de comprar esses recursos, se ainda não os tiver.

No entanto, o TCO pode ser menor com um backup físico se a organização já tem uma segunda localidade física e só precisa acrescentar a recuperação de desastres ao que já roda ali, ou se executa 24 horas por dia uma carga de trabalho estável e de alto volume, pesada o bastante para manter o hardware bem aproveitado.

Escalar o backup e a recuperação de desastres em infraestrutura local pode ser um problema, porque exige a compra de mais armazenamento ou capacidade de computação, além da instalação e da configuração. Além da despesa já mencionada, isso leva tempo. Com a recuperação de desastres na nuvem, a escalabilidade é nativa e, muitas vezes, automatizada: o armazenamento e a capacidade de computação escalam com rapidez conforme a demanda.

Essa escalabilidade pode ser especialmente vantajosa para organizações cujas necessidades de recuperação de desastres oscilam. Isso fica mais evidente no caso do hardware sem uso: quando a empresa já é dona do hardware, é muito difícil reduzir a estrutura para deixar de pagar por armazenamento ou capacidade de computação ociosos. Seria preciso vender os dispositivos usados e comprar outros quando necessário, ou então se conformar em pagar por equipamentos desnecessários. Evitar os custos do provisionamento excessivo é um dos principais motivos para a adoção do DR na nuvem.

Manter a recuperação de desastres em uma instalação local pode ser uma escolha arriscada diante de desastres naturais. Uma enchente, um incêndio ou outro desastre natural pode ser devastador para a infraestrutura de TI local, que funciona como um ponto único de falha. A recuperação de desastres na nuvem permite que a organização distribua o armazenamento por localidades físicas diferentes, todas acessíveis pela rede, o que protege contra a falha de uma única localidade e ajuda a manter a continuidade dos negócios.

Uma implementação inicial costuma ter várias etapas em comum, entre elas:

Uma análise preliminar dos riscos e do impacto nos negócios é um bom primeiro passo para definir as necessidades de proteção de dados da organização. Isso pode significar definir metas de RTO e RPO para diferentes aplicações, mapear todas as dependências do sistema e classificar os dados por categorias de prioridade para armazenamento frio, morno ou quente.

A avaliação de riscos pode envolver identificar os tipos de risco possíveis (ataques de ransomware, roubo de dados, desastres ambientais ou erro humano, por exemplo). Mas há outras avaliações a fazer. O aprisionamento a fornecedores é sempre um risco na escolha de um provedor de serviços, seja de nuvem ou não, e por isso um ambiente multinuvem pode ser um investimento que vale a pena. Além disso, é preciso levar em conta eventuais regulamentações sobre o armazenamento de determinadas informações em nuvens públicas.

Quando a organização já sabe do que precisa, pode comparar as formas de alcançar esses objetivos. As diferentes estratégias (backup e restauração, pilot light, warm standby e hot standby) podem ser usadas ao mesmo tempo para diferentes categorias de recuperação de desastres.

Se a organização optar por um sistema de DRaaS, grande parte da configuração e do gerenciamento ficará a cargo do provedor. Nos demais casos, a organização terá de configurar os próprios intervalos de sincronização de dados, a orquestração de failover e as regras de armazenamento.

Testar e manter o sistema de DR na nuvem com regularidade é essencial para garantir que ele funcione bem e esteja preparado para os piores cenários. Tanto as equipes internas de TI quanto as equipes terceirizadas de gerenciamento de DRaaS podem fazer testes isolados com regularidade para verificar se tudo está em ordem.

Esses testes podem medir o RTO e o RPO, confirmar que as aplicações de fato funcionam depois de um desastre e garantir que o failover opere como previsto, além de servir como ensaio geral para as equipes de TI. Esse ensaio também pode ajudar a testar o failback: o processo de retorno às operações normais.