Alta disponibilidade resolve a perda de um nó. Backup resolve a perda de uma VM. Existe um terceiro cenário que quase ninguém planeja e que, quando acontece, revela tudo que faltava: a perda do cluster inteiro.
Incêndio, enchente, perda de acesso ao datacenter, ransomware que alcançou o ambiente de gestão, erro humano catastrófico, falha simultânea de storage. São eventos raros — e a diferença entre a empresa que atravessa e a que não atravessa é o que estava guardado fora do cluster antes do evento.
A pergunta que define tudo
Se os seus nós desaparecerem agora, o que você tem para reconstruir?
Se a resposta incluir "tem um backup lá" e a frase seguinte for "mas ele está no PBS que fica no mesmo rack", o plano não existe. Este artigo é sobre o que precisa existir e em que ordem usá-lo.
O que precisa estar fora do cluster
Backup de VM é necessário e não é suficiente. A lista completa:
| Item | Por que é necessário | Onde guardar |
|---|---|---|
| Backup das VMs | O dado e as aplicações | Fora do local, cifrado |
| Chave de cifragem do backup | Sem ela o backup é inútil | Cofre, fora do cluster |
| Configuração das VMs | Recursos, rede, discos de cada uma | Repositório versionado |
| Configuração do cluster | Nomes, nós, storages | Repositório versionado |
| Desenho da rede | VLANs, bridges, bonding, endereços | Documento e código |
| Regras de firewall | Segurança do ambiente novo | Repositório versionado |
| Usuários, papéis, pools | Quem pode o quê | Repositório versionado |
| Configuração do storage | Ceph, ZFS, storages externos | Documento e código |
| Inventário de licenças | Windows, aplicações, chaves | Cofre |
| Contatos e contratos | Fornecedores, datacenter, suporte | Fora do ambiente |
| O procedimento em si | O roteiro de reconstrução | Impresso e fora do ambiente |
Os dois últimos itens são os mais esquecidos e os mais críticos. Um plano de recuperação que só existe na intranet do ambiente perdido não é um plano. E o telefone do datacenter guardado no sistema que caiu também não ajuda.
A ordem de reconstrução
A sequência importa, porque cada etapa depende da anterior:
Fase 1 — Decisão e comunicação
- Declarar o desastre. Deve haver uma pessoa com autoridade para isso, definida antes.
- Acionar o plano e reunir a equipe.
- Comunicar clientes e áreas internas, com o modelo de mensagem já pronto.
Fase 2 — Infraestrutura
- Obter hardware: equipamento reserva, contrato de contingência, aluguel de servidores dedicados, ou espaço em outro datacenter.
- Montar a rede básica: conectividade, endereçamento, acesso à internet.
- Instalar o Proxmox nos nós.
- Formar o cluster e estabelecer o quórum.
- Reconstruir o storage conforme o desenho documentado.
Fase 3 — Dados
- Conectar o destino do backup e a chave de cifragem.
- Restaurar por prioridade, não em ordem alfabética.
- Reconfigurar a rede das VMs conforme o inventário.
- Validar cada VM restaurada antes de liberar.
Fase 4 — Retomada
- Ajustar DNS e roteamento para o ambiente novo.
- Liberar por ondas, começando pelo mais crítico.
- Reconstruir usuários, permissões e firewall.
- Reestabelecer backup no ambiente novo — antes de tudo estar completo.
- Monitorar intensamente.
O passo 16 merece destaque: é comum deixar o backup por último, e isso significa operar dias sem proteção logo depois de um desastre. Reestabeleça a proteção assim que o primeiro conjunto de VMs estiver de pé.
A priorização, decidida antes
Restaurar na ordem errada custa horas caras. A lista de prioridades precisa existir antes, revisada com as áreas de negócio, com quatro níveis:
- Crítico — sem isso a empresa para. Tipicamente: autenticação, banco principal, o sistema que gera receita.
- Importante — precisa voltar no mesmo dia.
- Normal — pode esperar alguns dias.
- Adiável — volta por último; parte pode nem voltar.
Um cuidado frequentemente negligenciado: dependências. A aplicação crítica não sobe sem o banco, que não sobe sem o DNS interno, que não sobe sem o controlador de domínio. Mapeie a cadeia e restaure na ordem das dependências, não na ordem da importância percebida.
O RTO real, e por que ele surpreende
A soma dos tempos costuma ser bem maior do que a estimativa intuitiva:
| Etapa | Ordem de grandeza |
|---|---|
| Decidir e acionar | Horas |
| Obter hardware | Horas a semanas |
| Montar rede e instalar | Horas |
| Restaurar dados | Depende do volume e da banda |
| Validar e liberar | Horas |
A etapa que domina é a restauração, e ela é limitada por banda, não por capacidade. Restaurar 10 TB a partir de uma cópia externa, por um link de 1 Gbps, leva algo em torno de um dia inteiro — na velocidade teórica máxima, sem concorrência.
Faça essa conta agora. Volume do backup dividido pela banda do destino, com folga. O resultado é o piso do seu RTO, e ele costuma ser incompatível com o que o negócio imagina.
E o item mais incerto é a obtenção de hardware. Sem contrato de contingência ou equipamento reserva, você depende do mercado no pior momento possível.
Como reduzir o RTO
Se a conta não fecha, existem caminhos — em ordem crescente de custo:
- Cópia do backup mais próxima do local de recuperação, para não atravessar link estreito.
- Contrato de contingência com fornecedor de hardware, com prazo definido.
- Nós em espera fria em outro local, desligados, prontos para receber restauração.
- Replicação assíncrona das VMs críticas para um segundo local. Reduz drasticamente o RTO das mais importantes, com custo proporcional.
- Cluster secundário em espera morna, com as VMs críticas replicadas e prontas para ligar.
A estratégia que costuma equilibrar custo e risco: replicação das VMs críticas para um segundo local, e restauração por backup para todo o resto. Você protege o que gera receita com RTO curto, sem pagar por um ambiente espelho completo.
O exercício que prova o plano
Plano não testado é ficção. Três níveis de exercício, em ordem de esforço:
Leitura em mesa. A equipe percorre o procedimento em uma reunião, discutindo cada passo. Barato, revela lacunas óbvias, e deve ser feito uma vez por semestre.
Recuperação parcial. Restaurar as VMs críticas em ambiente isolado, validar que sobem e funcionam, cronometrar. Uma vez por ano, no mínimo.
Exercício completo. Reconstruir o ambiente inteiro em infraestrutura separada. Caro, e é o único que produz o número real.
O que cada exercício sempre revela, independentemente do nível: a chave de cifragem que ninguém sabia onde estava, a documentação desatualizada, a dependência não mapeada, a licença que exige reativação e o tempo que é o dobro do estimado.
Um detalhe importante: o exercício precisa ser feito por quem vai executar, não por quem escreveu o plano. Se só o autor consegue seguir o procedimento, ele não está pronto.
O elemento humano
O que mais falha em desastre real não é técnico:
- Quem declara o desastre? Sem autoridade definida, perde-se tempo em consulta.
- Quem faz o quê? Papéis atribuídos antes, com substitutos.
- Como a equipe se comunica se os sistemas internos caíram? Canal alternativo combinado.
- Quem fala com clientes? Uma pessoa, com mensagem preparada.
- As pessoas estão disponíveis? Desastre não escolhe horário. Contatos alternativos, e reconhecimento de que ninguém opera bem por 20 horas seguidas — planeje revezamento.
Erros comuns
- Backup no mesmo datacenter, sem cópia externa.
- Chave de cifragem guardada dentro do ambiente que se perdeu.
- Nenhuma documentação de rede, storage e configuração fora do cluster.
- Procedimento de recuperação armazenado no ambiente perdido.
- Nenhuma priorização definida, restaurando na ordem errada.
- Dependências não mapeadas, com a aplicação crítica esperando o DNS.
- Não calcular o RTO real limitado pela banda.
- Nenhum plano para obter hardware.
- Deixar o backup do ambiente novo por último.
- Nunca ter restaurado nada de verdade.
- Exercício feito só pelo autor do plano.
- Nenhuma autoridade definida para declarar o desastre.
- Nenhum canal de comunicação alternativo.
- Plano escrito uma vez e nunca revisado após mudanças no ambiente.
A conclusão desconfortável
A maioria das empresas descobre as lacunas deste artigo durante o desastre. As que atravessam bem descobriram durante um exercício, com calma, em uma tarde de terça-feira.
A diferença de custo entre as duas situações é de várias ordens de grandeza — e o exercício custa uma tarde.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, construímos e testamos planos de recuperação completos: inventário do que precisa estar fora do cluster e onde guardá-lo, configuração versionada de cluster, rede, storage, firewall e permissões, cópia externa cifrada com guarda de chave independente, priorização com mapa de dependências levantado junto às áreas de negócio, cálculo do RTO real a partir do volume e da banda, e a estratégia de redução — replicação das VMs críticas para segundo local, quando a conta não fecha. E conduzimos o exercício de recuperação com a sua equipe, cronometrado, para que o número deixe de ser estimativa.
Se o seu datacenter ficasse inacessível hoje, quanto tempo levaria para voltar? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.