Backup de Máquinas Virtuais: VMware e Hyper-V

Por que backup de máquina virtual é diferente de backup de servidor físico

Quando uma empresa vira sua infraestrutura para virtualização — VMware vSphere ou Microsoft Hyper-V — muita coisa fica mais simples: provisionamento de servidores em minutos, consolidação de hardware, migração a quente entre hosts. Mas o backup, ao contrário do que se imagina, fica mais complexo. Não porque a tecnologia seja pior, e sim porque as regras mudaram completamente. Continuar tratando uma VM como se fosse um servidor físico com agente instalado dentro dela é o erro mais comum que encontramos em ambientes de clientes novos.

Um servidor físico tem um sistema operacional que enxerga o disco diretamente. Já a máquina virtual roda sobre um hipervisor que abstrai o armazenamento em arquivos — VMDK no VMware, VHDX no Hyper-V. Esses arquivos podem ter centenas de gigabytes e mudam constantemente enquanto o sistema opera. Copiar um VMDK "quente", com a VM ligada, sem coordenação com o hipervisor, produz um arquivo corrompido: o equivalente digital a fotografar alguém correndo com o obturador aberto por dez minutos.

A boa notícia é que tanto VMware quanto Hyper-V oferecem APIs específicas para backup — vSphere Storage APIs for Data Protection (VADP) e Hyper-V VSS Writer / WMI Virtualization API, respectivamente. Uma solução de backup moderna conversa com o hipervisor, congela o estado da VM por alguns segundos, copia os blocos e libera. O resultado é um backup consistente, sem agente dentro da VM e sem downtime perceptível para o usuário.

Snapshot consistente: o que significa "consistente" de verdade

O termo snapshot é usado de forma ambígua no mercado, e essa ambiguidade custa caro na hora do restore. Existem três níveis de consistência, e a diferença entre eles determina se o seu banco de dados vai subir ou não depois de um desastre.

• Crash-consistent — equivale a puxar o cabo de energia do servidor e ligar de novo. O sistema de arquivos pode precisar de verificação, e transações em memória são perdidas. Serve para servidores de arquivos simples, nunca para bancos de dados.
• File-system consistent — o VSS (Volume Shadow Copy Service) no Windows, ou fsfreeze no Linux, garante que o sistema de arquivos esteja em estado íntegro. Melhor, mas ainda não resolve aplicações transacionais.
• Application-consistent — o backup aciona os VSS Writers da aplicação (SQL Server, Exchange, Active Directory) que fazem flush dos buffers em memória para disco e truncam logs de transação antes do snapshot. É o único nível aceitável para cargas críticas.

No VMware, isso depende do VMware Tools instalado e atualizado dentro do guest, com o serviço VSS habilitado. No Hyper-V, depende dos Integration Services (nos sistemas modernos, entregues via Windows Update) e do modo de backup escolhido: o Hyper-V oferece backup por saved state — que suspende brevemente a VM e é crash-consistent — ou por child partition snapshot, que usa VSS dentro da VM e entrega consistência de aplicação. Vale conferir qual dos dois seu ambiente está usando de fato, porque a queda para saved state acontece silenciosamente quando o Integration Services está desatualizado.

Backup que não é application-consistent para banco de dados não é backup: é uma aposta. Ele pode restaurar perfeitamente em noventa por cento dos testes e falhar exatamente no dia em que você precisa dele.

CBT e RCT: por que backup incremental de VM é rápido

Se toda janela de backup precisasse copiar o VMDK inteiro, uma VM de 500 GB tornaria backup diário inviável em qualquer link ou storage. É aqui que entra o rastreamento de blocos alterados — Changed Block Tracking (CBT) no VMware e Resilient Change Tracking (RCT) no Hyper-V a partir do 2016.

O mecanismo é elegante: o hipervisor mantém um mapa de quais blocos do disco virtual foram modificados desde o último ponto de referência. Quando o job de backup roda, ele pergunta ao hipervisor "o que mudou desde o backup de ontem?" e recebe uma lista de setores. Em vez de ler 500 GB, lê talvez 8 GB. Uma janela que levaria seis horas cai para vinte minutos, e o impacto em I/O no storage de produção despenca.

Na prática, CBT e RCT têm armadilhas conhecidas que merecem atenção operacional:

1. CBT pode ser corrompido por eventos como expansão de disco a quente, migração de storage ou falhas de host. Quando isso ocorre, o backup silenciosamente volta a ler tudo — ou, pior, gera incrementais incompletos. Monitore a duração dos jobs: um incremental que de repente dura como um full é sinal de reset de CBT.
2. Snapshots manuais esquecidos no ambiente VMware fazem o delta crescer indefinidamente e degradam a performance da VM. Auditoria periódica de snapshots órfãos é obrigatória.
3. RCT no Hyper-V exige que os checkpoints sejam do tipo produção e que o volume esteja em ReFS ou NTFS com configuração adequada — em cluster CSV há particularidades adicionais.
4. Backup incremental eterno (forever incremental) é eficiente em espaço, mas cria uma cadeia longa de dependência. Um bloco corrompido no meio da cadeia compromete todos os pontos posteriores. Faça verificação de integridade periódica e mantenha fulls sintéticos.

Replicação não substitui backup — e backup não substitui replicação

Essa é provavelmente a confusão conceitual mais cara em projetos de continuidade. Replicação de máquinas virtuais mantém uma cópia da VM em outro host ou site, atualizada continuamente ou em intervalos curtos. VMware oferece vSphere Replication; Hyper-V oferece Hyper-V Replica nativo, com replica primária e opcionalmente uma extended replica em terceiro site. O objetivo da replicação é RTO baixo: em caso de perda do site principal, você liga a réplica em minutos.

O problema é que replicação propaga erros com a mesma eficiência com que propaga dados legítimos. Ransomware que criptografa a VM de produção terá os blocos criptografados replicados para o destino em questão de minutos. Exclusão acidental de uma tabela, corrupção de banco, atualização mal aplicada — tudo isso viaja para a réplica. Replicação protege contra falha de hardware e de site. Não protege contra erro humano nem contra ataque.

Backup, por outro lado, mantém pontos de restauração no tempo. Você pode voltar para ontem, para a semana passada, para antes do incidente. É o que salva no cenário de ransomware — desde que os backups estejam fora do alcance do atacante. Daí a regra prática que sempre recomendamos, uma evolução do clássico 3-2-1:

• 3 cópias dos dados
• 2 mídias ou plataformas diferentes
• 1 cópia off-site
• 1 cópia imutável ou air-gapped (object lock, fita, repositório hardened)
• 0 erros na verificação de restore

Repositórios de backup ingressados no mesmo domínio Active Directory da produção são um alvo clássico: comprometido o domínio, comprometido o backup. Repositório de backup deve ter credencial isolada, autenticação independente e, sempre que possível, imutabilidade no nível do storage.

Boas práticas operacionais para VMware e Hyper-V

Tecnologia definida, o que separa um ambiente protegido de um ambiente com falsa sensação de segurança é a disciplina operacional. Alguns pontos que aplicamos em todo projeto de proteção de VMs:

Dimensione a janela pelo I/O, não pelo relógio. Backup de dezenas de VMs simultâneas satura o datastore e degrada produção. Escalone jobs por criticidade e monitore latência de disco durante a janela. No VMware, prefira transporte HotAdd ou NBD conforme a topologia; em ambientes com storage compatível, o transporte Direct SAN elimina o tráfego do host.

Teste restore de verdade, com frequência. Backup que nunca foi restaurado é hipótese. Restore granular de arquivo, restore de VM completa em rede isolada e verificação automática de boot devem estar no calendário mensal. Documente RTO e RPO reais medidos, não os prometidos no contrato.

Alinhe retenção a requisito de negócio e legal. Reter tudo por sete anos é caro e frequentemente desnecessário; reter trinta dias pode violar obrigação fiscal ou dificultar detecção de ransomware dormente, que costuma ficar semanas no ambiente antes de disparar. Defina políticas por tipo de carga.

Monitore e alerte sobre falhas. Job que falha silenciosamente por semanas é comum em ambientes sem observabilidade. Alerta de falha precisa chegar a uma pessoa responsável, com escalonamento, e a taxa de sucesso deve ser um indicador acompanhado mês a mês.

Proteja também a camada de gestão. vCenter e o host Hyper-V precisam ter backup próprio — restaurar VMs sem a plataforma de gestão é possível, mas transforma um incidente de duas horas em um projeto de dois dias.

Como a Duk estrutura proteção de ambientes virtualizados

Na Duk Informática & Cloud, backup de máquinas virtuais não é um produto avulso: faz parte do desenho de continuidade do cliente. Ao longo de mais de 18 anos atendendo empresas, e com mais de 550 clientes na base, aprendemos que o valor não está na ferramenta instalada, e sim no processo que garante que ela funcione no dia ruim.

Nosso trabalho começa com levantamento de criticidade: quais VMs sustentam receita, quais suportam operação, quais são acessórias. A partir disso definimos RPO e RTO por grupo, escolhemos o modelo — backup local para restore rápido, cópia off-site em nosso data center próprio em Alphaville, e camada imutável contra ransomware — e configuramos consistência de aplicação onde há banco de dados, com validação de VSS Writers. Como Microsoft Gold Partner, temos profundidade especial em cargas Hyper-V, SQL Server, Exchange e Microsoft 365, integrando a proteção de VMs com a proteção de dados em nuvem.

Depois vem a parte que raramente aparece em proposta comercial, mas que é onde o serviço realmente se prova: monitoramento diário dos jobs, testes de restore agendados com evidência documentada, revisão periódica de retenção e capacidade, e suporte 24/7 com SLA para o momento em que o telefone toca fora do horário. Se você tem um ambiente VMware ou Hyper-V e não consegue responder com segurança "quando foi o último restore testado?", vale conversar — esse costuma ser o melhor ponto de partida para uma avaliação.