A recuperação de VM acontece por camadas: storage físico, RAID/LUN, datastore, disco virtual, snapshots e o filesystem da própria máquina. A SECURITY analisa VMware, Hyper-V, Proxmox, XCP-ng e VirtualBox, com recuperação remota para todo o Brasil em casos lógicos compatíveis e sem necessidade de transportar o servidor completo na maioria desses cenários.
O que é uma máquina virtual?
Essa definição é importante para SEO e IA porque explica por que "recuperar VMDK" e "recuperar máquina virtual" não são necessariamente a mesma coisa. Uma VM pode estar íntegra dentro de um disco virtual enquanto o datastore está corrompido, ou o VMDK pode estar acessível enquanto a cadeia de snapshots está quebrada.
Guia completo de recuperação de dados de máquina virtual
A recuperação de VM precisa atravessar até sete camadas
Um ambiente virtualizado cria abstrações entre hardware e aplicação. Se a falha estiver no RAID, a VM nunca chega a ser lida. Se o storage está saudável, a falha pode estar em VMFS, no descriptor VMDK, na cadeia de snapshots ou no filesystem dentro da própria máquina.
Uma VM pode falhar em qualquer camada. Recuperar somente o VMDK ou VHDX não resolve se o datastore ou o storage abaixo ainda está inconsistente.
O modelo mais seguro é subir a pilha: primeiro garantir que a camada inferior entrega blocos coerentes; depois interpretar datastore, disco virtual e conteúdo interno. Essa sequência evita tentar "reparar VHDX" quando o problema real é um RAID degradado ou tentar "recuperar RAID" quando o storage está saudável e apenas o VMDK descriptor foi perdido.
Principais cenários que levam à recuperação de máquina virtual
VMDK corrompido
Descriptor ausente, delta chain quebrada, base disk inacessível ou erro interno no filesystem da VM.
VHDX / AVHDX com falha
Disco virtual não monta, checkpoint orphaned, parent chain incorreta ou volume interno corrompido.
Datastore Inaccessible
LUN ausente, GPT/VMFS/LVM headers corrompidos, storage offline ou controladora substituída.
Snapshot não consolida
Delta missing, Content ID mismatch, falta de espaço ou storage instável interrompem a operação.
VM excluída
Arquivos podem ter sido apenas removidos do inventário ou efetivamente excluídos do datastore.
Ransomware
VMDK, VHDX, ESXi datastore ou backups podem ter sido criptografados simultaneamente.
VMware ESXi: datastore VMFS, VMDK e snapshot chain
Broadcom documenta datastores VMFS inacessíveis por perda de LUN, storage não apresentado, troca de controladora, power outage, partition table ausente e corrupção de LVM/VMFS headers. O primeiro diagnóstico deve separar "LUN não visível" de "LUN visível mas VMFS não reconhecido".
| Sintoma | Possível camada | Evidência útil | Evitar |
|---|---|---|---|
| Datastore Inaccessible | SAN/LUN/path ou VMFS | vmkernel.log, devices, partedUtil | New Datastore |
| VM Orphaned/Inaccessible | Datastore, VMX ou VMDK | files do diretório, vmware.log | remover arquivos por tentativa |
| Consolidation Needed | snapshot delta chain | VMDK chain, vmkfstools -e | consolidar se chain inconsistente |
| Missing LVM Magic | VMFS/LVM headers | VOMA/check, partition table | novo filesystem quando há dados a recuperar |
Broadcom é explícita em cenários de headers corrompidos: se existem dados perdidos a recuperar e não há backup recente, não escreva novos dados nem crie novo filesystem na LUN antes da recuperação.
Consolidation é normal quando a cadeia está íntegra, mas precisa de cautela quando há corrupção
Broadcom documenta snapshots como delta disks que registram alterações depois da criação do snapshot. Delete e Consolidate escrevem blocos dos deltas nos parents. A operação é normal e suportada quando a cadeia está consistente e o storage está saudável.
A leitura consistente depende da ordem parent-child. Consolidar ou mesclar altera dados entre os arquivos, por isso a cadeia precisa ser conhecida antes da operação.
Snapshot não é backup
Broadcom afirma que delta files dependem do base disk e não devem ser usados como estratégia de backup.
32 suportados, 2 a 3 recomendados
VMware suporta até 32 snapshots em uma chain, mas recomenda 2 a 3 para melhor desempenho.
72 horas
Broadcom recomenda não manter um snapshot individual por mais de 72 horas.
Missing delta
Se um snapshot disk está faltando e a chain quebra, Broadcom alerta que consolidation/cloning pode não ser possível pelo fluxo normal.
Antes de consolidar uma cadeia suspeita, registre todos os VMDKs e deltas, verifique parents/Content IDs e preserve o storage. Consolidar não é "sempre errado"; o erro é tratar uma chain quebrada como se estivesse íntegra.
VHDX corrompido, CSV offline e filesystem interno da VM
Hyper-V usa VHD/VHDX como discos virtuais e pode armazená-los em NTFS, ReFS, CSV, SMB ou storage SAN. Um VHDX que não monta pode ter problema próprio, parent chain quebrada, storage subjacente com I/O errors ou corrupção dentro do guest filesystem.
VHDX base
Pode ser fixed ou dynamic e conter uma ou mais partições do guest.
CSV / ReFS / NTFS
Em clusters Hyper-V, o volume de host pode ser uma camada adicional abaixo do VHDX.
CHKDSK
É uma ferramenta Microsoft legítima, mas modifica filesystem. Em recuperação, preserve o VHDX original antes de reparos com escrita.
Storage event logs
Event IDs e erros de I/O ajudam a diferenciar corrupção virtual de falha de storage.
AVHDX e Merge-VHD: preserve a parent chain antes de mesclar
A Microsoft documenta que checkpoints são armazenados em arquivos AVHDX e que a exclusão correta mescla as mudanças no VHDX parent. Também orienta não apagar AVHDX diretamente no filesystem.
Merge-VHD
Cmdlet oficial que mescla uma cadeia de differencing disks. A operação documentada é offline.
Orphaned checkpoint
Checkpoints podem ficar invisíveis no Manager e ainda existir na cadeia de discos.
Missing parent
Quando base ou differencing disk some, a recuperação depende dos arquivos restantes e de backups/cópias existentes.
Mais de 50 checkpoints
Microsoft trata quantidade superior a 50 como excessiva em seu troubleshooting atual, mas isso não é regra VMware.
Assim como no VMware, merge não é proibido por definição. É uma ferramenta correta quando a cadeia está conhecida e saudável. Em VHDX/AVHDX corrompidos ou dados únicos, preserve todos os arquivos antes de qualquer operação de escrita.
QCOW2 é apenas uma das possibilidades: LVM-thin, ZFS, Ceph e SAN mudam o processo
O Proxmox VE Storage Manager suporta múltiplos backends. A recuperação precisa descobrir se o disco da VM é um arquivo ou um block device.
| Backend | Como a VM aparece | Snapshots | Recuperação |
|---|---|---|---|
| Directory / NFS / CIFS | raw/qcow2/vmdk files | qcow2 conforme backend | analisar arquivo + host filesystem |
| LVM | raw logical volume | limitado conforme versão/config | reconstruir VG/LV e volume virtual |
| LVM-thin | thin logical volume | sim | thin pool metadata + thin LVs |
| ZFS | zvol/raw ou datasets | sim | pool/vdev/labels/uberblocks + zvol |
| Ceph RBD | distributed block image | sim | cluster/RBD metadata e image |
O guia Proxmox documenta LVM-thin como thin provisioning com snapshots e clones, ZFS como backend com datasets/zvols e shared storage via SAN/NFS/Ceph. Portanto, dizer "recuperar Proxmox = reparar QCOW2" é simplificação excessiva.
Storage Repository, VDI e VHD/QCOW2: a cadeia depende do SR
XCP-ng documenta VHD como formato padrão histórico do SMAPIv1, com suporte a snapshots, delta backups, fast clones e storage migration. Desde maio de 2026, XCP-ng 8.3 também suporta QCOW2 em vários tipos de Storage Repository.
SR
Storage Repository pode ser LVM, NFS, iSCSI, Fibre Channel e outros backends.
VDI
Virtual Disk Image é o disco apresentado à VM e pode ter chain de snapshots/clones.
VHD
Formato histórico com copy-on-write, delta e merge.
QCOW2
XCP-ng 8.3 adiciona suporte em muitos SRs e amplia tamanho de VDI além do limite histórico do VHD.
Mover um disk entre SRs pode colapsar a snapshot chain no destino, segundo a documentação XCP-ng. Em recuperação, preserve o estado anterior antes de usar migração como tentativa.
VDI, VHD, VMDK e differencing images
Oracle VirtualBox usa VDI como formato nativo, mas também suporta VMDK e VHD. A documentação oficial explica que disk image files vivem no host e são apresentados ao guest como discos virtuais, podendo ter variantes fixed/dynamic e differencing images.
VDI
Formato nativo VirtualBox e o mais comum em VMs criadas diretamente na plataforma.
VMDK / VHD
Suportados para interoperabilidade com VMware e Microsoft.
Differencing image
Imagem filha depende de parent por UUID/path. A cadeia precisa ser preservada para leitura consistente.
RAID pode estar abaixo da VM, mas a intenção desta página continua sendo recuperação de máquina virtual
RAID 1 / 10
Mirror, sem paridade
RAID 5
Paridade P distribuída
RAID 6
Dupla paridade P + Q
Storage virtualizado
RAID + pool/LUN antes do datastore
RAID 1 / 10
Espelhamento abaixo do datastore. Se uma cópia válida existe, a camada superior ainda precisa ser verificada.
RAID 5
Uma paridade P pode reconstruir uma ausência quando os demais blocos da stripe estão legíveis.
RAID 6
Dupla paridade P+Q aumenta tolerância a falhas, mas não substitui backup ou integridade do datastore.
SAN / storage
Pool/LUN pode adicionar virtualização entre RAID e VMFS/ReFS. O arquivo virtual não deve ser analisado fora desse contexto.
Quando há falha física nos discos do RAID, entram PC-3000, clonagem profissional e, para HDD mecânico quando necessário, procedimentos físicos em sala limpa ISO-5. Quando os discos estão saudáveis e a falha é lógica, a recuperação pode ser totalmente remota.
VMDK, VHDX e datastores criptografados: preserve o conjunto antes de restaurar ou formatar
Ransomware pode atingir o host, arquivos de disco virtual, snapshots, backup repositories e storage compartilhado. O primeiro objetivo não é "tentar abrir a VM" repetidamente, mas isolar a infraestrutura e preservar o estado que ainda existe.
ESXi ransomware
Algumas famílias visam arquivos de VM no datastore e podem atingir VMDKs e configs.
Hyper-V ransomware
VHDX/AVHDX e volumes do host podem ser cifrados ou corrompidos.
Backups
Repositórios online podem ser afetados. Backup offline/imutável deve ser preservado antes de qualquer restore massivo.
Recuperação
Viabilidade depende da variante, cobertura da criptografia, snapshots não comprometidos e blocos residuais.
Como funciona a recuperação remota de VM para todo o Brasil
Casos de corrupção lógica podem ser avaliados remotamente quando os dados de origem estão acessíveis e estáveis. O objetivo é preservar o original e trabalhar sobre uma cópia ou destino independente.
12 passos quando uma máquina virtual crítica fica inacessível
O que pode agravar uma recuperação de VM
New Datastore / Format
Pode sobrescrever partition table, LVM/VMFS, ReFS ou outras estruturas críticas.
Apagar AVHDX ou delta VMDK
Filhos contêm alterações não presentes no base disk. Apagar manualmente pode destruir o estado atual.
Consolidate com chain quebrada
Consolidation é correta em chain íntegra, mas precisa ser interrompida quando consistency check falha ou deltas estão faltando.
CHKDSK/fsck no original
Ferramentas legítimas podem modificar metadata. Em recuperação forense, trabalhe primeiro sobre cópia quando o original é único.
Clonar sobre o mesmo storage
Destino deve ser independente para evitar sobrescrita e competição de I/O com a fonte.
Assumir snapshot = backup
Snapshot depende do mesmo storage e da cadeia de discos. Backup precisa existir em mídia/infraestrutura independente.
Como a SECURITY conduz a recuperação de dados de máquina virtual
O processo muda conforme a falha é lógica, de storage ou física. A regra central é preservar o estado útil antes de alterar a cadeia.
Caio Bruno F. Garcia, RAID Low Level e WinHex em VMs de extrema complexidade
WinHex pode auxiliar inspeção hexadecimal de LUNs, VMDK/VHDX e imagens quando o caso exige validar headers, offsets, partições, filesystem signatures e estruturas do storage abaixo da VM. Em ambientes com RAID quebrado, a análise Low Level acontece antes do datastore.
VMFS / LVM headers
Inspecionar partition table, assinaturas e regiões sobrescritas quando o ESXi não monta o datastore.
VMDK / VHDX structures
Comparar descriptors, parents, headers e boundaries em arquivos virtuais complexos.
RAID abaixo da VM
Validar disk order, stripe, parity e offsets quando o datastore depende de um array falhado.
Filesystem interno
Localizar NTFS, EXT, XFS ou database signatures dentro do disco virtual reconstruído.
Principais hipervisores, formatos e infraestruturas encontradas em recuperação de VM
A VM pode depender tanto do software de virtualização quanto do servidor, storage, RAID e formato de disco.
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo pilar complementa esta página porque mostra como a recuperação precisa atravessar discos físicos, RAID, VMs e banco de dados sem confundir as camadas.
Cenários técnicos de recuperação de máquina virtual
VMware ESXi com VMFS Inaccessible após falha do storage
Contexto: a LUN volta a ser vista pelo host, mas GPT/VMFS headers estão corrompidos e todas as VMs aparecem Inaccessible.
Estratégia: preservar imagem da LUN, analisar partition/LVM/VMFS, reconstruir o acesso aos diretórios e validar VMDKs em destino separado.
Hyper-V com VHDX e AVHDX em cadeia quebrada
Contexto: checkpoint merge falha depois de falta de espaço e os AVHDX permanecem no volume.
Estratégia: preservar todos os arquivos, mapear parent-child, reconstruir o estado lógico em cópia e extrair os dados sem apagar AVHDX.
Proxmox LVM-thin com várias VMs inacessíveis
Contexto: o thin pool apresenta metadata inconsistente e todos os logical volumes deixam de abrir.
Estratégia: preservar PV/VG/thin metadata, trabalhar em clone do block device e reconstruir volumes antes de analisar os guest filesystems.
VMware sobre RAID 5 com segundo disco instável
Contexto: datastore cai durante rebuild e os VMDKs ficam inacessíveis.
Estratégia: diagnosticar e clonar os membros, reconstruir RAID Low Level, depois VMFS e finalmente VMDK/guest filesystem.
VMFS sobrescrito parcialmente por outro filesystem
Contexto: a LUN é apresentada ao host errado e uma nova assinatura/filesystem é criada.
Estratégia: interromper novas escritas, preservar a LUN e analisar estruturas VMFS residuais e extents de VMDKs sem recriar o datastore.
FAQ sobre recuperação de dados de máquina virtual
O que é uma máquina virtual?
Máquina virtual é um computador definido por software que executa sistema operacional e aplicações sobre recursos fornecidos por um hipervisor. Seus discos ficam em arquivos ou volumes virtuais, como VMDK, VHDX, QCOW2, VDI ou VHD, e podem depender de datastore, storage, RAID, snapshots e metadata adicionais.
O que é recuperação de dados de máquina virtual?
É o processo de reconstruir as camadas necessárias para acessar os dados quando uma VM deixa de iniciar, um disco virtual corrompe, a cadeia de snapshots quebra, o datastore fica inacessível ou o storage físico falha. O trabalho pode envolver RAID, VMFS, VHDX, QCOW2, LVM-thin, ZFS, SRs e o filesystem dentro da própria VM.
Quais formatos de disco virtual podem ser recuperados?
A viabilidade depende do estado dos dados, mas ambientes podem envolver VMDK no VMware, VHD/VHDX no Hyper-V, QCOW2 e RAW no QEMU/Proxmox, VDI/VHD/VMDK no VirtualBox e VHD/QCOW2 em XCP-ng conforme versão e storage repository.
VMDK corrompido pode ser recuperado?
Pode existir viabilidade quando os extents, descriptors ou blocos de dados ainda estão presentes. Em VMware, a análise precisa considerar base disk, delta/sesparse files, Content IDs, parent chain e o filesystem interno da VM. A presença de um arquivo VMDK sozinho não comprova integridade da cadeia.
VHDX corrompido pode ser recuperado?
Pode existir viabilidade. VHDX pode ser fixed, dynamic ou parte de uma cadeia de differencing disks/checkpoints com AVHDX. A recuperação precisa preservar o arquivo original e entender parent-child relationships antes de executar merge ou repair que escreva sobre a cadeia.
O que é um datastore VMFS?
VMFS é o filesystem de datastore do VMware ESXi para armazenar arquivos de máquinas virtuais. Ele fica normalmente sobre uma LUN, dispositivo local ou storage apresentado ao host. Se a LUN some, a partição VMFS é sobrescrita ou os headers LVM/VMFS corrompem, todas as VMs daquele datastore podem ficar Inaccessible.
VMFS Inaccessible significa que os VMDKs foram apagados?
Não necessariamente. Broadcom documenta datastores inacessíveis por perda de acesso ao LUN, problemas de hardware, mudança de controladora, perda da partition table ou corrupção de headers. Os blocos de VM podem continuar presentes mesmo quando o ESXi não monta o datastore.
Posso criar um novo datastore no mesmo LUN para tentar recuperar?
Não quando os dados antigos precisam ser recuperados. Broadcom orienta não escrever novos dados nem criar novo filesystem na LUN se há dados perdidos a recuperar. Criar VMFS novo pode sobrescrever GPT, LVM, VMFS e diretórios necessários à reconstrução.
Posso usar VOMA em um datastore com dados perdidos?
VOMA possui modos de análise e ferramentas de consistência, mas a ação deve ser diferenciada entre inspeção e reparo. Em cenários em que dados perdidos precisam ser recuperados, a prioridade é preservar a LUN e evitar mudanças de escrita. Broadcom recomenda serviço de recuperação antes de criar novo filesystem quando os headers estão corrompidos.
Posso rodar CHKDSK em VHDX corrompido?
CHKDSK é uma ferramenta legítima de reparo de filesystem do Windows, e a Microsoft a inclui em troubleshooting de Hyper-V. Porém, ela modifica estruturas do filesystem. Quando o objetivo é recuperação forense de dados e o VHDX original está corrompido, é mais seguro trabalhar primeiro sobre uma cópia ou imagem, preservando o estado original.
Posso consolidar snapshots VMware quando há suspeita de corrupção?
Consolidation é uma operação normal e oficial do VMware quando a snapshot chain está íntegra. Ela é intensiva em leitura e escrita e mescla delta blocks nos parents. Se a cadeia está inconsistente, arquivos delta estão faltando ou o storage está instável, confirme a consistência e preserve cópias antes de consolidar.
Snapshots VMware são backup?
Não. Broadcom afirma que snapshots não devem ser usados como backup. Um snapshot mantém deltas dependentes do disco base e do datastore. Se os base disks forem perdidos, os snapshot files isolados não são suficientes para restaurar a VM.
Quantos snapshots VMware podem existir?
Broadcom documenta suporte de até 32 snapshots em uma cadeia, mas recomenda apenas 2 a 3 para melhor desempenho e orienta não manter um snapshot por mais de 72 horas. Isso é uma recomendação VMware e não deve ser aplicada automaticamente a outros hipervisores.
O que é AVHDX no Hyper-V?
AVHDX é o arquivo de differencing disk usado por checkpoints do Hyper-V. A Microsoft documenta que checkpoints ficam em arquivos AVHDX e que a exclusão correta de um checkpoint mescla as mudanças no parent VHDX. Arquivos AVHDX não devem ser simplesmente apagados no filesystem.
Como funciona Merge-VHD?
Merge-VHD é o cmdlet oficial Microsoft que mescla discos virtuais em uma cadeia de differencing disks. A Microsoft documenta que a operação é offline e que a cadeia não deve estar anexada durante o merge. Em uma recuperação, a parent chain precisa ser conhecida e preservada antes de mesclar.
Checkpoint Hyper-V quebrado pode ser recuperado?
Pode existir viabilidade dependendo de quais VHDX/AVHDX permanecem presentes. A Microsoft documenta checkpoints orphaned, missing e hidden, além de cadeias de differencing disks. Em dados críticos, preserve todos os arquivos antes de tentar merge ou exclusão.
Proxmox usa sempre QCOW2?
Não. Proxmox VE suporta vários backends. File storage pode usar raw, qcow2 e outros formatos; LVM-thin e ZFS normalmente apresentam block devices/raw volumes; Ceph RBD é storage em bloco; NFS/CIFS podem armazenar arquivos. A recuperação depende do backend real.
O que é LVM-thin no Proxmox?
LVM-thin é um backend de block storage com thin provisioning, snapshots e clones. O thin pool mantém metadata que mapeia blocos físicos e volumes lógicos. Corrupção do thin pool pode afetar várias VMs ao mesmo tempo.
Proxmox com ZFS pode ser recuperado?
Pode existir viabilidade conforme o estado do pool, vdevs, labels, uberblocks e datasets/zvols. Em Proxmox, ZFS é um backend próprio e não deve ser tratado como um simples arquivo QCOW2 quando os discos da VM são zvols raw.
XCP-ng usa VHD?
Sim. A documentação XCP-ng informa que VHD é o formato padrão histórico e que XCP-ng 8.3 também passou a suportar QCOW2 em vários tipos de Storage Repository. VHD suporta snapshots, delta backup e clones e pode formar cadeias que precisam ser analisadas corretamente.
VirtualBox usa apenas VDI?
Não. Oracle VirtualBox usa VDI como formato nativo, mas também suporta VMDK e VHD, além de differencing images. O formato real e a relação parent-child precisam ser confirmados antes da recuperação.
VM deletada acidentalmente do inventário está perdida?
Remover a VM do inventário não necessariamente apaga os arquivos do datastore. Se VMDK/VHDX/QCOW2 e configuração ainda existem, a VM pode ser re-registrada ou reconstruída. Se os arquivos foram efetivamente excluídos ou o datastore reutilizado, a recuperação depende de sobrescrita e da arquitetura de storage.
VM deletada do datastore pode ser recuperada?
Pode existir viabilidade enquanto os blocos ainda não foram sobrescritos e a camada de storage permitir reconstruir metadata e extents. Thin provisioning, snapshots, TRIM/UNMAP, all-flash e storage virtualizado podem mudar significativamente o comportamento após exclusão.
Ransomware em ESXi ou Hyper-V permite recuperação de VM?
Depende da variante, do que foi criptografado e da existência de snapshots ou backups não comprometidos. A prioridade é isolar o ambiente, preservar evidências e não executar ações que modifiquem os arquivos originais. O trabalho pode envolver VMDK/VHDX parcialmente criptografados e storage subjacente.
RAID e VM são a mesma recuperação?
Não. RAID é uma camada física ou lógica abaixo do datastore. A recuperação de VM pode exigir primeiro reconstruir RAID e storage, mas depois ainda existem VMFS, VMDK/VHDX/QCOW2, snapshots e filesystem interno. Esta página mantém a intenção principal em recuperação de máquina virtual.
É possível recuperar uma VM remotamente?
Sim, em muitos casos lógicos. Se o storage está estável e acessível, a análise pode ser feita remotamente com logs, sessão segura e cópia dos discos virtuais ou LUNs para destino independente. Falhas físicas, mídias instáveis ou RAID com discos defeituosos podem exigir envio das mídias ao laboratório.
Preciso levar o servidor físico?
Na maioria dos casos lógicos de VMDK, VHDX, QCOW2, VMFS ou checkpoint, não. Logs, arquivos virtuais, LUNs ou cópias podem ser suficientes. Se a origem do problema é física em HDD/SSD/RAID, pode ser necessário enviar as mídias, não necessariamente o servidor inteiro.
Quanto custa recuperar uma máquina virtual?
O custo depende da plataforma, volume de dados, tipo de corrupção, cadeia de snapshots, storage físico, RAID, quantidade de VMs e intervenções anteriores. Casos lógicos sobre arquivos estáveis têm escopo diferente de um datastore sobre RAID com múltiplas falhas físicas.
Quanto tempo leva?
Não existe prazo único. A análise de uma cadeia pequena de discos virtuais pode ser mais curta que a clonagem de vários discos físicos ou a reconstrução de um SAN. O diagnóstico precisa informar quais camadas estão falhando antes de estimar prazo.
A SECURITY atende recuperação de VM em todo o Brasil?
Sim. Casos lógicos compatíveis podem ser avaliados e conduzidos remotamente para todo o Brasil. Quando há falha física, a SECURITY orienta o envio seguro das mídias necessárias. Alphaville é priorizado como ponto de atendimento em Barueri.
Sem necessidade de levar o equipamento em muitos casos e recuperação remota para todo o Brasil
Se a falha é lógica e os arquivos ou LUNs estão acessíveis de forma estável, podemos iniciar por sessão remota, análise de logs e cópia para destino independente. Não é necessário levar o servidor físico apenas para analisar um VMDK, VHDX, QCOW2 ou datastore acessível.
Remoto
VMware, Hyper-V, Proxmox e outros ambientes podem ser avaliados por acesso seguro quando a origem está estável.
Envio de mídias
Se há falha física, orientamos envio dos HDDs/SSDs/NVMe necessários, mantendo slot e serial documentados.
Servidor completo
Normalmente não é necessário, exceto quando backplane, controladora, cache ou comportamento específico do hardware faz parte da falha.
Todo o Brasil
Triagem lógica pode começar remotamente independentemente do estado; logística física é definida conforme o diagnóstico.
Alphaville, São Paulo e Campinas quando o caso exige laboratório
Quando existe falha física nas mídias ou necessidade de intervenção em storage/RAID, a SECURITY orienta a logística e recebe o material necessário. Em Barueri, este artigo prioriza Alphaville.
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 e, em projetos de virtualização de alta complexidade, relaciona a camada de VM ao storage, RAID Low Level, análise hexadecimal com WinHex e tecnologias de aquisição como PC-3000 e Data Extractor quando a falha chega às mídias físicas.
Máquina virtual por dentro: datastore, disk chain, snapshots, RAID e filesystem
Este guia aprofunda os conceitos que mais ajudam a separar manutenção normal de recuperação de dados e transforma a página em uma referência técnica sobre virtualização.
1. Hipervisor
Hipervisor cria e gerencia hardware virtual para VMs. ESXi, Hyper-V, Proxmox/QEMU e XCP-ng usam estruturas e storage backends diferentes.
2. Configuração da VM
Arquivos de configuração descrevem CPU, memória, devices e discos. Perder a configuração não equivale necessariamente a perder os discos virtuais.
3. Disco virtual
VMDK, VHDX, QCOW2, VDI e VHD são abstrações de bloco. O guest OS os enxerga como discos e cria partições/filesystems internos.
4. VMDK descriptor e extent
Em VMware, um pequeno descriptor pode apontar para flat/delta extents. Recuperar apenas um arquivo sem entender a relação pode produzir disco inválido.
5. VMDK snapshot delta
Broadcom documenta delta/sesparse files que recebem writes depois do snapshot. A chain current state depende do child mais recente e de todos os parents necessários.
6. VMware consolidation
Consolidation mescla blocos dos delta disks nos parents. É uma operação suportada e normal quando a chain está íntegra.
7. Content ID mismatch
Broadcom documenta erros quando um child espera Parent Content ID diferente do base/parent disponível. Missing delta files podem quebrar a chain e impedir consolidation normal.
8. Snapshot não é backup
Broadcom recomenda não usar snapshots VMware como backup. Eles dependem do base disk e do mesmo storage.
9. Snapshot depth VMware
VMware suporta até 32 snapshots numa cadeia, mas recomenda apenas 2 a 3 para desempenho e não manter snapshot individual por mais de 72 horas.
10. VMFS
VMFS é o datastore filesystem do ESXi e organiza diretórios e arquivos das VMs sobre block devices/LUNs.
11. VMFS Inaccessible
Broadcom lista perda de LUN/path, hardware, administrative unmount, partition table perdida e corrupção de metadata como causas possíveis.
12. Missing LVM Magic
Quando LVM/VMFS signatures são sobrescritas, o ESXi deixa de reconhecer o volume. Se lost data precisa ser recuperado, Broadcom orienta não criar novo filesystem.
13. VOMA
VOMA é ferramenta VMware para analisar consistência de metadata. Em recuperação, diferencie check/análise de fix/reparos e preserve a LUN antes de qualquer ação com escrita.
14. VHDX
Formato de disco virtual moderno do Hyper-V. Pode ser fixed ou dynamic e participar de differencing chains.
15. AVHDX
Arquivo de differencing disk criado por checkpoint. Microsoft orienta não apagar AVHDX manualmente.
16. Merge-VHD
Cmdlet oficial que mescla differencing disks em parent. Microsoft documenta a operação como offline.
17. Checkpoints orphaned
Arquivos AVHDX podem existir mesmo sem aparecer corretamente no Hyper-V Manager, principalmente após backup/merge incompleto.
18. CHKDSK
CHKDSK é ferramenta legítima para filesystem Windows. Como escreve correções, o original de um VHDX crítico deve ser preservado antes de usá-la como tentativa de recuperação.
19. Proxmox file storage
Directory/NFS/CIFS podem guardar raw, qcow2 e outros files. Snapshots em file storage normalmente dependem do formato e backend.
20. Proxmox LVM
LVM apresenta block logical volumes e pode ser usado sobre storage local ou SAN. O disco da VM pode não existir como arquivo.
21. Proxmox LVM-thin
Thin pool aloca blocos sob demanda e suporta snapshots/clones. Corrupção da thin metadata pode afetar múltiplos volumes.
22. Proxmox ZFS
ZFS backend usa pools/datasets/zvols e suporta snapshots/clones. Recuperação precisa analisar pool e não apenas procurar QCOW2.
23. Proxmox Ceph RBD
Ceph RBD distribui block images pelo cluster. A falha pode estar em OSDs/PGs, cluster metadata ou imagem RBD, não num arquivo local.
24. QCOW2
QEMU copy-on-write format suporta backing files e snapshots. A cadeia de backing files precisa ser conhecida em cenários de dependência.
25. XCP-ng Storage Repository
SR define onde os VDIs residem. Pode usar LVM, NFS, iSCSI, Fibre Channel e outros backends.
26. XCP-ng VHD
VHD é formato histórico padrão do SMAPIv1 e suporta snapshots, delta backups e clones. XCP-ng 8.3 adicionou QCOW2 a muitos SR types.
27. VirtualBox VDI
VDI é formato nativo VirtualBox. Oracle também suporta VMDK e VHD.
28. VirtualBox differencing images
Differencing images dependem de parent UUID/path. Alterar ou perder parent pode quebrar a cadeia lógica.
29. RAID abaixo do hipervisor
VMware ou Hyper-V pode estar saudável, mas depender de um RAID local degradado. Nesse caso a recuperação física/lógica do array vem antes da VM.
30. RAID 5 e VMFS
Uma falha adicional durante rebuild pode retirar o datastore inteiro. Depois de reconstruir o RAID, VMFS ainda precisa ser validado.
31. RAID 6 e VMs
Dupla paridade protege contra duas falhas em condições normais, mas não evita corrupção lógica de VMFS/VHDX ou ransomware.
32. SAN / LUN
Datastore pode estar em FC/iSCSI SAN. LUN desaparecida pode ser path/mapping e não corrupção. Confirme storage visibility antes de atuar no filesystem.
33. Thin provisioning
VM disks e LUNs podem ser thin. Exclusão, TRIM/UNMAP e reutilização podem alterar a chance de recuperar blocos deletados.
34. Snapshots de storage
Array snapshots são diferentes de snapshots do hipervisor. Podem oferecer ponto adicional de recuperação, mas também possuem metadata e retenção próprias.
35. Ransomware
Snapshots online no mesmo ambiente podem ser apagados ou criptografados. Isolamento e cópias imutáveis são controles diferentes do RAID.
36. Recuperação remota
Quando storage e arquivos são estáveis, logs, cópias e análise podem ser conduzidos remotamente. O objetivo é evitar I/O destrutivo e mover o trabalho para um destino independente.
37. Recuperação física
Se o datastore está sobre HDD/SSD com falha, o problema deixa de ser apenas virtualização. PC-3000, clonagem controlada e, quando necessário, sala limpa entram antes da camada VM.
38. WinHex
WinHex pode ajudar na inspeção de baixo nível, RAID, partition tables e headers. Não substitui ferramentas do hipervisor nem decodifica automaticamente qualquer formato.
39. SQL Server dentro da VM
Depois de recuperar o disk image e filesystem, MDF/NDF/LDF ainda precisam ser validados no nível da aplicação.
40. Active Directory
Um DC que consegue bootar não está automaticamente íntegro. Serviços, database do AD e replicação precisam ser verificados em ambiente controlado.
41. ERP e aplicações
O objetivo final pode ser extrair database/files sem necessariamente restaurar o mesmo hipervisor original.
42. Backup x snapshot
Backup deve existir em storage separado e ter restore testado. Snapshot é estado dependente da mesma infraestrutura.
43. Restore test
Backups só são confiáveis quando restauráveis. Testes periódicos reduzem dependência de recuperação emergencial.
44. Logs
vmkernel.log, vmware.log, Hyper-V Event Logs, Proxmox journals e storage events preservam a cronologia da falha.
45. Segundo parecer
Consolidate, Merge, CHKDSK, VOMA, fsck, recreate datastore, controller swap e restores anteriores precisam ser documentados antes de uma nova tentativa.
46. Matriz técnica de decisão
| Sintoma | Camada provável | Prioridade | Evitar |
|---|---|---|---|
| VMFS Inaccessible | LUN/path ou VMFS | Preservar LUN e logs | New Datastore |
| VMDK chain broken | Snapshot parent-child | Mapear todos os deltas | Consolidate cego |
| VHDX/AVHDX orphaned | Checkpoint chain | Preservar files e ParentPath | Apagar AVHDX |
| LVM-thin corrupt | Proxmox storage metadata | Clonar PV/VG/thin metadata | recriar thin pool |
| ZFS pool degraded | vdev/pool | Preservar devices e labels | import -f por tentativa |
| RAID degraded + VMs offline | Camada física | Diagnosticar/clonar membros | rebuild repetido |
| Ransomware | host/VM/storage | Isolar e preservar evidências | restores/escritas desordenadas |
| VM apagada | inventory/datastore | Evitar sobrescrita e verificar files | reutilizar espaço |
47. Conclusão técnica
Recuperação de máquina virtual é a reconstrução do caminho entre storage físico e aplicação. O melhor resultado vem de preservar o estado, identificar a camada da falha e trabalhar de baixo para cima. VMDK, VHDX, QCOW2 e VMFS são apenas partes do problema. Em muitos casos lógicos, todo o trabalho pode começar remotamente, sem transportar o servidor físico.
Referências utilizadas para validar este guia
- Broadcom: VMFS Inaccessible, Missing LVM Magic e preservação para data recovery
- Broadcom: causas de VMFS Datastore Inaccessible
- Broadcom: VMFS sobrescrito por ReFS e VMs Orphaned
- Broadcom: Delete/Consolidate snapshots
- Broadcom: best practices de snapshots, backup, 32 snapshots, 2-3 recomendados e 72h
- Broadcom: snapshot chain consistency e consolidation manual
- Microsoft: checkpoints Hyper-V e AVHDX
- Microsoft: Merge-VHD
- Microsoft: troubleshooting de snapshots/checkpoints/differencing disks
- Proxmox VE Administration Guide: storage, LVM-thin, ZFS e snapshots
- XCP-ng: Storage API, VHD e QCOW2
- XCP-ng: SR/VDI management e snapshot chain collapse em migration
- Oracle VirtualBox: VDI, VMDK, VHD e virtual storage
- X-Ways: WinHex low-level data processing and RAID interpretation
