O VMware armazena máquinas virtuais em um conjunto de arquivos dentro de um datastore formatado com VMFS. Cada arquivo tem uma função crítica — a perda ou corrupção de qualquer um deles pode tornar a VM completamente inacessível.
Arquivo texto de poucos KB com os metadados do disco virtual — geometria, versão, caminho do -flat.vmdk. Se corrompido ou deletado, a VM não abre. Recriamos manualmente com base nos dados do -flat.
O disco virtual propriamente dito — pode ter centenas de GBs. Contém o filesystem interno da VM (NTFS, ext4, etc.). Trabalhamos diretamente neste arquivo mesmo sem o descriptor ou o ESXi.
Arquivo texto com todas as configurações da VM: RAM, CPUs, adaptadores de rede, dispositivos, versão de hardware virtual. Necessário para recriar a VM em outro host após recuperação.
Dump da memória RAM da VM no momento do snapshot. O .vmsn contém o estado completo incluindo registradores de CPU. Presente apenas quando a VM foi snapshotada com a memória.
Cada snapshot cria um -delta.vmdk que armazena as mudanças em relação ao disco base. Cadeia longa de snapshots degrada performance e aumenta risco — consolidação interrompida é um dos casos mais críticos.
Estado da BIOS/UEFI virtual da VM — sequência de boot, configurações de hardware virtual. Arquivo pequeno (poucos KB) mas necessário para boot correto da VM recuperada.
Falha no header do volume VMFS, corrupção do heartbeat region ou falha de LUN. O datastore desaparece do vCenter/ESXi mas os dados ainda estão no storage.
Acúmulo excessivo de snapshots (-delta.vmdk), corrupção da cadeia delta ou consolidação interrompida. VM fica presa em "locked" ou inacessível.
O .vmdk descriptor é texto de poucos KB. Se corrompido ou deletado, o vSphere não consegue mapear o -flat.vmdk. Recriamos o descriptor manualmente com base nos dados do -flat.
Falha de disco no array do host. Recuperamos o VMFS de configurações RAID degradadas ou reconstruímos o layout após falha catastrófica no storage subjacente.
O Hyper-V usa arquivos .vhd (formato legado) ou .vhdx (formato atual, suporta até 64TB, journaling para proteção contra corrupção) para armazenar discos virtuais. Checkpoints (snapshots) geram arquivos .avhd/.avhdx (automatic virtual hard disk).
Cenários de falha em Hyper-V:
O VHDX tem um header duplo (para tolerância a falhas) e uma metadata region. Se ambas as cópias do header se corrompem, o arquivo não abre. Reconstruímos a metadata manualmente.
Deleção acidental de um .avhdx no meio da cadeia, interrupção durante merge de checkpoint ou VM importada sem os arquivos de checkpoint correspondentes.
Em clusters Hyper-V, falha do CSV pode tornar múltiplas VMs inacessíveis. Recuperamos o volume e as VMs sem perda de dados das VMs que estavam paradas.
O Block Allocation Table (BAT) do VHD dinâmico mapeia blocos lógicos para posições físicas. Corrupção do BAT resulta em dados ilegíveis. Reconstruímos o BAT por análise do layout físico.
O Proxmox VE usa principalmente dois formatos de disco virtual: QCOW2 (QEMU Copy On Write v2 — suporta snapshots e compressão) e raw (imagem direta de disco). Para storage, suporta LVM, ZFS, Ceph e diretórios locais.
Problemas comuns em Proxmox:
Para recuperação de QCOW2, utilizamos qemu-img check e qemu-img convert para extração dos dados brutos, contornando a tabela L1/L2 corrompida por análise direta do layout de clusters no arquivo.
O Nutanix AHV armazena VMs no Nutanix Distributed Storage Fabric (DSF), um sistema de armazenamento distribuído proprietário. A recuperação em ambientes Nutanix exige trabalho com o AOS (Acropolis OS), análise dos vDisks e do Curator para identificar dados corrompidos ou inacessíveis.
Para Citrix Hypervisor (XenServer), trabalhamos com o formato VHD/VDI no Storage Repository (SR), recuperação de SRs inacessíveis via xe sr-repair e extração direta de VHDs do LVM-over-iSCSI.
Diagnóstico gratuito em até 2 horas. Cobrança somente com resultado confirmado. Não tome decisões sem antes falar com um especialista.
Primeiro, NÃO tente deletar o arquivo de lock (.lck) manualmente em um ambiente de produção sem saber a causa — isso pode corromper dados. Verifique se há outro host tentando acessar o arquivo, reinicie o management agent (não o host) via SSH e verifique logs em /var/log/vmkernel.log. Se o problema persistir, entre em contato conosco antes de qualquer ação adicional.
Depende do que foi feito. Se apenas removida do inventário (sem deletar arquivos), os VMDKs ainda estão no datastore e podem ser reregistrados. Se deletada com "Delete from Disk", os arquivos foram removidos do VMFS — mas o VMFS não sobrescreve dados imediatamente, e com carving de baixo nível é possível recuperar os VMDKs se o espaço não foi realocado.
Quando a consolidação de snapshot é interrompida (queda de energia, falta de espaço, timeout), a cadeia de delta pode ficar inconsistente. Nossa abordagem: mapear manualmente a cadeia de arquivos -delta.vmdk, identificar o ponto de inconsistência, reconstruir a cadeia de dados e extrair o estado mais recente consistente da VM.
Para VMware: todos os arquivos do diretório da VM (.vmdk, -flat.vmdk, -delta.vmdk, .vmx, .vmsd). Para Hyper-V: o .vhdx principal e todos os .avhdx da cadeia de checkpoint + o arquivo .xml de configuração. Para Proxmox: o arquivo .qcow2 e o arquivo de configuração /etc/pve/qemu-server/VMID.conf. O diagnóstico identifica o problema sem risco adicional de perda.
O VMFS (VMware File System) é um filesystem de cluster desenvolvido especificamente para armazenamento compartilhado. Diferente do NTFS ou ext4, o VMFS foi projetado para acesso simultâneo por múltiplos hosts ESXi — por isso utiliza um sistema de locking distribuído via SCSI Reservations ou ATS (Atomic Test & Set).
A estrutura do VMFS5/VMFS6 é composta por:
Magic number, UUID do volume, versão do VMFS, tamanho do volume e ponteiros para as estruturas de metadados. Se corrompido, o ESXi não reconhece o datastore — mas pode ser reconstruído.
Armazena metadados dos arquivos — nome, tamanho, permissões e blocos alocados. A FDC tem redundância no VMFS6, tornando recuperação mais confiável mesmo com corrupção parcial.
Estrutura de alocação de blocos que mapeia offsets lógicos do arquivo para posições físicas no LUN. Arquivos VMDK grandes usam múltiplos níveis de pointer blocks.
Área usada para coordenação de acesso entre múltiplos hosts. Em datastores locais, a corrupção da heartbeat region pode tornar o volume inacessível, mas os dados permanecem intactos.
Em clusters vSphere com HA e DRS habilitados, uma falha de VM pode desencadear comportamentos automáticos que complicam a recuperação:
Nossa orientação: desabilite temporariamente o HA restart para a VM afetada antes de iniciar diagnóstico. Isso preserva o estado atual e evita ações automáticas que podem complicar a recuperação.
Empresa de médio porte com vSphere 7 perdeu acesso a datastore de 8TB após falha de controladora SAN. 23 VMs tornaram-se inacessíveis simultaneamente. Diagnóstico revelou corrupção do Volume Header do VMFS6. Reconstruímos o header a partir do backup interno do VMFS, restaurando acesso a 21 das 23 VMs integralmente. As 2 restantes (com corrupção em flat.vmdk) tiveram recuperação parcial de 85% dos dados via carving. Tempo total: 36 horas.
VM de servidor de arquivos com 2TB de dados teve o VHDX criptografado por LockBit 3.0 — mas a criptografia foi interrompida após 40 minutos (detecção pelo EDR). Os primeiros 512KB de cada arquivo dentro da VM estavam criptografados, mas a estrutura NTFS interna estava íntegra. Montamos o VHDX como read-only, recuperamos 78% dos arquivos completos e 15% parcialmente (arquivos pequenos, totalmente criptografados). Tempo: 5 dias para 2TB.
Antes de nos contatar, você pode executar estes comandos via SSH no ESXi para coletar informações de diagnóstico (sem risco de perda de dados):
Com a migração para cloud pública, cenários de recuperação envolvem formatos e protocolos específicos de cada plataforma:
VMs Azure usam VHD/VHDX em Managed Disks (Page Blobs). Exportamos o VHD via azcopy, trabalhamos localmente e reimportamos. Snapshots Azure Backup corrompidos são tratados via REST API do Recovery Services Vault.
VMs EC2 usam EBS (Elastic Block Store) baseado em imagens RAW. Exportamos via VM Import/Export para S3 em formato VMDK, OVA ou VHD e trabalhamos localmente.
GCP usa Persistent Disks com imagens RAW. Exportamos para Cloud Storage em formato de imagem, fazemos download e trabalhamos em cópia local sem custo adicional de egress em recuperação de emergência.
Em ambientes corporativos, os datastores VMware são frequentemente apresentados via protocolos de storage em rede. Cada protocolo tem comportamentos específicos em falha:
Falha de rede em iSCSI pode causar APD (All Paths Down) no ESXi, levando VMs ao estado "paused". Quando a conectividade retorna, verificamos integridade do VMFS pois escritas incompletas durante APD podem causar corrupção.
Datastores NFS são especialmente sensíveis a timeouts. Corrupção pode ocorrer se o servidor NFS ficar indisponível durante uma operação de escrita do VMkernel. NFS v4.1 com pNFS reduz mas não elimina este risco.
FC é o protocolo mais confiável para datastores VMware. Falhas ocorrem principalmente em LUN masking incorreto, fabric reconfiguration ou HBA failure. PDL (Permanent Device Loss) pode deixar VMs ativas em estado irrecuperável sem acesso ao storage.
O VMware vSAN é uma solução hyperconvergida que usa os discos locais dos hosts ESXi para criar um pool de storage distribuído. Os dados são armazenados em componentes distribuídos entre os hosts segundo uma Fault Tolerance Policy (FTT).
Repositórios corrompidos, restore points inválidos, chains quebradas de incrementais
CommCell database corrompido, media agents inacessíveis, recovery sem CommCell
Catálogo NBU corrompido, tape restore com fita danificada, policy recovery
VPGs com checkpoints corrompidos, journal degradado, failover de test sem cleanup
Protection groups com VMs em estado de erro, failover incompleto, reprotect falho
Arquivos .tib/.tibx corrompidos, backup chain quebrada, agente sem comunicação com servidor
O erro "Cannot open the disk or one of the snapshot disks it depends on" geralmente indica: (1) arquivo de lock .lck presente de outro host, (2) arquivo descriptor .vmdk com referência incorreta ao -flat.vmdk, (3) cadeia de snapshots quebrada. Diagnóstico em 30 minutos via acesso remoto ao ESXi. Não delete o .lck sem entender a causa — pode corromper dados em VMs ativas.
Sim. Trabalhamos diretamente com os arquivos VMDK sem necessidade do ESXi em funcionamento. O -flat.vmdk contém os dados brutos do disco virtual — podemos montá-lo em ambiente isolado, analisar o filesystem interno (NTFS, ext4) e extrair os dados. Para isso, precisamos do -flat.vmdk e do arquivo descriptor .vmdk (arquivo texto de alguns KB).
Para VHDX corrompido, primeiro tentamos o repair nativo (Hyper-V Manager → Edit Disk → Repair). Se falhar, trabalhamos na estrutura interna do VHDX: analisamos o cabeçalho (Metadata Region), reconstruímos o Block Allocation Table (BAT) se necessário e extraímos os dados das data blocks íntegros. Para cadeias de checkpoints (.avhdx), mapeamos manualmente a hierarquia e extraímos o estado mais recente consistente.
O diagnóstico é concluído em até 2 horas. Para uma VM de 1TB com descriptor corrompido (problema simples), a recuperação pode ser feita em 4 a 8 horas. Para casos que exigem carving completo do VMDK (1TB), o processo leva de 2 a 5 dias úteis dependendo da velocidade de transferência e complexidade. Casos urgentes com SLA de 24h estão disponíveis para ambientes corporativos críticos.
Falha na consolidação de snapshot é um dos casos mais comuns que atendemos. Causas: espaço insuficiente no datastore durante a consolidação, timeout do VMkernel, corrupção parcial de um arquivo -delta.vmdk. Nossa abordagem: mapeamos toda a cadeia de snapshots manualmente, identificamos o ponto de falha, reconstruímos os dados da cadeia sem perder o estado atual da VM, e consolidamos cirurgicamente. Não use "Delete All Snapshots" sem diagnóstico — pode deixar a VM irrecuperável.
Sim. O QCOW2 (QEMU Copy On Write 2) tem estrutura com L1/L2 tables para mapeamento de clusters. Corrupção nas L-tables impede a leitura de clusters de dados, mas os próprios clusters frequentemente estão íntegros. Usamos qemu-img check para diagnóstico, qemu-img convert para extração de dados brutos contornando as tables corrompidas, e análise direta do layout físico do arquivo quando necessário.
Diagnóstico gratuito em 2h · VMware, Hyper-V, Proxmox, Nutanix · Atendimento 24h
O KVM (Kernel-based Virtual Machine) com QEMU é o hypervisor padrão em ambientes Linux corporativos, usado diretamente ou como base para Proxmox, oVirt e Red Hat Virtualization. Os formatos de disco mais comuns:
Imagem 1:1 do disco. Mais simples de recuperar — montamos diretamente com losetup + kpartx e acessamos as partições. Sem overhead de metadados que possam se corromper.
Suporta snapshots e compressão, com L1/L2 tables de alocação. Corrupção de L-tables impede leitura — contornamos via qemu-img convert -p -f qcow2 -O raw com recuperação de clusters íntegros.
Quando snapshots são usados como backing chain (arquivo base + deltas), a perda de um arquivo da cadeia pode tornar os demais ilegíveis. Reconstruímos a cadeia e extraímos os dados disponíveis.
VMs em LVM thin podem ter snapshots corrompidos ou pool thin com metadados inválidos. Recuperamos os chunks de dados diretamente do pool, contornando os metadados LVM danificados.
Após recuperar o disco virtual (VMDK, VHDX, QCOW2), frequentemente é necessário recuperar dados do filesystem interno da VM. Trabalhamos com todos os sistemas de arquivos comuns:
Windows Server VMs. MFT corruption, $MFTMirr recovery, NTFS journal analysis, cluster bitmap repair.
Linux VMs. Superblock recovery (múltiplas cópias), journal replay, inode table reconstruction, e2fsck.
CentOS/RHEL VMs. AGF/AGI/AGFL recovery, xfs_repair, log reset, allocation group rebuild.
Ubuntu/Fedora VMs modernas. B-tree recovery, subvolume scan, btrfs check --repair, chunk tree rebuild.
VMs macOS (Parallels, VMware Fusion). Container recovery, Checkpoint map repair, sealed volume handling.
VMs legadas ou partições de dados. FAT table recovery, cluster chain rebuild, directory entry reconstruction.
| Ferramenta | Plataforma | Aplicação |
|---|---|---|
| vmkfstools | VMware ESXi | Cloning, repair e validação de VMDKs |
| vSphere Data Recovery | VMware vSphere | Recovery de VMs a partir de backups vDR |
| qemu-img convert | QEMU/KVM/Proxmox | Conversão e extração de QCOW2/raw |
| Hyper-V Manager + diskpart | Hyper-V | Mount de VHDX, repair de metadata region |
| VHD Tool (Microsoft) | Hyper-V | Inspeção e reparo de VHD/VHDX corrompidos |
| R-Studio / TestDisk | Todos | File carving dentro de discos virtuais montados |
| FTK Imager | Todos | Imagem forense de VMDKs e VHDs para análise |
| esxcli / vim-cmd | VMware ESXi | Diagnóstico remoto via SSH sem vCenter |
Nenhum, quando o processo é feito corretamente. Sempre criamos uma imagem forense do disco virtual antes de qualquer operação — trabalhamos sempre na cópia, nunca no original. O arquivo original permanece intacto. Isso permite múltiplas tentativas com técnicas diferentes sem risco adicional.
Depende do uso do datastore desde a deleção. O VMFS não sobrescreve os dados de uma VM deletada imediatamente — apenas libera o espaço para reutilização. Se o espaço não foi realocado (novas VMs criadas, arquivos copiados), os VMDKs podem ser recuperados por carving do filesystem VMFS. Quanto mais cedo o diagnóstico, maiores as chances.
Conceda acesso SSH ao host ESXi ou acesso ao vCenter via VPN. Nossa equipe realiza diagnóstico inicial sem mover dados (apenas leitura de logs e metadados). Se a recuperação puder ser feita remotamente (descriptor repair, lock removal, snapshot consolidation), resolvemos sem necessidade de transferir os arquivos. Para casos que exigem trabalho nos arquivos, solicitamos acesso ao storage via SCP/SFTP ou recebemos os discos físicos.
Diagnóstico gratuito. Resposta em até 2 horas. Cobrança somente com resultado confirmado. Não tome decisões sem antes falar com um especialista.