Se uma máquina virtual caiu, foi apagada ou o datastore corrompeu, o caminho de volta depende do que existia antes. Aqui está o que dá para fazer em cada cenário — e como o SERVER BACKUP devolve a VM inteira em minutos, em vez de horas.
A maior parte das perdas definitivas acontece nos primeiros minutos, tentando consertar no lugar. Se você é o técnico chamado para resolver, comece por aqui.
Se o VMDK sumiu ou o datastore está com erro, não recrie a VM, não formate e não rode reparo em cima. Cada escrita nova reduz a chance de recuperar o que ainda está lá. Desligue o que estiver gravando naquele volume.
Snapshot do vSphere não é backup, mas em caso de alteração recente ele pode ser o caminho mais rápido. Veja em Snapshot Manager se existe um ponto anterior ao incidente — e confira o espaço livre no datastore antes de reverter.
Se existe backup, a pergunta certa não é “tem backup?”, é “de quando é e já foi testado?”. Backup nunca restaurado é uma hipótese, não uma garantia. Confirme a data e a integridade antes de prometer prazo ao cliente.
Se não existe cópia nenhuma, o caminho passa a ser perícia de dados em nível de disco — trabalho especializado, caro e sem garantia. É exatamente o cenário que um backup gerenciado evita.
Com a VM protegida pelo SERVER BACKUP, a recuperação não é uma coisa só. Você escolhe o escopo conforme a urgência, e o tempo de parada muda de horas para minutos.
O caminho mais rápido quando o negócio está parado. A máquina virtual sobe a partir da própria cópia e volta a operar em minutos, enquanto a restauração definitiva acontece em segundo plano. Serve para colocar o sistema de pé primeiro e organizar o resto depois.
Devolve a máquina virtual completa — disco, configuração e estado — para o host original ou para outro host. É o caminho quando o hardware foi perdido, quando a VM precisa voltar para um ESXi diferente, ou quando você quer o ambiente exatamente como estava.
Restauração granular: alguém apagou uma pasta, um documento foi sobrescrito, uma base foi corrompida. Você entra no conteúdo da cópia e tira só o que precisa, sem restaurar a máquina toda nem parar quem está trabalhando.
Antes de jogar de volta em produção — ou para provar ao cliente que a cópia presta. É o mesmo procedimento do nosso Restore Drill: sobe em ambiente separado, valida a integridade e gera evidência.
Restaurar sozinho é possível. O que costuma faltar às três da manhã não é o botão — é saber que a cópia é boa, saber qual ponto escolher e ter alguém do outro lado enquanto o cliente liga a cada dez minutos.
No modelo gerenciado, o monitoramento é 24/7 por pessoas, a cópia é testada periodicamente e a restauração é acompanhada por quem já fez isso antes. Você não recebe um chamado com número de protocolo — você fala com técnico.
A velocidade da volta é decidida lá atrás, na hora de copiar. No VMware, isso significa trabalhar a partir do host — e não de dentro de cada convidado.
A cópia é feita direto do host vSphere / ESXi. Nada é instalado dentro de cada máquina virtual — o que reduz manutenção e permite restaurar a VM como um todo.
Usando o Changed Block Tracking do próprio VMware, só os blocos alterados sobem. Swap e blocos deletados ficam de fora — janelas de backup curtas e menos banda consumida.
Quando a VM roda Exchange, SQL Server ou Oracle, o snapshot é coordenado em nível de aplicação. Sem isso, a VM volta — mas a base pode voltar inconsistente.
| Cenário no VMware | Caminho recomendado |
|---|---|
| VM deletada por engano | Restauração da VM inteira para o host original. Se a pressa for grande, ligar direto do backup e restaurar em seguida. |
| Datastore corrompido ou host perdido | Restaurar para host alternativo. É por isso que a cópia mora fora do ambiente de produção. |
| Ransomware cifrou as VMs | Voltar a um ponto anterior à infecção. Com storage imutável contratado, a cópia não pode ser cifrada nem apagada pelo atacante. |
| Arquivo apagado dentro da VM | Restauração granular, sem parar a máquina virtual nem os usuários. |
| Snapshot travado / cadeia quebrada | Restaurar a VM a partir da cópia, em vez de tentar consolidar uma cadeia inconsistente. |
| Migrar a VM para outro servidor | Restauração em host alternativo — o mesmo recurso do desastre, usado a favor. |
O mesmo padrão de proteção da bringback, aplicado ao ambiente VMware.
Dados cifrados em trânsito e em repouso. A chave é sua — só você acessa o conteúdo.
Com storage imutável (object lock / WORM) contratado, o dado não pode ser deletado, alterado ou criptografado.
Verificação periódica com correção: o dado é conferido para garantir que está 100% restaurável.
Elimina blocos repetidos e comprime — menos espaço, menos banda, mais retenção pelo mesmo custo.
Replicado em 2 data centers Tier-III em estados diferentes, de 3 que operamos no Brasil.
Políticas diária, semanal, mensal e anual, com versionamento — do jeito que a auditoria pede.
* A imutabilidade depende do tipo de storage contratado (armazenamento imutável / object lock / WORM). É uma característica da infraestrutura de armazenamento, definida na contratação.
Todo backup é monitorado 24/7 na Plataforma iCOM e passa por testes de recuperação (Restore Drill): periodicamente, os dados são restaurados em ambiente isolado, a integridade é validada e vira relatório. É esse relatório que você mostra quando o cliente — ou a auditoria — pergunta se o dado volta mesmo.
Depende do que aconteceu. Se a VM foi removida do inventário mas os arquivos ainda estão no datastore, ela pode ser registrada de volta. Se o VMDK foi apagado ou o datastore corrompeu, sem cópia o caminho é perícia em nível de disco — caro, demorado e sem garantia. Por isso a primeira regra é parar de escrever no volume.
Não. Snapshot depende do mesmo datastore e da mesma cadeia de discos: se o volume falhar ou o ransomware chegar, o snapshot vai junto. Ele resolve um rollback rápido de alteração recente — não uma perda real.
Ligando direto do backup, a VM pode voltar a operar em minutos, enquanto a restauração definitiva acontece. Uma restauração completa depende do tamanho do disco e do link disponível.
Sim. A restauração pode ir para o host original ou para um host alternativo — que é o caminho quando o hardware foi perdido ou quando você está migrando o ambiente.
Sim, com restauração granular — sem precisar restaurar a máquina virtual inteira e sem parar quem está usando o sistema.
Não. O SERVER BACKUP trabalha em nível de host vSphere / ESXi, protegendo as máquinas virtuais sem agente interno.
Com storage imutável contratado (object lock / WORM), a cópia não pode ser alterada nem apagada dentro do período de retenção — nem por você, nem pelo atacante. Restaura-se um ponto anterior à infecção.
Se você é o técnico que apaga o incêndio quando o cliente liga desesperado, existe um jeito de essa ligação não acontecer mais — e de virar receita recorrente sua. Manda o cenário no WhatsApp: quantos hosts, quantas VMs, o que precisa proteger. A resposta vem em linguagem de técnico, sem ligação e sem roteiro comercial.