Um hot site é um local de recuperação totalmente equipado, com hardware, software, ligações de rede e dados atuais já instalados, que pode assumir a operação do site principal em minutos a horas. É o tipo de site de recuperação de desastres mais rápido e mais caro. Na cloud, o equivalente é uma configuração de hot standby ou ativo/ativo numa segunda região.
Pontos principais
- O NIST descreve os hot sites como instalações dimensionadas para o sistema e configuradas com o hardware necessário, a infraestrutura de suporte e o pessoal de apoio.
- Os dados são atualizados de forma contínua ou logo após o site principal, pelo que se perdem poucos dados e a recuperação é rápida.
- Os warm sites têm algum equipamento e exigem preparação antes de serem usados. Os cold sites oferecem apenas espaço e energia.
- Em termos de AWS, isto corresponde ao "hot standby" (ativo/passivo com capacidade total) ou ao "multi-site ativo/ativo", a estratégia mais complexa e dispendiosa.
- A replicação não protege contra corrupção de dados nem ransomware. Continua a precisar de cópias de segurança com recuperação pontual.
O que é um hot site na recuperação de desastres?
É um local alternativo que já executa, ou pode executar de imediato, uma cópia dos seus sistemas de produção. Quando o site principal falha, redireciona os utilizadores e continua a trabalhar.
A referência normativa dos EUA é a NIST SP 800-34, o Contingency Planning Guide for Federal Information Systems. Define este tipo de site como tendo equipamento suficiente, o software de produção atual e armazenamento adequado, com os dados de cópia de segurança mais recentes carregados. Em muitos casos, as suas bases de dados são atualizadas ao mesmo tempo que as do site principal, ou pouco depois. O NIST refere ainda que o site precisa de uma forma de transferir rapidamente a conetividade dos utilizadores e de um apoio operacional próximo do do site de produção.
Um exemplo do NIST são dois sistemas idênticos em locais diferentes, ambos em produção, cada um capaz de suportar a carga total, com os dados sincronizados continuamente. O NIST considera esta a opção mais cara.
Hot site vs warm site vs cold site
Os três tipos de site diferem na quantidade de recursos preparados antes de um desastre. Mais preparação significa recuperação mais rápida e custo de funcionamento mais elevado.
| Característica | Cold site | Warm site | Hot site |
|---|---|---|---|
| O que existe | Espaço, energia, ligações de telecomunicações, controlo ambiental | Parte ou a totalidade do hardware, software, telecomunicações e energia | Hardware completo, infraestrutura de suporte e pessoal |
| Dados | Restaurados a partir de cópias de segurança após o evento | Restaurados ou parcialmente replicados | Atuais ou quase atuais, muitas vezes replicados de forma contínua |
| Tempo de preparação | Longo | Médio | Curto |
| Custo | Baixo | Médio | Médio a elevado |
| Utilização típica | Sistemas que podem estar parados durante dias | Sistemas importantes com alguma tolerância | Sistemas em que minutos de indisponibilidade importam |
As linhas de tempo de preparação e de custo seguem a tabela de critérios de sites alternativos de exemplo do NIST. Os tempos de recuperação exatos dependem da sua arquitetura e dos testes, não da designação.
Como funciona um hot site?
Uma configuração funcional tem quatro componentes que têm de se manter alinhados com a produção:
- Infraestrutura: servidores, armazenamento e capacidade de rede dimensionados para a carga que precisa de executar aí.
- Replicação de dados: cópia síncrona ou assíncrona de bases de dados e ficheiros a partir do site principal.
- Configuração e código: as mesmas versões de software, correções e definições da produção, idealmente implementadas a partir dos mesmos modelos de infraestrutura como código.
- Comutação de tráfego: alterações de DNS, de balanceador de carga ou de rede que encaminham os utilizadores para o site de recuperação quando o ativa.
O que acontece na ativação?
A ativação é uma decisão, não apenas um passo técnico. O responsável pelo incidente confirma que o site principal não consegue recuperar dentro do objetivo de tempo de recuperação (RTO) acordado e, depois, a equipa segue o runbook: parar as escritas no site principal, se possível, promover as réplicas das bases de dados, comutar o tráfego, verificar se as aplicações funcionam e informar os utilizadores e as partes interessadas. A AWS refere que o failover automático com base em verificações de estado deve ser usado com cautela, porque um falso alarme custa disponibilidade e dados. Por isso, muitas equipas acionam o failover manualmente, mas automatizam todos os passos por trás do botão.
Hot sites na cloud: hot standby e ativo/ativo
Na cloud raramente se arrenda um edifício separado. Em vez disso, executa-se uma segunda cópia do ambiente noutra região ou Zona de Disponibilidade. O whitepaper de recuperação de desastres da AWS descreve quatro estratégias, da mais económica à mais completa:
| Estratégia AWS | O que corre na região de recuperação | Tipo de site mais próximo |
|---|---|---|
| Cópia de segurança e restauro | Apenas cópias de segurança; a infraestrutura é reimplementada após o evento | Cold site |
| Pilot light | Dados replicados e serviços essenciais ligados; servidores aplicacionais desligados | Cold a warm |
| Warm standby | Uma cópia reduzida, mas totalmente funcional, que pode receber tráfego de imediato | Warm site |
| Hot standby / multi-site ativo/ativo | Capacidade total, em espera (ativo/passivo) ou a servir utilizadores (ativo/ativo) | Hot site |
A AWS considera o multi-site ativo/ativo a abordagem mais complexa e dispendiosa, mas afirma que pode reduzir o tempo de recuperação para perto de zero na maioria dos desastres. Salienta também que a maioria dos clientes que constroem um segundo ambiente completo acaba por o usar em modo ativo/ativo, já que o está a pagar de qualquer forma.
Uma configuração na cloud tem duas vantagens face a uma física. Pode testar o failover sem deslocar pessoas e pode reconstruir todo o ambiente a partir de código se algo divergir. Em contrapartida, paga capacidade total em dois locais, além da transferência de dados para a replicação.
Compensa o custo de um hot site?
Apenas para os sistemas em que o custo da indisponibilidade é superior ao custo de manter um segundo ambiente. Parta de uma análise de impacto no negócio, defina um RTO e um objetivo de ponto de recuperação (RPO) para cada sistema e faça corresponder o tipo de site a esses objetivos. O nosso guia sobre RPO e RTO mostra como os definir.
O NIST faz aqui uma observação útil: um mesmo sistema pode precisar de estratégias diferentes para funções diferentes. O processamento de encomendas pode exigir failover instantâneo, enquanto os relatórios mensais na mesma plataforma podem esperar dias. Uma hierarquização deste tipo mantém reduzida a infraestrutura sempre ligada e a fatura controlada.
Lista de verificação antes de construir um
- Suficientemente longe do site principal para que um único evento regional não afete ambos.
- Capacidade para a carga crítica, não necessariamente para tudo.
- Atraso de replicação monitorizado face ao seu RPO, com alertas.
- Cópias de segurança com recuperação pontual guardadas em separado, para recuperar de corrupção de dados ou de ransomware que a replicação copiaria.
- Controlos de segurança equivalentes aos da produção: identidade, firewalls, registo e cifragem.
- Um runbook de failover com responsáveis identificados e um plano de failback.
- Testes de failover regulares, registados no seu plano de recuperação de desastres.
Como a Opsio pode ajudar
A Opsio desenha e opera recuperação de desastres na cloud na AWS, no Azure e no Google Cloud, desde pilot light até configurações multirregião completas, e testa o failover com a sua equipa. Para a WorkBuster, uma plataforma global de recrutamento em SaaS, construímos o ambiente AWS com MySQL RDS Multi-AZ e escalamento automático, com modelos CloudFormation para que a infraestrutura possa ser reimplementada de forma consistente; leia o caso WorkBuster.
Perguntas frequentes
Qual é a diferença entre um hot site e um cold site?
O primeiro tem equipamento, software e dados atuais prontos e pode assumir rapidamente. O segundo tem apenas espaço, energia e ligações de rede, pelo que os sistemas têm de ser instalados e restaurados a partir de cópias de segurança antes de o trabalho recomeçar.
Com que rapidez pode um hot site assumir as operações?
Tipicamente, em minutos a horas, consoante a atualidade dos dados e o grau de automatização da comutação. Uma configuração ativo/ativo na cloud pode reduzir o tempo de recuperação para perto de zero na maioria das falhas, mas a recuperação de corrupção de dados continua a depender das cópias de segurança.
Um hot site é o mesmo que um site espelhado?
São muito próximos. Um site espelhado executa uma cópia idêntica e continuamente sincronizada da produção. O exemplo do NIST de dois sistemas de produção idênticos, cada um a suportar a carga total, é, na prática, um site espelhado.
Preciso de um hot site se trabalho na cloud?
Não automaticamente. Executar em várias Zonas de Disponibilidade já protege contra a perda de um centro de dados. Um hot standby numa segunda região compensa quando falhas regionais, a regulamentação ou os contratos exigem tempos de recuperação muito curtos.
O que significa "hotsite" em marketing?
Em marketing, sobretudo no Brasil, um "hotsite" é um pequeno site temporário para uma campanha ou lançamento de produto. Nada tem que ver com recuperação de desastres.
Escrito por
Group COO & CISO
Fredrik é o COO e CISO do grupo na Opsio. Concentra-se na excelência operacional, na governação e na segurança da informação, trabalhando em estreita colaboração com as equipas de entrega e de liderança para alinhar tecnologia, risco e resultados de negócio em ambientes de TI complexos. Lidera a prática de segurança da Opsio, incluindo serviços SOC, testes de penetração e quadros de conformidade.
Normas editoriais: Este artigo foi escrito pelo profissional cloud indicado acima. Atualizamo-lo quando a tecnologia ou a regulamentação que aborda muda; as datas desta página indicam a última atualização. A Opsio mantém independência editorial.