Site hot, warm e cold são três níveis de prontidão do seu ambiente de contingência. A diferença entre eles não é qualidade — é quanto você paga por mês para reduzir o tempo de retomada. Escolher o nível errado significa gastar demais por um RTO que você não precisava, ou descobrir tarde que o seu não era suficiente.
Cold site: infraestrutura, sem operação
Um cold site é espaço, energia, refrigeração e conectividade prontos — mas sem seus sistemas rodando. Em caso de desastre, você provisiona os servidores, restaura os dados do backup e configura a rede.
É o modelo mais barato e o mais lento. O RTO é medido em dias, não horas, e depende inteiramente da qualidade do seu backup e da documentação da sua infraestrutura. Um cold site com backup íntegro e nenhuma documentação é um RTO indeterminado.
Faz sentido para sistemas de suporte cuja parada por alguns dias não interrompe a receita: ambientes de desenvolvimento, arquivos históricos, sistemas de apoio administrativo.
Warm site: parcialmente pronto
No warm site, o hardware está provisionado e os dados chegam por replicação periódica, mas as aplicações não estão ativas. Você liga, valida e assume — em horas, não dias.
É o ponto de equilíbrio para a maioria das empresas de médio porte. Você paga por capacidade reservada, não por um ambiente duplicado rodando em paralelo, e ainda consegue RTO dentro de um turno de trabalho.
O detalhe que decide se funciona: a frequência da replicação. Warm site com replicação diária tem RPO de até 24 horas, por mais rápido que seja o RTO. São métricas independentes, e confundi-las é erro comum.
Hot site: espelho ativo
O hot site roda em paralelo com o principal, com dados sincronizados continuamente. O failover leva minutos, às vezes segundos.
Custa aproximadamente o dobro da infraestrutura — você mantém dois ambientes de produção. A justificativa não é técnica, é financeira: se uma hora de parada custa mais que a diferença mensal entre warm e hot, o hot se paga.
Esse cálculo é surpreendentemente raro de ver feito. Muitas empresas pagam por hot site em sistemas que tolerariam warm, e mantêm em warm justamente o sistema que gera a receita.
A escolha é por sistema, não por empresa
O erro mais caro nessa decisão é tratá-la como uniforme. Sua empresa não precisa de um nível — cada sistema precisa do seu.
- ERP e faturamento: normalmente hot ou warm agressivo. Parada aqui trava a operação e a receita.
- E-commerce e sistemas com cara para o cliente: hot, porque a parada é visível e mensurável em conversão perdida.
- BI, relatórios e data warehouse: warm ou cold. Ninguém fecha por não ter dashboard por dois dias.
- Desenvolvimento e homologação: cold, quase sempre.
Fazer esse mapeamento é o que transforma DR de despesa em decisão. Sem ele, você está comprando um nível de proteção médio para necessidades que não são médias.
Como começar o mapeamento
Liste seus sistemas e responda, para cada um, uma pergunta só: quanto custa uma hora de parada? Em receita perdida, em multa contratual, em hora-parada de equipe, em dano de reputação quando aplicável.
Com esses números na mesa, o nível de contingência de cada sistema deixa de ser opinião. E a conversa com o fornecedor passa a ser sobre dimensionamento, não sobre convencimento.
Onde a Adentro entra
O DR Ativo cobre o cenário de contingência pronta para assumir a operação. Nosso time técnico ajuda a fazer o mapeamento por sistema antes de propor arquitetura — porque propor antes disso é chutar.