O que é Disaster Recovery de verdade foi o tema do primeiro episódio da segunda temporada do Adentro Labs, o podcast da Adentro que explora os desafios mais críticos da infraestrutura de TI e da continuidade de negócios.
No episódio, Ronaldo Barbieri, CEO da Adentro, recebeu Jeferson Roehe, CTO da Adentro desde 2014, com vasta experiência na recuperação de ambientes e na implementação de tecnologias e metodologias de DR em clientes de diferentes portes e setores.
O resultado foi uma conversa técnica, direta e sem atalhos, sobre um tema que pode definir o futuro de uma empresa quando o pior acontece.
O que é Disaster Recovery e por que backup não é a mesma coisa
A confusão começa antes mesmo de o problema chegar. Ronaldo abriu o episódio com uma polêmica direta: backup não é DR.
Jefferson explicou que o backup é essencialmente um conjunto de cópias de segurança ao longo do tempo, um versionamento voltado para compliance jurídico e legal, que define por quanto tempo cada alteração precisa ser guardada.
Já o Disaster Recovery vai além. “Ter a cópia dos dados não garante que você consiga executar as atividades para recuperá-los”, afirmou Jefferson. DR é um plano de recuperação: se a máquina de produção foi comprometida ou destruída, não há onde restaurar o backup. E backup, normalmente, é tratado como uma área mais fria, mais lenta. O DR é o que coloca a empresa de volta no ar com agilidade.
Essa distinção tem consequências práticas. Jefferson relembrou casos em que empresas tinham backup disponível, mas ficaram paradas porque não tinham um ambiente preparado para receber a restauração. O backup existia. A operação não voltou.
RTO e RPO: os dois números que definem o plano de DR
Depois de diferenciar backup de DR, Ronaldo trouxe outro conceito que aparece com frequência, e que também gera muito ruído: RTO e RPO.
Jefferson esclareceu cada um. O RTO (Recovery Time Objective) é o tempo máximo aceitável de indisponibilidade: quanto tempo a operação pode ficar fora do ar? Já o RPO (Recovery Point Objective) é a tolerância à perda de dados: se o RPO é de 24 horas, a empresa aceita voltar a um ponto consolidado do dia anterior.
Como definir esses números na prática
A dificuldade, segundo Jefferson, está em olhar para o negócio, não apenas para a TI.
Uma farmácia com PDV sincronizado em tempo real tem um impacto muito diferente de uma empresa com sistemas que rodam offline na ponta. Uma transportadora que não consegue emitir conhecimentos de carga para a saída dos caminhões tem um problema imediato. O mapeamento precisa começar pelo impacto real que a parada causa.
“A TI consegue dar uma resposta rápida para voltar os dados”, disse Jefferson. “Mas o negócio está preparado para ficar uma hora fora? Para perder 8 horas de dados?”
A resposta inicial quase sempre é “não posso perder nada”. Mas eventos reais mostram que a empresa se adapta, e que o mais importante é saber o limite real antes do desastre, não durante. Um comitê pequeno, com pessoas da TI, da área jurídica e da operação, é o ponto de partida ideal para essa conversa.
Cenários reais de desastre no Brasil
Quando se fala em desastre, a imagem que vem à mente costuma ser furacão ou coisa de filme. Mas Ronaldo e Jefferson trouxeram o debate para o dia a dia real do mercado brasileiro.
Os desastres lógicos são os mais frequentes: ataques de ransomware, criptografia de dados, falhas em storage, problemas em controladoras de disco. Não precisam de nenhuma catástrofe natural. Estão dentro do próprio ambiente de TI.
Mas os desastres físicos também são uma realidade próxima, e Jefferson lembrou das enchentes no Rio Grande do Sul em 2024. Empresas que tinham produção e backup no mesmo local perderam os dois. Quem tinha uma cópia off-site em outro ponto geográfico saiu em situação completamente diferente.
Empresa na nuvem também precisa de DR?
Sim. Essa foi uma das respostas mais diretas do episódio.
Jefferson explicou que, na letra miúda dos contratos das grandes nuvens públicas, a responsabilidade pelo dado é do cliente, o controlador, e não do provedor, que apenas opera o dado. Contratar uma máquina virtual não inclui, automaticamente, backup ou DR. Se a zona de disponibilidade cair, a máquina para junto.
“Você pode contratar uma máquina virtual na nuvem e não aplicar o firewall nela. A mesma coisa funciona com as regras de backup e DR”, alertou Jefferson. “Você levou para dentro da nuvem a mesma insegurança que tinha no on-premise.”
E o que mais chama atenção: as camadas de segurança, as políticas de backup e as replicações de DR costumam ser os primeiros itens cortados quando o projeto chega à fase de aprovação de budget.
Por que os planos de DR nunca são testados
Ronaldo trouxe uma situação que ele ouve com frequência: a empresa tem um plano de DR, mas nunca o testou. Jefferson confirmou, e explicou por quê isso acontece tanto.
O motivo mais comum é a ausência de janela na produção. Para testar o DR, é necessário subir o ambiente de replicação paralelamente ao de produção. Quem não consegue parar ou reduzir a produção não consegue testar. E quem nunca testou descobre os problemas só quando o desastre chega de verdade.
“Tudo aquilo que você poderia ter aprendido a cada três ou seis meses, você deixa para aprender no momento do DR”, disse Jefferson. Uma indisponibilidade que poderia durar uma hora se torna dias. Ou semanas.
Como fazer os testes na prática
Jefferson foi direto sobre a frequência e o formato. No primeiro ano, o ideal é testar a cada três meses, em modo off, sem afetar a produção. O objetivo não é a perfeição. É levantar o que precisa ser corrigido.
“O primeiro teste nunca dá certo”, ele afirmou. “Aparecem os erros clássicos: entradas de DNS, nomes de site, roteamento, regras de Firewall.” No segundo teste, a equipe já chega nas minúcias das aplicações. Depois de ajustado, seis meses é um intervalo adequado para a maioria das empresas. Um ano já começa a ficar arriscado, o ambiente muda demais nesse período.
Outro ponto levantado por Ronaldo foi a documentação. Ele já viu planos de DR com 80 ou 90 páginas que, na prática, não funcionam no momento do desastre. A primeira coisa que acontece é a equipe sentar para ler, e o tempo vai embora.
Jefferson usou uma metáfora precisa: é como a placa de uma rodovia. “Dobre à direita para a praia” move uma decisão rápida. Um outdoor com 20 frases complexas paralisa. Um documento de DR precisa dizer, na primeira página, quem acionar, quais máquinas subir e por onde começar.
Os 4 Ps do plano de continuidade de negócios
Para encerrar a parte técnica, Ronaldo apresentou um framework que usa nas suas conversas com clientes: os 4 Ps.
Pessoas – Quem precisa estar envolvido no momento do desastre? Não é a empresa inteira. É um grupo pequeno, com papéis definidos.
Premissas – Em quais situações o DR será acionado? Às vezes, esperar o ambiente produtivo voltar faz mais sentido do que ativar o DR. Essa decisão precisa estar documentada antes do incidente.
Processos – Quais ações executar, em qual ordem, e quem é responsável por cada uma delas?
Provedores – No momento do desastre, a equipe interna costuma ser pequena demais para uma reconstrução do zero. Jefferson reforçou que ter bons parceiros na sala de crise faz diferença real: duas cabeças conferem melhor, executam melhor e reduzem o risco de uma segunda queda logo após a recuperação.
“A gente já acompanhou situações em que o cliente precisava abrir um novo CNPJ porque tinha o produto, mas não tinha mais os dados”, lembrou Ronaldo. “O dado hoje é o novo ouro das empresas.”
Comece agora: o primeiro passo antes de contratar qualquer solução
Para fechar o episódio, Ronaldo pediu algo acionável, algo que qualquer empresa pudesse fazer ainda essa semana, antes de contratar qualquer solução.
Jefferson foi direto: baixe o assessment de risco e segurança e o simulador de plano de DR disponíveis no site da Adentro. São dois documentos que ajudam a mapear a maturidade atual e a entender por onde começar, sem precisar de uma “bíblia encadernada” cheia de fluxogramas.
O segundo passo é garantir que os dados estejam fisicamente separados da produção: seja em backup off-site, replicação ou DR em outro ambiente. “Às vezes a empresa joga todo o histórico fora por uma economia de algumas dezenas de reais por mês”, disse Jefferson. “Esse é um dos piores cenários, e um dos mais evitáveis.”
Siga acompanhando o Adentro Labs
A cada episódio do Adentro Labs, especialistas e líderes de grandes instituições compartilham experiências, desafios e inovações que estão moldando o futuro da tecnologia.
Se você atua com TI, inovação ou transformação digital, esse conteúdo é para você. Apresentado por Ronaldo Barbieri, CEO da Adentro, o canal traz conversas técnicas, diretas e acessíveis.
Assista agora na íntegra primeiro episódio da segunda temporada do Adentro Labs:
Confira também todos os episódios do Adentro Labs no canal no YouTube da Adentro ou no Spotify.
Você também pode se interessar:
