A recuperação de dados em VMware exige separar storage físico, VMFS, VMDK, snapshot chain, vSAN e o filesystem da própria VM. A SECURITY atua sobre cópias sempre que possível, com recuperação remota para todo o Brasil em casos lógicos compatíveis.
O que é VMware ESXi?
A intenção principal desta página é recuperação de dados VMware. RAID aparece como camada inferior quando o datastore depende de um array físico.
Guia completo de recuperação de dados em VMware
VMware precisa ser recuperado por camadas
Uma VM pode aparecer Inaccessible porque a LUN sumiu, VMFS não monta, o descriptor VMDK foi perdido, a snapshot chain está inconsistente ou o storage físico falhou.
A recuperação VMware precisa identificar onde o acesso deixou de ser coerente antes de reparar a camada acima.
Essa separação evita ações na camada errada. Se o descriptor sumiu mas o -flat.vmdk existe, a Broadcom documenta recriação do descriptor. Se a LUN foi sobrescrita, recriar o descriptor não resolve o VMFS.
Datastore Inaccessible, VMDK missing, CID mismatch e vSAN objects inacessíveis
Datastore Inaccessible
LUN/path, partition table, LVM/VMFS headers ou storage podem estar em falha.
VMDK missing
Descriptor, flat extent, delta ou sesparse file podem estar ausentes.
CID mismatch
Parent/child snapshot descriptors não fecham a chain.
Consolidation failed
Locks, storage connectivity, chain inconsistency ou falta de espaço podem bloquear merge.
Object Inaccessible
Fault domains, disk groups, rede ou dispositivos podem afetar componentes.
APD / PDL
Perda de paths ou dispositivo permanente pode retirar o datastore sem apagar automaticamente os blocos.
VMFS inacessível: primeiro separar path loss de metadata corrompida
Broadcom documenta VMFS Inaccessible com causas distintas: LUN não apresentada, missing partition, LVM/VMFS headers corrompidos, storage controller replacement e overwrites.
| Sintoma | Camada provável | Próxima verificação | Evitar |
|---|---|---|---|
| Datastore 0B | APD/PDL/path | esxcli storage, SAN paths | formatar LUN |
| Missing LVM Magic | LVM/VMFS headers | VOMA/check + imagem | New Datastore |
| Partition ausente | GPT/VMFS partition | partedUtil / backing LUN | criar nova partição por tentativa |
| Após controller swap | storage presentation/geometry | controller + LUN identity | inicializar storage |
Quando lost data precisa ser recuperado e não existe backup recente, Broadcom orienta não escrever novos dados nem criar novo filesystem na LUN.
Descriptor perdido é diferente de -flat.vmdk perdido
Broadcom documenta recriação de descriptor VMDK quando o data file ainda existe. O descriptor pequeno contém createType, extent description, geometry e outras propriedades; o -flat.vmdk contém blocos do virtual disk em vários layouts VMFS.
Descriptor .vmdk
Pode ser recriado em cenários suportados se tamanho, type e extent corretos são conhecidos.
-flat.vmdk
É o data file do virtual disk em vários formatos VMFS. Se está ausente, a Broadcom orienta backup/recovery especializado.
delta.vmdk
Data file de snapshot em vmfsSparse em vários cenários antigos.
sesparse.vmdk
Usado para snapshots VMFS6 e certos discos grandes.
O benchmark acerta ao destacar VMDK corrompido e flat órfão, mas exagera ao sugerir que vmkfstools sempre destrói metadata. vmkfstools é ferramenta oficial; o risco está em usá-la sem compreender a estrutura e sobre a única cópia.
CID, parentCID e parentFileNameHint definem a snapshot chain
Broadcom documenta que filenames numéricos não são suficientes para ordenar a chain. O child possui parentCID e parentFileNameHint; o parent possui CID. Uma inconsistência quebra o encadeamento.
Broadcom documenta CID/parentCID e parentFileNameHint como parte da relação entre parent e child.
32 suportados
Broadcom documenta até 32 snapshots numa chain.
2 a 3 recomendados
Para melhor performance e menor complexidade operacional.
72 horas
Broadcom recomenda não manter um snapshot individual por mais de 72 horas.
Snapshot não é backup
Delta depende do base disk e do mesmo datastore.
Consolidation é operação suportada quando a chain está íntegra. Se há files faltando, CID mismatch ou storage instável, preserve tudo antes de consolidar.
vSAN: objetos, components, resync, APD e PDL
vSAN distribui objetos de VM conforme storage policy e fault domains. Broadcom documenta estados como inaccessible, degraded, absent, stale e resyncing após host, rede ou disk group failures.
APD
All Paths Down significa perda de todos os paths sem confirmação imediata de perda permanente.
PDL
Permanent Device Loss é sinalização de perda permanente do device ou path.
Repair delay
O delay padrão para certas host failures é 60 minutos; mudar o timer não acelera resync já iniciado.
Inaccessible objects
Em double fault ou perda de fault domains, objetos podem ficar indisponíveis até componentes voltarem ou suporte orientar.
Em cenários de objetos inacessíveis, Broadcom recomenda evitar mudanças permanentes sem suporte porque alterar componentes ou topology pode reduzir fontes de recuperação.
Delete Datastore e nova formatação podem sobrescrever VMFS
Broadcom documenta em 2026 que excluir um VMFS datastore e criar um novo volume na mesma área é destrutivo e pode sobrescrever metadata e data blocks. Também documenta casos de instalação acidental do ESXi sobre uma LUN VMFS.
Delete Datastore
Remove estruturas e, combinado com novo volume, pode destruir metadata crítica.
New Datastore
Não deve ser criado sobre uma LUN com lost data a recuperar.
ESXi instalado na LUN
Pode substituir partition table e filesystem layout.
Snapshot LUN
Quando existe snapshot de storage anterior ao overwrite, pode ser uma fonte útil.
VMX perdido ou VM removida do vCenter não significa que o VMDK sumiu
Broadcom documenta reconstrução de VMX usando vmware.log e criação de nova VM shell com existing disks em cenários em que os virtual disks estão íntegros.
.vmx
Configuração da VM. Pode apontar para base VMDK ou snapshot child.
.vmsd
Banco de informações de snapshots para Snapshot Manager.
.vmsn
Pode conter config e memory state de snapshots.
Inventário
Unregister/remove do inventory não é igual a delete files.
SAN, NFS, iSCSI e multipath podem causar Inaccessible sem destruir os dados
Fibre Channel
Zoning, HBA ou path loss pode retirar LUN sem alterar blocos.
iSCSI
Network, target e multipath podem causar APD.
NFS
Locks e storage connectivity podem impedir consolidation e VM access.
Controller replacement
Datastore local pode desaparecer após troca de controller sem apagar automaticamente o disk content.
RAID é camada inferior, não a intenção principal desta página
RAID 1 / 10
Mirror
RAID 5
Paridade P
RAID 6
P + Q
vSAN / Storage
Objetos/policies antes da VM
Quando ESXi usa RAID local ou storage baseado em RAID, a recuperação física/logical do array pode vir antes de VMFS. Caio Bruno F. Garcia é associado a RAID Low Level e WinHex em casos de extrema complexidade.
ESXi ransomware pode atingir VMDKs, snapshots e backups
Variantes voltadas a virtualização podem criptografar disk images, configs e backups montados. A prioridade é isolar o ambiente e preservar originais antes de restore ou repair.
Isolar
Interromper propagação e novas escritas.
Preservar
VMDK, VMX, logs, ransom note e backups.
Validar backup
Preferir cópia independente e testada.
Recovery
Viabilidade depende da variante, extensão da criptografia e storage.
Como funciona a recuperação remota de VMware
12 passos quando VMware perde datastore, VMDK ou snapshots
O que realmente pode agravar uma recuperação VMware
New Datastore
Pode sobrescrever VMFS e data blocks.
Delete Datastore
Broadcom documenta impacto destrutivo quando combinado com nova criação.
Consolidate em chain quebrada
Files faltando ou CID mismatch precisam ser entendidos antes.
Editar descriptors sem cópia
Parent incorreto pode apresentar estado errado da VM.
Remover components vSAN
Pode reduzir fontes disponíveis em double fault.
Rebuild RAID cego
Outro membro instável pode afetar o datastore inteiro.
Como a SECURITY conduz a recuperação de VMware
Se existe falha física, entram PC-3000, Data Extractor, DeepSpar e, quando necessário, procedimentos em sala limpa ISO-5.
Caio Bruno F. Garcia, WinHex e RAID Low Level em VMware de extrema complexidade
WinHex pode auxiliar inspeção hexadecimal de LUNs, VMFS signatures, partition tables, VMDK descriptors/extents e RAID físico quando o caso exige análise abaixo das ferramentas VMware.
VMFS/LVM
Inspecionar signatures e regiões sobrescritas.
VMDK
Comparar descriptors, flat/delta extents e offsets.
Snapshot chain
Correlacionar CIDs e files existentes.
RAID físico
Validar ordem, stripe, paridade e offsets.
Principais tecnologias encontradas em projetos VMware
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo complementa este artigo quando VMware depende de RAID ou storage corporativo.
Cenários técnicos de recuperação de VMware
VMFS Inaccessible com Missing LVM Magic
Preservar a LUN, analisar headers/partition table e evitar New Datastore.
Descriptor VMDK perdido com -flat presente
Validar tamanho/type e recriar descriptor em cópia antes de reanexar.
Snapshot chain com CID mismatch
Mapear parent/child, descriptors e vmware.log antes de consolidation.
vSAN com objects Inaccessible após double fault
Preservar object health, fault domains e devices antes de mudanças permanentes.
VMware sobre RAID 5 degradado
Recuperar primeiro o array, depois VMFS, VMDK e guest filesystem.
FAQ sobre recuperação de dados em VMware
O que é VMware ESXi?
VMware ESXi é o hipervisor bare-metal da plataforma vSphere. Ele executa máquinas virtuais diretamente sobre o hardware e utiliza datastores como VMFS, NFS, vSAN e outros backends para armazenar arquivos de VM.
O que é recuperação de dados em VMware?
É o processo de preservar e reconstruir as camadas necessárias para acessar dados quando VMFS fica inacessível, VMDK ou snapshot chain corrompem, vSAN perde objetos, a LUN desaparece ou o storage físico falha.
O que é VMFS?
VMFS é o filesystem de datastore usado pelo VMware ESXi para armazenar arquivos de máquinas virtuais. Se a LUN perde partition table, LVM/VMFS headers ou acesso físico, todas as VMs do datastore podem ficar Inaccessible.
VMFS Inaccessible significa perda total?
Não necessariamente. Broadcom documenta causas como LUN não apresentada, path loss, partition table ausente, headers LVM/VMFS corrompidos, troca de controladora ou sobrescrita. O tratamento depende da causa.
Posso criar um novo datastore sobre a LUN inacessível?
Não quando os dados antigos precisam ser recuperados. Broadcom orienta não escrever novos dados nem criar novo filesystem na LUN quando existe lost data a recuperar.
VMDK corrompido pode ser recuperado?
Pode existir viabilidade. É preciso separar descriptor .vmdk, data extent -flat.vmdk e, quando há snapshots, delta/sesparse extents. Descriptor ausente pode ser recriado em cenários suportados se o data file correto permanece presente.
Qual a diferença entre .vmdk e -flat.vmdk?
O .vmdk pequeno é normalmente o descriptor que contém geometria e referências. O -flat.vmdk é o arquivo de dados de um disco VMFS thick/thin em vários cenários. Perder apenas o descriptor é diferente de perder o flat data file.
Descriptor VMDK perdido significa que os dados foram perdidos?
Não necessariamente. A Broadcom documenta procedimento para recriar descriptor quando o flat file continua presente. Se o data file foi perdido, a situação é muito mais grave e pode exigir backup ou recuperação especializada.
O que é snapshot chain no VMware?
Snapshots criam child disks em relação ao parent. Cada descriptor possui CID e parentCID; também pode conter parentFileNameHint. A ordem correta da chain depende dessas relações, não apenas do número do filename.
O que é CID mismatch?
É uma inconsistência em que o parentCID do child não corresponde ao CID do parent esperado. Broadcom documenta que isso pode impedir power-on ou consolidation e, em certos cenários, pode ser corrigido nos descriptors.
Consolidate snapshots é sempre destrutivo?
Não. Consolidation é uma operação oficial VMware para mesclar snapshot data quando a chain está íntegra. Em recovery, o risco aumenta quando há files faltando, CID mismatch, storage instável ou falta de espaço.
Snapshots VMware são backup?
Não. Broadcom recomenda não usar snapshots como backup. O snapshot é um change log dependente do base disk e do mesmo datastore.
Quantos snapshots VMware são suportados?
Broadcom documenta suporte de até 32 snapshots em uma chain e recomenda apenas 2 a 3 para melhor desempenho. Também recomenda não manter um snapshot individual por mais de 72 horas.
O que é seSparse no VMware?
Em VMFS6, snapshots usam seSparse. Broadcom também documenta seSparse para certos discos maiores que 2 TB em versões anteriores. A chain ainda depende de descriptors e CIDs corretos.
VM removida do vCenter está perdida?
Não necessariamente. Remover do inventário não é o mesmo que apagar os arquivos do datastore. Se VMX e VMDKs continuam presentes, a VM pode ser re-registrada ou reconstruída.
VMX perdido pode ser reconstruído?
Pode, em muitos cenários. Broadcom documenta reconstrução de configuração usando vmware.log e criação de nova VM shell com existing disks quando os VMDKs estão disponíveis.
O que é vSAN Inaccessible Object?
vSAN distribui objetos de VM entre componentes conforme storage policy. Broadcom documenta objetos em estado inaccessible, degraded, absent ou resyncing quando hosts, disk groups, rede ou dispositivos falham.
APD e PDL são a mesma coisa?
Não. APD significa All Paths Down, quando o ESXi perde todos os caminhos e não sabe se a perda é temporária ou permanente. PDL significa Permanent Device Loss, quando o storage informa perda permanente.
PDL ou APD significa que os dados foram apagados?
Não automaticamente. Esses estados descrevem perda de acesso ao dispositivo. O conteúdo pode continuar no storage, dependendo da causa. O diagnóstico deve separar connectivity de corrupção ou perda física.
vSAN com objects Inaccessible pode ser recuperado?
Pode existir viabilidade dependendo dos fault domains, components, object health, OSD/cache/capacity devices e resync state. Broadcom recomenda suporte antes de mudanças permanentes em cenários de objetos inacessíveis.
Posso reduzir o vSAN repair delay para acelerar a recuperação?
Broadcom explica que o repair delay controla quando vSAN inicia repair após certos host failures; mudar o timer não acelera um resync já em andamento. Falha física de disk pode iniciar rebuild imediatamente.
VOMA recupera VMFS apagado?
VOMA é uma ferramenta de análise de metadata. Se os headers VMFS foram sobrescritos e lost data precisa ser recuperado, Broadcom orienta data recovery em vez de criar novo filesystem. VOMA não é uma ferramenta universal de undelete.
Excluir um datastore VMFS é destrutivo?
Broadcom documenta que Delete Datastore é destrutivo e que criar um novo volume sobre a mesma área sobrescreve metadata e blocos. Não faça isso quando os dados precisam ser recuperados.
Instalar ESXi na LUN errada pode apagar o datastore?
Sim. Broadcom documenta casos em que instalação acidental do ESXi sobre uma LUN VMFS substitui partition table e estruturas, tornando o datastore inacessível.
Ransomware em ESXi pode ser recuperado?
Depende da variante, cobertura da criptografia, snapshots, backups e storage. A prioridade é isolar o ambiente, preservar VMDKs e não executar ações de escrita desordenadas.
VMware sobre RAID físico pode ser recuperado?
Pode. Quando a falha está no RAID abaixo do datastore, o array precisa ser reconstruído primeiro. Depois VMFS, VMDK, snapshots e guest filesystems são analisados.
RAID e VMware são a mesma recuperação?
Não. RAID é uma camada inferior. Esta página mantém a intenção principal em recuperação de VMware ESXi/vSphere.
É possível recuperar VMware remotamente?
Sim, em muitos casos lógicos. Se LUNs, datastores ou VMDKs estão acessíveis e estáveis, a triagem pode começar remotamente com logs e cópias. Falhas físicas exigem envio das mídias.
Preciso levar o servidor completo?
Na maioria dos casos lógicos, não. Logs, VMDKs, snapshots, VMX e imagens de LUN podem ser suficientes. Em falha física, normalmente enviam-se as mídias afetadas e informações do RAID.
Quanto custa recuperar VMware?
O custo depende do volume, quantidade de VMs, VMFS, snapshot chain, vSAN, storage físico, RAID, ransomware e intervenções anteriores.
Quanto tempo leva?
Depende da camada da falha. Recriar um descriptor pode ser muito diferente de reconstruir um VMFS ou vSAN sobre múltiplas mídias instáveis.
A SECURITY atende VMware em todo o Brasil?
Sim. Casos lógicos compatíveis podem começar por recuperação remota para todo o Brasil. Quando há falha física, a SECURITY orienta o envio das mídias necessárias.
Sem necessidade de levar o equipamento em muitos casos
Remoto
Logs, VMDKs e LUN images podem ser analisados por sessão segura.
Mídias físicas
Se HDD/SSD/RAID falha, enviam-se as mídias afetadas.
Servidor completo
Normalmente não é necessário em falha lógica de datastore/VMDK.
Todo o Brasil
Triagem lógica pode começar independentemente da localização.
Alphaville, São Paulo e Campinas quando o caso exige laboratório
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 ambientes VMware de alta complexidade, relaciona VMFS, VMDK e snapshots às camadas de storage, RAID Low Level e análise hexadecimal com WinHex, além de PC-3000 e Data Extractor quando existe falha física.
VMware por dentro: VMFS, VMDK, snapshots e vSAN
1. ESXi
Hipervisor bare-metal da plataforma vSphere.
2. vCenter
Camada de gerenciamento; sua indisponibilidade não implica perda dos VMDKs.
3. Datastore
Abstração de storage apresentada aos hosts.
4. VMFS
Filesystem clustered para datastores de bloco.
5. LVM header
Faz parte da identificação do VMFS e pode ser sobrescrito.
6. VOMA
Ferramenta de análise de metadata, não undelete universal.
7. VMDK descriptor
Arquivo pequeno que descreve o virtual disk e seus extents.
8. -flat.vmdk
Data extent de virtual disk em vários formatos VMFS.
9. delta.vmdk
Extent de snapshot vmfsSparse em muitos cenários.
10. sesparse.vmdk
Formato de snapshot usado no VMFS6.
11. VMX
Configuração da máquina virtual.
12. VMSD
Database de snapshot information.
13. VMSN
Snapshot state/config, opcionalmente memória.
14. CID
Content ID do virtual disk descriptor.
15. parentCID
CID esperado do parent pelo child.
16. parentFileNameHint
Hint do parent VMDK no descriptor do child.
17. Snapshot chain
Relação parent-child que define o current disk state.
18. Consolidation
Operação oficial para commit de deltas em uma chain íntegra.
19. 32 snapshots
Máximo suportado em chain segundo Broadcom.
20. 2 a 3 snapshots
Quantidade recomendada para melhor desempenho.
21. 72 horas
Retenção recomendada máxima de snapshot individual.
22. File locks
Backup/replication podem deixar locks que bloqueiam consolidation.
23. Missing descriptor
Pode ser recriado se o data file correto ainda existe.
24. Missing flat file
Broadcom não oferece método vSphere para recriar os dados; backup/recovery é necessário.
25. VMFS Inaccessible
Pode ser path, partition, metadata ou storage.
26. APD
All Paths Down, perda de todos os paths sem certeza inicial de permanência.
27. PDL
Permanent Device Loss, perda permanente informada pelo storage.
28. vSAN
Distributed storage de objetos conforme policy.
29. vSAN objects
Podem ficar degraded, absent, inaccessible ou resyncing.
30. Repair delay
Por padrão 60 minutos para certas host failures; não acelera resync já iniciado.
31. Delete Datastore
Ação destrutiva quando seguida de nova criação na mesma área.
32. New Datastore
Não deve ser criado sobre LUN com lost data a recuperar.
33. Accidental ESXi install
Pode sobrescrever VMFS partition e headers.
34. Fibre Channel
Path/zoning/HBA podem retirar LUN sem apagar blocos.
35. iSCSI
Network/target/MPIO podem causar APD.
36. NFS
Storage connectivity e locks influenciam VMs e consolidation.
37. RAID local
Pode estar abaixo do VMFS e exigir recuperação primeiro.
38. RAID 5
Paridade simples.
39. RAID 6
Dupla paridade.
40. RAID Low Level
Ordem, stripe, offsets, parity e metadata.
41. PC-3000
Quando mídia suportada possui falha física/firmware.
42. Sala limpa ISO-5
Quando HDD mecânico exige intervenção física.
43. WinHex
Auxilia inspeção hexadecimal de LUN/VMFS/VMDK e RAID.
44. Ransomware
Pode atingir VMDK, VMX, backups e datastore.
45. Backup
Snapshot não substitui backup.
46. Remote recovery
Casos lógicos estáveis podem ser analisados remotamente.
47. Second opinion
Tentativas anteriores precisam ser documentadas.
48. Matriz técnica de decisão
| Sintoma | Camada | Prioridade | Evitar |
|---|---|---|---|
| VMFS Inaccessible | LUN/VMFS | preservar LUN + logs | New Datastore |
| VMDK descriptor missing | VMDK descriptor | validar flat/tamanho | criar descriptor sem contexto |
| CID mismatch | snapshot chain | mapear descriptors | consolidate cego |
| vSAN inaccessible | objects/components | preservar topology | remover components por tentativa |
| APD/PDL | storage path | validar storage/connectivity | formatar LUN |
| RAID degraded | camada física | diagnosticar/clonar | rebuild repetido |
49. Conclusão técnica
Recuperação VMware exige distinguir storage, VMFS, VMDK, snapshot chain e guest filesystem. A melhor estratégia preserva a LUN e os arquivos antes de operações com escrita. Em muitos casos lógicos, a análise pode começar remotamente em qualquer região do Brasil.
Referências utilizadas para validar este guia
- Broadcom: VMFS Inaccessible / Missing LVM Magic
- Broadcom: snapshot best practices
- Broadcom: recreating missing VMDK descriptor
- Broadcom: recreating snapshot descriptor
- Broadcom: CID mismatch
- Broadcom: APD / PDL
- Broadcom: vSAN repair delay and resync
- Broadcom: vSAN inaccessible objects
- Broadcom: deleting VMFS datastore and recreating volume
- Broadcom: ESXi installed on shared LUN
- X-Ways: WinHex
