Backup VMware e Hyper-V: o que ninguém te conta sobre snapshot de máquina virtual

Mas Maurício, eu já tiro snapshot das minhas VMs toda noite — isso não é backup de máquina virtual?

Essa é, de longe, a frase que mais ouço de técnico de TI quando a conversa chega em ambiente virtualizado. E entendo — faz todo sentido na teoria. O snapshot congela o estado da VM, cria um ponto de retorno, parece seguro…

Até o dia que o storage quebra. Aí o snapshot vai junto, junto com tudo que estava dentro dele.

Vou te explicar a diferença de verdade, como fazer backup VMware (e Hyper-V) do jeito certo, o que é backup agentless, o que significam RTO e RPO em linguagem de gente — e por que VM inteira na nuvem offsite é o único cenário que realmente te deixa dormir tranquilo.

Snapshot e backup de VM: por que são coisas completamente diferentes?

Pra entender, precisa saber o que um snapshot de fato é: ele é um delta de disco armazenado dentro do mesmo storage do host. Quando você tira um snapshot no VMware vSphere ou no Hyper-V, o sistema congela o estado atual da VM e passa a registrar só as diferenças a partir dali. Parece uma cópia — mas não é.

O problema: o snapshot depende completamente da saúde do storage onde ele vive.

Se o datastore falhar, se um ransomware criptografar o host ESXi ou o servidor Hyper-V, se o RAID colapsar, o snapshot vai junto. Você não tem nada. Zero. É como guardar o cofre e a chave sobressalente no mesmo lugar — na hora do assalto, o ladrão leva os dois.

Tem mais: snapshot acumulado degrada a performance da VM. O arquivo de delta cresce, as operações de I/O ficam mais lentas, e o ambiente começa a reclamar. Muitos ambientes que “têm snapshot” na verdade têm snapshots velhos de semanas que ninguém deletou — e o disco está quase cheio.

Backup de máquina virtual é outra história. Veja a diferença:

Resumindo: snapshot é ferramenta de operação (rollback rápido pós-patch, por exemplo). Backup é a sua proteção real.

O que é backup agentless de VMs e por que importa?

Nos primórdios do backup de ambientes virtualizados, a abordagem era instalar um agente dentro de cada VM — igual a um servidor físico. Funcionava, mas gerava sobrecarga, conflitos de versão de SO e um trabalho danado pra gerenciar dezenas de máquinas.

O backup agentless resolve isso de forma elegante: o agente roda no hypervisor, fora das VMs. No VMware vSphere/ESXi, ele usa a VADP (vSphere API for Data Protection). No Hyper-V, a API nativa do Windows Server.

O resultado prático é simples:

• Nenhum software extra dentro das VMs — sem conflito, sem agente pra atualizar em cada máquina.
• VMs novas que você criar no host entram automaticamente na rotina de backup, sem configuração adicional.
• O impacto na performance é mínimo — o processo de cópia conversa com o storage de forma otimizada.
• Funciona mesmo se a VM estiver ligada e em produção (backup a quente).

Pra infraestrutura com dezenas de VMs, isso não é detalhe — é o que torna o backup gerenciável sem virar um emprego de tempo integral.

VMware vSphere/ESXi e Hyper-V: as diferenças práticas no backup

As duas plataformas têm o mesmo conceito de backup agentless via API, mas com algumas particularidades que vale conhecer.

No VMware ESXi/vSphere, o fluxo padrão envolve a criação de um snapshot temporário da VM (só como ponto de consistência de dados — não como backup em si), a leitura dos blocos alterados via CBT (Changed Block Tracking) e a cópia incremental pra o destino. O CBT é o que permite fazer backup incremental eficiente: em vez de copiar o disco inteiro toda vez, o sistema copia só os blocos que mudaram desde o último backup. Economia de tempo e espaço significativa.

No Hyper-V, o mecanismo equivalente se chama RCT (Resilient Change Tracking), disponível a partir do Windows Server 2016. Funciona de forma análoga ao CBT do VMware — rastreia os blocos modificados e alimenta o backup incremental. Para VMs antigas em Hyper-V sem RCT (Windows Server 2012 R2 ou anterior), o backup costuma ser mais lento porque precisa comparar os discos inteiros.

Ambas as plataformas permitem backup consistente com a aplicação quando o VMware Tools ou o Integration Services do Hyper-V está instalado e atualizado dentro da VM — o que garante que o banco de dados ou o Exchange, por exemplo, sejam copiados num estado consistente, sem transação aberta no meio.

Se você tem um banco de dados crítico rodando em VM, vale ler também sobre backup de banco de dados — porque o backup da VM captura o arquivo de dados, mas o backup específico do banco garante consistência transacional e granularidade pra restaurar uma tabela específica.

O que significa restaurar a VM inteira — e quando você vai precisar disso?

Você já imaginou o cenário: o servidor ESXi morre de madrugada, as VMs de produção somem e você tem que reerguer tudo antes do expediente?

É exatamente aí que a diferença entre snapshot e backup real aparece. Com backup de VM completo, você tem duas opções:

Restore completo da VM: você pega o arquivo de backup, aponta pra um host de destino (pode ser o mesmo recuperado ou um host diferente), e a VM volta exatamente como estava — sistema operacional, aplicações, configurações de rede, dados. Tudo. Sem reinstalar nada, sem reconfigurar. A VM sobe e volta a trabalhar.

Restore granular (Item Level Recovery): quando o problema não é o servidor todo, mas um arquivo específico que alguém apagou dentro de uma VM. Boas soluções de backup de VM permitem montar o backup como volume e recuperar um arquivo ou pasta sem restaurar a máquina inteira.

A escolha entre um e outro depende do tipo de incidente. Ransomware no host inteiro? Restore completo de todas as VMs. Arquivo de configuração deletado por engano? Restore granular resolve em minutos.

RTO e RPO: o que esses termos significam no seu dia a dia?

Eu sei que RTO e RPO parecem linguagem de consultoria cara. Mas são duas perguntas simples que qualquer dono de empresa deveria saber responder:

RPO (Recovery Point Objective) — “Quanto de dado eu aceito perder?”

Se o backup roda uma vez por dia, às 23h, e o servidor cai às 17h do dia seguinte, você perdeu 18 horas de trabalho. Esse é o seu RPO: 18 horas. Se 18 horas de perda é inaceitável pro seu negócio, o backup precisa rodar com mais frequência — a cada 4 horas, a cada hora, ou em modo contínuo.

RTO (Recovery Time Objective) — “Quanto tempo a empresa aguenta parada?”

É o tempo máximo que você tem pra reerguer tudo antes de começar a sangrar de verdade: perder cliente, perder contrato, infringir LGPD. Uma VM de produção com disco de 200 GB restaurando de um backup local é muito mais rápida do que restaurar de uma nuvem com link de 100 Mbps.

A combinação de backup agentless + cópia offsite na nuvem resolve os dois: frequência alta de backup (RPO curto) e cópia local pra restore rápido em caso de emergência (RTO curto). O dado que vai pra nuvem é a sua proteção contra o pior cenário — incêndio, enchente, ransomware que destruiu o storage físico.

Na enchente do Rio Grande do Sul em maio de 2024, a gente recolocou 9 clientes trabalhando de casa, em dias, porque os dados deles estavam na nuvem e fora do alcance da água. Sem cópia offsite, a história teria sido outra.

Por que o backup de VM precisa ir pra fora do datacenter — obrigatoriamente?

Tem uma armadilha comum em ambientes de TI bem estruturados: o backup vai pra um NAS dedicado dentro do mesmo rack do servidor. É melhor que nada. Mas continua vulnerável a incêndio, roubo, enchente e, principalmente, a um ransomware que varre a rede e criptografa tudo que encontra — incluindo o compartilhamento de rede onde ficam os backups.

Backup de VM de verdade exige cópia offsite. Aqui na WSpeed, a cópia vai criptografada pra nuvem especializada em backup — usamos o Backblaze B2 como primário, por ser mais econômico e focado especificamente em armazenamento de backup, e o AWS S3 como opção complementar. Os dados saem do seu ambiente já cifrados, chegam na nuvem cifrados, e só você tem a chave.

Isso é o que garante que, mesmo que o servidor físico seja destruído completamente, a restauração da VM é possível — e o RTO volta a ser uma questão de horas, não de “começa tudo do zero”.

Se você gerencia TI de terceiros e quer entender como estruturar isso pra seus clientes, dá uma olhada nas nossas soluções para empresas de TI — tem contexto específico pra quem é MSP ou suporte local.

Como funciona o WSpeed VM Backup na prática?

A nossa solução de backup de máquinas virtuais cobre VMware vSphere/ESXi e Hyper-V com abordagem agentless — instalação no host, sem tocar nas VMs. O fluxo é:

1. Cadastro das VMs no console — você define quais máquinas proteger, a frequência e a retenção.
2. Backup incremental automático via CBT (VMware) ou RCT (Hyper-V) — só os blocos que mudaram, sem copiar tudo do zero toda vez.
3. Cópia offsite criptografada — os dados saem do seu ambiente e chegam na nuvem sem trafegar em texto claro.
4. Restore completo ou granular — você escolhe restaurar a VM inteira ou só arquivos específicos de dentro dela, pelo mesmo console.
5. Relatório e alerta — você sabe se o backup rodou, quanto tempo levou e se houve erro, sem precisar entrar no console pra conferir.

E tem o que mais importa: garantia em contrato. Ou a gente recupera as suas VMs, ou arca com a multa financeira já definida no acordo. Não é promessa de marketing — está no papel. Porque de nada adianta backup se você não pode confiar.

Se você ainda tem dúvida sobre o que é backup antes de entrar no mundo de virtualização, recomendo ler esse artigo antes — ele explica a base da regra 3-2-1 que também vale pra VM.

E aí: você já testou o restore de uma VM no seu ambiente hoje? Comente abaixo — quero saber como tá o nível de proteção por aí.

Abraço e até o próximo artigo ou vídeo.