O que é Recuperação de VM?
A recuperação de máquina virtual é o processo de restaurar sistemas e dados armazenados em ambientes virtualizados, como VMware ESXi, Microsoft Hyper-V, Proxmox e VirtualBox, quando há falhas físicas, lógicas ou exclusões acidentais. Esse processo permite recuperar VMs que ficaram inacessíveis, corrompidas, deletadas ou cujo datastore VMFS foi danificado.
Esses ambientes utilizam arquivos de disco virtual — como VMDK, VHD, VHDX, VDI ou QCOW — que podem sofrer danos devido a falhas em discos, problemas em storages NAS/SAN, degradação de RAID, queda de energia, travamento do hipervisor, defeitos no ESXi ou ataques cibernéticos.
O trabalho de recuperação envolve a análise da estrutura do arquivo virtual, reconstrução de volumes, extração dos dados e validação da integridade das informações. Em situações mais complexas, também é necessária a atuação no nível do storage ou do conjunto RAID onde os datastores estão armazenados.
A E-Recovery é especializada nesse tipo de recuperação corporativa, utilizando técnicas avançadas de engenharia reversa, equipamentos profissionais e procedimentos seguros para restaurar ambientes virtuais críticos com total confidencialidade e alta taxa de sucesso.
O que fazer quando seu Datastore VMFS/CSV ou Ambiente Virtualizado para de funcionar?
Uma falha em ambientes virtualizados — como VMware ESXi, Microsoft Hyper-V, XenServer ou Proxmox — é um dos cenários mais críticos para qualquer empresa. Em muitos casos, o impacto não é apenas a perda de uma VM, mas a paralisação de servidores inteiros: Controladores de Domínio, Banco de Dados SQL, Aplicações ERP e sistemas essenciais.
Na maioria das vezes, a queda de uma VM acontece como um desastre em duas camadas:
1) Camada Física (Hardware)
Ocorre quando há falhas no RAID, no servidor Dell/HP/Lenovo, no storage HPE, QNAP ou Synology — ou até mesmo no disco onde o datastore está armazenado.
2) Camada Lógica (Sistema de Arquivos da VM)
É quando o Datastore VMFS, o Volume CSV (Hyper-V) ou os arquivos VMDK/VHDX ficam inacessíveis, corrompidos ou desaparecem.
Essa combinação torna o cenário altamente delicado — e toda ação precipitada pode destruir as chances de recuperação.
Veja o que não fazer!
❌ 1) NÃO recrie o datastore (VMFS/CSV)!
Quando o datastore some, é tentador clicar em Create New Datastore no vSphere/Hyper-V Manager.
Isso é destrutivo.
O comando formata o LUN e elimina os metadados originais — apagando os ponteiros dos arquivos .VMDK, .VHDX, snapshots e toda a estrutura lógica.
➡ Resultado: recuperação se torna impossível.
❌ 2) NÃO rode CHKDSK / FSCK no volume!
Se o volume CSV/NTFS aparecer como RAW, Corrompido ou pedir “verificação”, não execute CHKDSK.
Ele pode interpretar o volume como danificado e simplesmente deletar arquivos VHDX/VMDK que considera inválidos.
➡ Resultado: perda permanente de múltiplas VMs.
☎️ 3) Desligue o host/storage e fale com especialistas
A atitude mais segura é desligar imediatamente o servidor ESXi/Hyper-V ou o storage que contém os LUNs.
Isso impede sobrescritas e evita danos adicionais.
Nossos engenheiros são especialistas em engenharia reversa de VMFS, CSV e storages NAS/SAN que utilizam RAID.
Oferecemos diagnóstico rápido e gratuito para preservar a integridade dos dados e aumentar as chances de recuperação.
Especialistas em Todas as Plataformas de Virtualização
A E-Recovery é referência nacional em recuperação de dados de ambientes virtualizados, atuando com VMware ESXi/vSphere, Microsoft Hyper-V, Citrix XenServer, Proxmox VE, VirtualBox, KVM/QEMU e infraestruturas híbridas.
Nossos engenheiros utilizam técnicas avançadas de engenharia reversa, equipamentos profissionais e laboratório próprio para lidar com os ambientes virtuais mais complexos. Recuperamos dados de sistemas de arquivos como VMFS (VMware), ReFS/NTFS (Hyper-V), EXT4/XFS/ZFS (Linux/Proxmox/KVM) e LVM, mesmo em cenários com RAID, SAN, LUNs corrompidas, discos RAW ou storages inacessíveis.
Plataformas que recuperamos:
Recuperação de VMware (ESXi, vSphere, VMFS)
Seu Datastore VMFS está “Offline”, “Inacessível” ou “Corrompido”? Suas VMs (.VMDK) sumiram? Não tente “recriar” o datastore! Somos especialistas forenses em reconstrução de VMFS.
O seu ambiente VMware (ESXi, vSphere, vSAN) está apresentando algum destes sintomas?
🚫 Datastore VMFS Inacessível – O host ESXi não “vê” mais o Datastore. Ele pode aparecer como “Inativo” (Inactive) ou simplesmente ter desaparecido da lista de armazenamento.
📂 Arquivos .VMDK / .VMDK-flat Sumiram – A pasta do datastore está vazia, ou os arquivos principais das suas VMs (os “discos rígidos virtuais” .vmdk e -flat.vmdk) desapareceram.
💾 Datastore “RAW” (Pede Formatação) – O vSphere/vCenter vê o LUN (o disco do Storage), mas o identifica como “RAW” (Bruto) ou “Não Formatado”, e se oferece para formatá-lo com um novo VMFS.
❌ VM “Corrompida” ou “Órfã” – A Máquina Virtual não liga e dá um erro de “arquivo não encontrado”, “disco corrompido” ou “a cadeia de snapshots (delta.vmdk) está quebrada”.
Entendendo a Falha do Datastore VMFS (A Dupla Camada)
O VMFS (Virtual Machine File System) é o sistema de arquivos de alta performance da VMware. A perda de um Datastore VMFS é quase sempre um desastre de duas camadas:
Camada de Hardware (O RAID/Storage): Primeiro, o hardware (Servidor Dell, Storage HPE, NAS Synology) falhou. O RAID 5 quebrou (2 discos falhos), o RAID 6 falhou (3 discos falhos), a LUN do Storage (iSCSI/FC) ficou offline, ou o pool ZFS/SHR corrompeu.
Camada Lógica (O VMFS): O “mapa” (metadados) do próprio VMFS, que estava “em cima” desse RAID quebrado, agora está corrompido ou inacessível.
Seus arquivos .VMDK (suas VMs) estão “fatiados” pelo RAID e “presos” dentro de um sistema de arquivos (VMFS) que está “quebrado”.
⚠️ A REGRA DE OURO: NÃO TENTE “RECRIAR” O DATASTORE (VMFS)!
Quando um Datastore VMFS desaparece, a primeira reação de um administrador de TI é usar o vSphere para “Criar um novo Datastore” no LUN que parece estar vazio. NÃO FAÇA ISSO JAMAIS!
Isso formata o LUN e apaga os metadados (o “mapa”) do VMFS original, destruindo os ponteiros para todos os seus arquivos .VMDK. Esta ação zera as chances de recuperação. Da mesma forma, não rode vmfs-tools ou fsck em um volume instável.
Perguntas Frequentes (FAQ): Recuperação de VMware (VMFS)
1. O RAID 5 do meu servidor falhou. A recuperação das VMs é diferente de uma recuperação de arquivos normal? Sim, muito. Em uma recuperação de arquivos normal (ex: fotos, documentos), buscamos arquivos individuais. Em uma recuperação de VMware, o objetivo é recuperar os arquivos de disco virtual (ex: NomeDaVM-flat.vmdk, .vmdk de snapshot, e o arquivo .vmx de configuração) com 100% de integridade. Nosso objetivo não é recuperar “arquivinhos”, mas sim a Máquina Virtual inteira e funcional.
2. O que é um arquivo “-flat.vmdk” e por que ele é importante? O arquivo .vmdk que você vê no VMware é apenas um “descritor” (um pequeno arquivo de texto). Os seus dados reais (o disco C: da sua VM) estão em um arquivo grande e oculto chamado NomeDaVM-flat.vmdk . A recuperação se concentra em encontrar e reconstruir este arquivo “-flat”.
3. O vSphere está me oferecendo para “Criar um novo Datastore” no disco. Devo? NÃO. NUNCA. Esta é a “armadilha” mais comum. “Criar um novo Datastore” é o mesmo que formatar. Isso apaga o “mapa” (metadados) do VMFS original. Mesmo que os dados ainda estejam fisicamente nos discos, encontrar os arquivos .vmdk (que podem ter 2TB e estar fragmentados) se torna quase impossível.
4. Como a E-Recovery recupera minhas VMs VMware? Nosso processo é uma recuperação de “múltiplas camadas”:
Clonagem: Clonamos (bit-a-bit) todos os discos do servidor ou storage.
Remontagem do RAID (Camada 1): Fazemos a engenharia reversa da controladora (Dell PERC, HPE Smart Array, LSI) ou do sistema (SHR, ZFS) para remontar virtualmente o seu RAID 5, 6, 10, etc.
Reparo do Datastore (Camada 2): No RAID virtual, usamos software forense para escanear e reparar o sistema de arquivos VMFS (mesmo que os metadados estejam destruídos).
Extração dos Arquivos VM: Extraímos os arquivos .VMDK /
-flat.vmdk/.vmxintactos, prontos para você “importar” em um novo servidor e voltar à produção.
Recuperação de Hyper-V (Servidor / CSV / VHDX)
Seu Volume Compartilhado (CSV) está “Offline”? Seus discos VHD/VHDX sumiram? Não rode o CHKDSK! Somos especialistas em reparar volumes NTFS/ReFS e recuperar VMs Hyper-V.
O seu ambiente Microsoft Hyper-V está apresentando algum destes sintomas?
🚫 Volume CSV Inacessível – O “Volume Compartilhado Clusterizado” (Cluster Shared Volume) está “Offline” ou “Redirecionado” (Redirected Access) e todas as VMs pararam.
📂 Arquivos .VHD / .VHDX Sumiram – A pasta do volume (ex: C:\ClusterStorage\Volume1\) está vazia, ou os arquivos de disco virtual (.vhd ou .vhdx) desapareceram.
💾 Volume “RAW” (Pede Formatação) – O Windows Server (onde o Hyper-V está) vê o disco/LUN como “RAW” (Bruto) ou “Não Formatado”, e se oferece para formatá-lo.
❌ VM “Corrompida” ou “Falha ao Iniciar” – A Máquina Virtual não liga e dá um erro de “arquivo não encontrado”, “disco corrompido” ou “a cadeia de snapshots (avhdx) está quebrada”.
Entendendo a Falha do Datastore Hyper-V (A Dupla Camada)
Assim como no VMware, a perda de dados no Hyper-V é um desastre de duas camadas:
Camada de Hardware (O RAID/Storage): Primeiro, o hardware (Servidor Dell, Storage HPE, NAS Synology) falhou. O RAID 5 quebrou (2 discos falhos), o RAID 6 falhou (3 discos falhos), ou a LUN do Storage (iSCSI/FC) ficou offline.
Camada Lógica (O Filesystem): O “mapa” que estava “em cima” desse RAID quebrado agora está inacessível. O Hyper-V usa sistemas de arquivos padrão do Windows (NTFS ou ReFS) e, em clusters, o CSV (Cluster Shared Volume). Se esse “mapa” (NTFS/ReFS) se corromper, o Windows não consegue mais “montar” o volume.
Seus arquivos .VHDX (suas VMs) estão “fatiados” pelo RAID e “presos” dentro de um sistema de arquivos (NTFS/ReFS) que está “quebrado”.
⚠️ A REGRA DE OURO: NÃO RODE O CHKDSK (VERIFICADOR DE DISCO)!
Quando um volume NTFS ou ReFS (onde suas VMs estão) aparece como “RAW” ou “Corrompido”, a primeira reação de um administrador de Windows Server é rodar o comando CHKDSK /F ou CHKDSK /R. NÃO FAÇA ISSO JAMAIS!
O CHKDSK foi feito para consertar o volume, não para salvar dados. Ele pode encontrar os arquivos .VHDX (que são arquivos gigantescos de 2TB) e interpretá-los como “corrompidos” ou “órfãos”. O CHKDSK pode DELETAR esses arquivos ou “consertá-los” de forma destrutiva, apagando suas VMs permanentemente para “salvar” o volume.
Perguntas Frequentes (FAQ): Recuperação de Hyper-V (VHDX/CSV)
1. Qual a diferença entre recuperar VMware (VMFS) e Hyper-V (NTFS/ReFS)? O VMFS (VMware) é um sistema de arquivos de cluster, 100% proprietário. O Hyper-V (Microsoft) usa sistemas de arquivos que também rodam no Windows (NTFS e ReFS). Embora o NTFS pareça “mais simples”, a forma como o Hyper-V “trava” os arquivos (especialmente em um Volume Compartilhado Clusterizado – CSV) e a estrutura dos discos .VHDX (com seus snapshots .avhdx) cria uma camada de complexidade única que exige ferramentas forenses específicas.
2. O que é um arquivo “.VHDX” e “.AVHDX”?
.VHDX: É o “disco rígido virtual” da sua VM (ex: o disco C: do seu servidor virtual).
.AVHDX: É um snapshot (ponto de verificação). Quando você cria um snapshot, o Hyper-V para de escrever no .VHDX principal e começa a escrever as alterações nesse novo arquivo .avhdx. A VM em funcionamento é uma “corrente” entre o disco original e todos os seus snapshots.
3. O que é um “CSV” (Volume Compartilhado Clusterizado) e por que ele falha? É a tecnologia da Microsoft que permite que vários servidores (hosts) Hyper-V acessem o mesmo disco (LUN) ao mesmo tempo. A falha ocorre quando o “nó” (servidor) que é o “dono” do CSV falha, ou quando os metadados do NTFS/ReFS “por baixo” do CSV se corrompem (geralmente por uma falha de RAID no Storage).
4. Como a E-Recovery recupera minhas VMs Hyper-V? Nosso processo é uma recuperação de “múltiplas camadas”:
Clonagem: Clonamos (bit-a-bit) todos os discos do servidor ou storage que hospedava as VMs.
Remontagem do RAID (Camada 1): Fazemos a engenharia reversa da controladora (Dell PERC, HPE Smart Array, etc.) para remontar virtualmente o seu RAID 5, 6, 10, etc.
Reparo do Filesystem (Camada 2): No RAID virtual, usamos software forense para reparar a estrutura do NTFS ou ReFS.
Reconstrução da Corrente (Camada 3): Se houver snapshots (.avhdx), nós analisamos os metadados para “juntar” a corrente (o .vhdx principal + todos os seus snapshots .avhdx) na ordem correta, “fundindo-os” para criar o estado mais recente da VM.
Extração: Extraímos os arquivos .VHDX e .AVHDX intactos, prontos para você “importar” em um novo servidor.
Recuperação de Citrix XenServer / Hypervisor (LVM/VHD)
Seu Storage Repository (SR) está “Broken” ou “Unplugged”? Seus discos .VHD sumiram? Não tente “Reparar” o SR! Somos especialistas em reconstrução de volumes LVM e cadeias VHD.
O seu ambiente Citrix XenServer (ou Xen Hypervisor) está apresentando algum destes sintomas?
🚫 SR “Broken” (Quebrado) – O XenCenter (ou Xen Orchestra) mostra o “Storage Repository” (SR) como “Broken” (Quebrado) ou “Unplugged” (Desconectado) e se recusa a “reconectar” ou “reparar”.
📂 Discos .VHD Sumiram – As VMs estão “órfãs” (com um X vermelho), e os discos virtuais (.vhd) não são encontrados no SR.
💾 LVM Corrompido – A LUN (Storage) que continha o SR está inacessível. O sistema (baseado em Linux) reporta erros de LVM (Logical Volume Manager) ou “Volume Group not found”.
❌ VM não Inicia – A VM falha ao iniciar com erros de “disco não encontrado” ou “a cadeia de snapshots VHD está quebrada” (VHD chain is broken).
Entendendo a Falha do XenServer (A Armadilha do LVM)
O XenServer (agora Citrix Hypervisor) é uma plataforma de virtualização de alta performance. Ao contrário do VMware (que usa VMFS), o XenServer usa uma camada de LVM (Logical Volume Management) do Linux para criar seus Storage Repositories (SRs). Os discos virtuais são armazenados no formato VHD (o mesmo do Hyper-V, mas “em cima” do LVM).
A falha ocorre quando o “mapa” (metadados) do LVM se corrompe. Isso quase sempre é um sintoma de uma falha de hardware na camada inferior (uma falha de RAID 5/6 no seu Servidor Dell/HPE ou no seu Storage). Uma queda de energia ou falha de disco pode “quebrar” o LVM, tornando todas as VMs dentro dele inacessíveis.
⚠️ A REGRA DE OURO: NÃO TENTE “REPAIR” O SR OU “FORMATAR O LUN”!
Se o seu Storage Repository (SR) está “Broken” (Quebrado), a interface XenCenter pode se oferecer para “Reparar” (Repair) ou “Recriar” (Re-create) o SR. NÃO FAÇA ISSO!
A função “Repair” é perigosa e pode apagar os metadados LVM na tentativa de “consertar” o volume. “Recriar” é o mesmo que formatar o LUN, destruindo a estrutura LVM e todos os seus arquivos .vhd permanentemente.
Perguntas Frequentes (FAQ): Recuperação de XenServer (LVM/VHD)
1. Qual a diferença entre recuperar VMware (VMFS) e XenServer (LVM/VHD)? A arquitetura é totalmente diferente. O VMFS é um sistema de arquivos de cluster. O XenServer usa uma camada de LVM (Logical Volume Manager) do Linux, que “fatia” o armazenamento de forma diferente. Os discos são VHD (o mesmo formato do Hyper-V, mas sobre LVM). A recuperação exige a engenharia reversa dessa camada LVM para remontar os volumes e acessar os VHDs.
2. O que é um “SR Quebrado” (Broken SR)? Significa que o XenServer não consegue mais ler o “mapa” (metadados LVM) do seu Storage Repository. Isso geralmente acontece por uma falha de RAID no Storage subjacente (Dell, HPE, etc.) ou por uma queda de energia que corrompeu os metadados LVM.
3. O que é uma “cadeia de snapshots” (VHD chain) quebrada? Assim como no Hyper-V, quando você cria um snapshot no XenServer, ele cria um disco de “diferença” (.VHD). A VM em funcionamento depende do disco original e de todos os seus snapshots. Se um desses links (ponteiros) se quebra ou corrompe, a VM não “monta” mais.
4. Como a E-Recovery recupera minhas VMs XenServer? Nosso processo é uma recuperação de “múltiplas camadas”:
Clonagem: Clonamos (bit-a-bit) todos os discos do servidor ou storage.
Remontagem do RAID (Camada 1): Fazemos a engenharia reversa da controladora (PERC, Smart Array, etc.) para remontar virtualmente o seu RAID 5, 6, 10, etc.
Reparo do LVM (Camada 2): No RAID virtual, usamos software forense para escanear e reparar a estrutura LVM do XenServer.
Reconstrução da Cadeia VHD (Camada 3): Identificamos e “juntamos” (merge) a cadeia de VHDs (disco principal + snapshots) na ordem correta.
Extração: Extraímos os arquivos .VHD intactos, prontos para você “importar” em um novo SR.
Recuperação de VirtualBox (VDI, VHD, VMDK)
Sua Máquina Virtual (VM) VirtualBox não “dá boot”? O disco virtual (.VDI) está corrompido? Não “descarte” os snapshots! Somos especialistas em reconstruir cadeias de discos VirtualBox.
O seu ambiente Oracle VM VirtualBox está apresentando algum destes sintomas?
❌ Erro “Guru Meditation” – Um erro crítico e fatal que faz a VM “quebrar” (crashar) imediatamente ao tentar iniciar.
🚫 Disco Virtual Corrompido (.VDI) – A VM falha ao iniciar com um erro de “não foi possível abrir o disco virtual”, “arquivo .VDI não encontrado” ou “disco corrompido”.
💾 Snapshots “Quebrados” – A VM não consegue “ligar” ou “restaurar” um snapshot, ou o disco principal e os arquivos de snapshot (.vdi ou .vmdk de diferença) perderam a “ligação”.
📂 Arquivos Sumiram (Dentro da VM) – A VM até liga, mas o sistema operacional “guest” (ex: Windows ou Linux dentro da VM) está corrompido, em modo RAW, ou pede para formatar.
Entendendo a Falha do VirtualBox (A Armadilha dos Snapshots)
O VirtualBox é a ferramenta de virtualização de desktop mais popular do mundo. A maioria das falhas ocorre por um de três motivos:
Falha no HD Hospedeiro: O HD (ou SSD) do computador real (o “hospedeiro”) onde os arquivos da VM estavam armazenados falhou (ex: bad blocks, modo RAW).
Erro de Snapshot: O VirtualBox usa um sistema de “snapshots” (pontos de verificação). Isso cria uma “corrente” de arquivos. Se um único arquivo (elo) dessa corrente for corrompido ou deletado, a VM inteira para de funcionar.
Corrupção do Arquivo .VDI: Uma queda de energia ou o computador “travar” pode corromper o arquivo .vdi (o “disco rígido virtual”) principal, tornando-o ilegível.
⚠️ A REGRA DE OURO: NÃO DELETE ARQUIVOS DE SNAPSHOT E NÃO “CRIE UM NOVO DISCO”!
Quando uma VM do VirtualBox falha, a primeira reação do usuário é tentar “limpar” a pasta da VM. Você pode ver vários arquivos .vdi (ex: {uuid}.vdi, {uuid}.vdi, etc.) e achar que são “lixo”.
NÃO APAGUE NADA! Esses arquivos são os snapshots (os elos da corrente). Se você apagar um snapshot “antigo”, você destrói permanentemente todos os dados que foram escritos depois dele.
Da mesma forma, NÃO tente “Criar um Novo Disco Virtual” e anexá-lo à VM, pois isso não recupera os dados antigos.
Perguntas Frequentes (FAQ): Recuperação de VirtualBox (VDI)
1. Qual a diferença entre recuperar um VirtualBox (VDI) e um VMware (VMDK)? Ambos são “discos virtuais”, mas o formato é diferente.
VMDK (VMware): Usa uma estrutura -flat.vmdk (dados) e .vmdk (descritor), e um sistema de arquivos de servidor (VMFS).
VDI (VirtualBox): Usa um formato de disco próprio (.vdi), que tem sua própria estrutura interna. Os snapshots também são .vdi. A recuperação exige ferramentas forenses que entendam a estrutura interna específica de um arquivo .vdi e como “fundir” (merge) a cadeia de snapshots.
2. Meu arquivo .VDI está em um HD externo que ficou RAW. E agora? Este é um problema de “duas camadas”. Seus arquivos .vdi (Camada 2) estão presos dentro de um HD (Camada 1) que está em RAW. O processo de recuperação é:
Primeiro, nós recuperamos os dados do HD RAW (como descrito na nossa página de HD), para salvar o arquivo .vdi intacto.
Segundo, se o arquivo .vdi também estiver corrompido (pela falha do HD), nós o reparamos.
3. O que é um “Guru Meditation Error”? É a “Tela Azul” do VirtualBox. É um erro fatal que o hipervisor não consegue resolver. Quase sempre é causado por um problema de baixo nível (como um arquivo .vdi corrompido) ou um conflito de hardware.
4. Como a E-Recovery recupera minhas VMs do VirtualBox? Nosso processo é focado em reconstruir o disco virtual:
Clonagem: Clonamos o HD hospedeiro onde os arquivos .vdi estavam (se a falha foi no HD).
Engenharia Reversa (Se o HD hospedeiro falhou): Recuperamos os arquivos .vdi e .vbox (configuração) do HD.
Reconstrução da Cadeia VDI (A Parte Difícil): Se a falha foi nos snapshots, nossos engenheiros analisam os arquivos .vox (XML) e os .vdi para descobrir a ordem correta da corrente (qual snapshot liga em qual).
Remontagem Virtual: Nós “fundimos” (merge) virtualmente o disco base com todos os seus snapshots na ordem correta para criar o estado mais recente da VM.
Extração: Montamos o arquivo .vdi final (já “fundido”) e extraímos seus arquivos e pastas.
Recuperação de Proxmox VE (KVM / ZFS / LVM)
Seu Pool ZFS (Proxmox) está “UNAVAIL” ou seu LVM-thin está “Inativo”? Não force o “zpool import”! Somos especialistas em recuperar VMs KVM (.qcow2, .raw) de ZFS e LVM.
O seu ambiente de virtualização KVM (Proxmox, RHV) está apresentando algum destes sintomas?
🚫 Pool ZFS “UNAVAIL” ou “FAULTED” – O Proxmox VE não consegue “importar” (import) o pool ZFS. O zpool status mostra o pool como “Degradado” (DEGRADED) com mais falhas do que a paridade (RAID-Z1/Z2) suporta.
💾 Volume LVM “Inativo” – O Storage LVM (ou LVM-thin) não é ativado no boot. O “Volume Group” (VG) não é encontrado e as VMs não iniciam.
❌ VM “Corrompida” (Erro de I/O) – A VM (KVM) não liga e dá um “erro de I/O” (Input/Output error) ao tentar acessar o disco virtual (.qcow2 ou .raw).
🖥️ Host Proxmox Não “Dá Boot” – O próprio servidor (host) Proxmox não inicia, geralmente por uma falha no disco de boot (que pode ter corrompido o grub ou o LVM).
Entendendo a Falha do Proxmox (O Desafio do ZFS e LVM)
O Proxmox VE (baseado no hipervisor KVM do Linux) é a plataforma open-source mais poderosa do mercado. Sua flexibilidade é sua maior força e sua maior complexidade na recuperação. A falha quase sempre ocorre no storage subjacente:
Falha de ZFS: A maioria das instalações modernas de Proxmox usa ZFS (com RAID-Z1/Z2). A falha ocorre quando o “pool” ZFS “quebra” (por falha de múltiplos discos, RAM defeituosa ou queda de energia).
Falha de LVM/LVM-thin: A outra configuração comum é usar LVM sobre um RAID de hardware (ex: Dell PERC). A falha ocorre quando os metadados do LVM (o “mapa” do Volume Group) se corrompem.
Em ambos os casos, os arquivos de disco virtual (.qcow2 ou .raw) ficam presos dentro de uma estrutura (ZFS ou LVM) que não “monta” mais.
⚠️ A REGRA DE OURO: NÃO TENTE “FORÇAR O POOL” (zpool import -f)!
Se o seu pool ZFS está UNAVAIL, a internet (e fóruns) vão sugerir que você rode o comando zpool import -f (forçar importação) ou zpool import -F (reverter transações). NÃO FAÇA ISSO JAMAIS!
Se o pool está instável (por discos falhando), “forçar” a importação pode corromper permanentemente os metadados (Uberblocks). Você pode “quebrar” a “árvore” de dados do ZFS e destruir 100% das suas VMs.
Perguntas Frequentes (FAQ): Recuperação de Proxmox (KVM)
1. Quais plataformas KVM vocês recuperam? Nós temos expertise em todas as principais plataformas baseadas em KVM:
Proxmox VE: (O mais comum) Incluindo storages ZFS (RAID-Z), LVM-thin e Ceph.
Red Hat Virtualization (RHV) / oVirt: Ambientes corporativos complexos.
Nutanix (AHV): O hipervisor da Nutanix (Acropolis Hypervisor) é baseado em KVM.
KVM/Linux Padrão: Ambientes customizados rodando QEMU/KVM.
2. Qual a diferença entre recuperar Proxmox com ZFS e Proxmox com LVM-thin? São recuperações totalmente diferentes:
ZFS (RAID-Z): É um processo forense de engenharia reversa do ZFS (para reconstruir os “Uberblocks” e “Transaction Groups”). (Veja nosso FAQ de ZFS na página de RAID para detalhes).
LVM-thin: É um processo de engenharia reversa do Linux LVM. Precisamos encontrar e remontar virtualmente o “Volume Group” (VG) e os “Logical Volumes” (LVs) que estão corrompidos ou inativos.
3. Meus arquivos .qcow2 (ou .raw) sumiram. É possível recuperar? Sim. Seus arquivos (.qcow2 ou .raw) não “sumiram”. Eles estão “presos” dentro do “container” de armazenamento (o ZFS Pool ou o LVM Volume Group) que “quebrou”. Nosso trabalho é, primeiro, consertar o container (o ZFS ou o LVM) para, em seguida, extrair seus arquivos de VM intactos.
4. Como a E-Recovery recupera minhas VMs Proxmox? Nosso processo é uma recuperação de “múltiplas camadas”:
Clonagem: Clonamos (bit-a-bit) todos os discos do servidor.
Remontagem do RAID (Camada 1): Se o Proxmox estava rodando em cima de um RAID de hardware (ex: LSI/Dell PERC), nós primeiro remontamos o RAID.
Engenharia Reversa (Camada 2 – O Desafio):
Se for ZFS: Usamos ferramentas forenses de ZFS (como Klennet) para reconstruir virtualmente o Pool ZFS “quebrado”.
Se for LVM: Usamos ferramentas forenses de LVM para encontrar e reativar o Volume Group (VG) e os LVs “thin”.
Extração (Camada 3): Uma vez que o “container” (ZFS ou LVM) está montado, extraímos os arquivos de disco virtual (.qcow2 ou .raw) intactos, prontos para você “importar” em um novo host.
Recuperação de VMs Criptografadas (Ransomware ESXi / Hyper-V)
Seu Datastore (VMFS/CSV) foi atacado por Ransomware? Arquivos .vmdk ou .vhdx criptografados? NÃO PAGUE O RESGATE! Desligue o host/storage imediatamente. Somos especialistas em reverter ataques a hipervisores.
O seu ambiente de virtualização foi vítima de um ataque e está apresentando estes sintomas?
🔒 VMs Criptografadas – Todos os seus arquivos de Máquina Virtual (.vmdk, .vhdx, .vdi, .qcow2) foram renomeados com uma extensão estranha (ex: .locked, .esxi, .args, etc.).
** ransom.txt** – Você encontra um “bilhete de resgate” (um arquivo de texto, como !!!READ_ME.txt) na raiz do seu Datastore, exigindo um pagamento em Bitcoin.
❌ VMs não Iniciam – Todas as suas Máquinas Virtuais estão “Desligadas” e não “dão boot”, reportando que o arquivo de disco virtual não foi encontrado ou está corrompido.
🖥️ Host Inacessível (ESXi) – O próprio host ESXi (o hipervisor) pode estar inacessível ou mostrando uma tela de resgate.
Entendendo o Ataque de Ransomware em VMs (O Ataque ao Hipervisor)
Este é o ataque mais devastador para uma empresa. Os hackers não atacam mais apenas os “Servidores Windows” (as VMs); eles atacam diretamente o Hipervisor (o VMware ESXi ou o Hyper-V) que os hospeda.
Usando vulnerabilidades (como o ESXi Shell ou o vCenter), o hacker criptografa os arquivos “mãe” (os .vmdk ou .vhdx). Isso é como trancar um prédio inteiro (o Datastore) em vez de apenas uma sala (a VM). O resultado é a perda de todos os seus servidores de uma só vez.
⚠️ A REGRA DE OURO: DESLIGUE OS HOSTS E O STORAGE IMEDIATAMENTE!
A sua reação pode ser rodar um Antivírus ou deletar os arquivos “estranhos”. NÃO FAÇA ISSO.
DESLIGUE OS SERVIDORES HOST (ESXi/Hyper-V). Não apenas as VMs, desligue o hardware.
DESLIGUE O STORAGE (SAN/NAS) que armazena os Datastores.
Por quê? Muitos ransomwares modernos (especialmente em SSDs/SANs) deletam os arquivos .vmdk originais e criam cópias criptografadas. Cada segundo que o sistema fica ligado, o comando TRIM / UNMAP (a “limpeza de lixo”) está rodando e apagando fisicamente os arquivos originais deletados, destruindo a única chance de recuperação sem a chave do hacker.
Perguntas Frequentes (FAQ): Recuperação de VMs (Ransomware)
1. É possível recuperar meus dados sem pagar o resgate? Sim, em muitos casos é possível. A recuperação não é sobre “quebrar” a criptografia (que é impossível). A recuperação é um processo forense focado em “des-deletar” (undelete) os arquivos originais, ou varrer a área livre do disco em busca de versões antigas ou que foram deletadas.
2. Como funciona a recuperação (se o vírus “deletou” os arquivos originais)? O processo é uma corrida contra o tempo e o comando TRIM/UNMAP.
Muitos vírus (como o Qlocker ou variantes do ESXiArgs) fazem o seguinte: 1) Copiam seu .vmdk, 2) Criam uma versão criptografada, 3) Deletam o .vmdk original.
Nossa recuperação foca em encontrar e recuperar o arquivo .vmdk original deletado de dentro do “espaço livre” do seu Datastore (VMFS, ZFS, Btrfs), antes que o TRIM o apague para sempre.
3. O que é UNMAP (TRIM) e por que ele é o inimigo aqui? O UNMAP (equivalente ao TRIM em Storages SAN) é um comando que o VMware envia ao Storage (Dell, HPE) dizendo: “Ei, aquele espaço do .vmdk que foi deletado pode ser limpo de verdade.” O Storage então apaga fisicamente os blocos. Desligar o Storage é a única forma de parar esse processo.
4. Como a E-Recovery recupera VMs de um ataque de ransomware? Nosso processo é uma recuperação forense de arquivos deletados em altíssimo nível:
Isolamento Imediato: Recebemos os discos do Storage/Servidor e os conectamos a um “bloqueador de escrita” (write-blocker) forense. Isso impede que qualquer comando (incluindo TRIM/UNMAP) seja enviado aos discos.
Clonagem e Remontagem do RAID: Clonamos todos os discos e remontamos virtualmente o seu RAID (5, 6, 10, ZFS, SHR, etc.).
Análise Forense do Datastore (VMFS/CSV): No RAID virtual, usamos ferramentas forenses de “file carving” (esculpir arquivos) para “escavar” o espaço livre do Datastore (VMFS, NTFS/CSV, etc.).
Recuperação dos .VMDK/.VHDX Deletados: Localizamos e reconstruímos os arquivos .vmdk ou .vhdx originais que o vírus tentou apagar.
Extração: Extraímos as VMs intactas, livres da criptografia, para uma nova mídia segura.
Recuperação de VM Deletada ou Snapshot Excluído
Sua VM foi deletada acidentalmente do Datastore? Snapshots sumiram? DESLIGUE O STORAGE IMEDIATAMENTE! A recuperação é uma corrida contra o comando TRIM/UNMAP.
O seu ambiente de virtualização sofreu um erro humano e está com estes sintomas?
❌ “Delete from Disk” – Um administrador (ou você) clicou com o botão direito na VM (no vSphere, Hyper-V, Proxmox) e selecionou “Deletar do Disco” (Delete from Disk) por engano.
📂 Arquivos .VMDK / .VHDX Sumiram – A VM desapareceu, e os arquivos de disco virtual (.vmdk, .vhdx, .qcow2) não estão mais na pasta do Datastore.
🔗 Snapshot Quebrado ou Deletado – Você tentou “consolidar” ou “deletar” um snapshot, o processo falhou, e agora a VM não liga mais (a “cadeia” quebrou) ou o snapshot foi deletado por engano.
💾 Volume Formatado – O Datastore (VMFS) ou Volume (NTFS/CSV/ZFS) inteiro onde as VMs estavam foi formatado acidentalmente.
Entendendo a Deleção Acidental em VMs (O Inimigo: TRIM/UNMAP)
Este é o desastre lógico mais perigoso em um ambiente virtual moderno. Ao contrário de um HD antigo (onde um arquivo deletado fica “invisível” esperando para ser sobrescrito), em um Storage moderno (SAN/NAS) ou em SSDs, o sistema de arquivos (VMFS, NTFS, ZFS) envia um comando chamado TRIM ou UNMAP para o hardware.
Este comando diz ao Storage: “Ei, os blocos onde aquela VM de 2TB estava agora estão livres. Você pode apagá-los fisicamente (zerar os blocos) para otimizar o espaço.”
Seus dados não estão apenas “deletados”; eles estão na fila para destruição física pelo próprio hardware.
⚠️ A REGRA DE OURO: DESLIGUE O STORAGE IMEDIATAMENTE (DESCONECTE DA ENERGIA)!
A recuperação de uma VM deletada é uma corrida contra o relógio. Cada segundo que o Storage (Dell PowerVault, HPE MSA, Synology, etc.) ou o host (ESXi) fica ligado, o processo de “limpeza de lixo” (Garbage Collection / TRIM / UNMAP) está rodando em segundo plano e apagando fisicamente os blocos onde sua VM estava.
NÃO CRIE NOVAS VMs ou copie novos arquivos para esse Datastore! Você estará sobrescrevendo os dados. DESLIGUE O HARDWARE (o Storage ou o Servidor) da tomada. Isso para o processo de limpeza e nos dá a única chance de recuperar os dados.
Perguntas Frequentes (FAQ): Recuperação de VM Deletada
1. Deletei a VM do vSphere. Ela não vai para a “Lixeira”? Não. Em ambientes de virtualização, “Deletar do Disco” é uma ação permanente. Não existe “Lixeira” para Datastores VMFS ou Volumes CSV.
2. O que é UNMAP (TRIM) e por que ele é tão perigoso aqui? O UNMAP (TRIM) é o comando que o hipervisor (VMware/Hyper-V) usa para dizer ao Storage (Dell, HPE, etc.) que os blocos de uma VM deletada estão “livres”. Em um Storage “thin-provisioned” ou em SSDs, o Storage apaga fisicamente esses blocos para recuperar o espaço. Desligar o equipamento é a única forma de parar esse processo.
3. Deletei só um Snapshot, não a VM inteira. É grave? Sim. Uma VM que usa snapshots é uma “corrente” (chain). O disco atual depende de todos os snapshots anteriores. Se você deletar um snapshot do meio da corrente por engano, você “quebra” a corrente e corrompe o disco virtual. A recuperação foca em “remendar” essa corrente.
4. Como a E-Recovery recupera uma VM deletada se o TRIM/UNMAP existe? Nosso sucesso depende 100% da sua ação (ter desligado o Storage rápido).
Isolamento Imediato: Recebemos os discos do Storage/Servidor e os conectamos a um “bloqueador de escrita” (write-blocker) forense. Isso impede que o sistema operacional envie novos comandos TRIM/UNMAP.
Clonagem e Remontagem do RAID: Clonamos todos os discos e remontamos virtualmente o seu RAID (5, 6, 10, ZFS, SHR, etc.).
Análise Forense do Datastore (VMFS/CSV): No RAID virtual, usamos ferramentas forenses de “file carving” (esculpir arquivos) para “escavar” o espaço “livre” (ainda não “zerado” pelo TRIM) em busca dos metadados e dos blocos de dados dos arquivos .vmdk ou .vhdx deletados.
Reconstrução da VM: Reconstruímos o arquivo de disco virtual (-flat.vmdk ou .vhdx) a partir dos fragmentos encontrados.
Como Funciona o Processo?
Veja como funciona o processo de recuperação de dados corporativos da E-Recovery — transparente, seguro e totalmente acompanhado pelos nossos engenheiros.
Contato Inicial e Entrega do Dispositivo
Entre em contato conosco pelo formulário, WhatsApp ou telefone para que um engenheiro possa orientar as primeiras ações e garantir a preservação dos dados.
Você pode entregar seu dispositivo, servidor, HD/SSD, storage ou mídia em qualquer uma de nossas unidades:
Matriz – Vila Mariana (SP)
Unidades de Recebimento: Barra Funda, Pinheiros, Morumbi e Tatuapé
Também aceitamos envio por Correios ou transportadora, com rastreamento.
Recomendação importante:
Embale o dispositivo em plástico bolha e utilize uma caixa rígida para evitar impactos durante o transporte. Caso o problema envolva servidor, storage, datastore ou máquina virtual, não ligue o equipamento — isso preserva a integridade dos dados e aumenta significativamente as chances de recuperação.
Diagnóstico e Orçamento
Realizamos uma análise técnica completa do dispositivo, servidor, storage ou ambiente virtual (VMware, Hyper-V, Proxmox, etc.) para identificar a falha e confirmar a viabilidade da recuperação.
Após a análise inicial, você recebe um laudo técnico preliminar e uma proposta comercial detalhada, totalmente transparente e alinhada ao escopo do seu caso. O valor da avaliação é cobrado por dispositivo ou VM, conforme a urgência desejada:
Avaliação Emergencial (8 horas corridas): R$ 400,00
Para empresas com ambiente parado, perda de VM crítica, datastore inacessível ou falha em RAID/storage.Avaliação Expressa (24 horas corridas): R$ 200,00
Ideal para casos importantes, porém sem paralisação total da operação.Avaliação Gratuita (48 horas úteis): R$ 0,00
Disponível para mídias individuais como HD/SSD/pendrive e para cenários sem urgência imediata.
Observação Importante
Casos de alta complexidade — como servidores físicos, sistemas RAID, storages NAS/SAN, datastores VMFS/CSV ou máquinas virtuais (VMDK/VHDX/QCOW2) — podem requerer avaliação especializada, com valores ajustados conforme a estrutura do ambiente. Qualquer alteração sempre será informada e aprovada por você antes do início da análise aprofundada.
Recuperação em Laboratório
Após sua aprovação formal, iniciamos o processo de recuperação em nosso laboratório próprio, localizado na matriz.
Os trabalhos são realizados por engenheiros especializados utilizando equipamentos profissionais como PC-3000, sistemas de engenharia reversa de VMFS/CSV/ZFS/LVM, ferramentas forenses e técnicas avançadas de imagiamento e reconstrução.
Dependendo do caso, realizamos:
clonagem segura do dispositivo para evitar riscos;
reconstrução de estruturas lógicas (VMDK, VHDX, QCOW2, snapshots);
análise e correção de metadados de datastores VMFS/CSV;
reconstrução de arrays RAID e storages NAS/SAN quando necessário.
Todo o processo é executado com total sigilo e seguindo protocolos que preservam a integridade dos dados corporativos.
Validação dos Dados Recuperados
A validação é uma das etapas mais importantes do processo.
Após concluirmos a recuperação, enviamos a lista completa dos arquivos, pastas, VMs ou bancos de dados encontrados.
Você poderá validar tudo de forma segura por acesso remoto (AnyDesk ou UltraViewer), abrindo e testando:
arquivos críticos do negócio;
máquinas virtuais recuperadas (VMDK/VHDX/QCOW2);
bancos de dados (SQL, Firebird, Oracle, etc., quando aplicável);
pastas de trabalho, documentos e snapshots.
Nada é entregue ou cobrado antes da sua confirmação total de integridade.
Somente após a sua aprovação seguimos para a etapa de pagamento e entrega dos dados.
Pagamento do Serviço
A regra “No Data, No Charge” (Sem Dados, Sem Cobrança) se aplica à grande maioria dos casos. O pagamento só é solicitado após a validação e aprovação dos dados recuperados, garantindo total segurança e transparência.
No entanto, alguns cenários específicos exigem taxa inicial de análise e alocação de recursos, pois envolvem alta complexidade, tempo prolongado de laboratório e uso de equipamentos ou peças especiais.
Nossa Política de Risco Compartilhado (importante)
Para casos mais avançados, pode ser necessária uma taxa inicial referente à análise aprofundada, engenharia reversa, engajamento técnico ou aquisição de peças, independentemente do resultado final.
Essas situações incluem:
Avaliações Expressas e Emergenciais
Incidentes de Ransomware (ESXi/Hyper-V/Proxmox)
Dispositivos formatados ou com exclusão grave de dados
Discos extremamente danificados
Casos que exigem compra de peças (ex.: HD doador específico)
Projetos de alta complexidade, como:
Servidores com RAID
Storages NAS/SAN
Volumes muito grandes
Recuperação de máquinas virtuais (VMDK, VHDX, QCOW2)
Reconstrução de datastores VMFS / CSV / ZFS / LVM
Toda e qualquer taxa será informada previamente, descrita em sua proposta comercial e somente aplicada com sua aprovação formal.
Entrega e Retirada dos Dados
Após a validação e o pagamento, seus dados recuperados são preparados para entrega de forma segura e controlada, conforme o método escolhido:
Cópia em Mídia Física (Sem Custo Adicional)
Você pode fornecer um HD ou SSD novo, e realizamos a gravação dos dados recuperados sem custo extra.
A mídia é entregue lacrada e identificada, garantindo total segurança no transporte e armazenamento.
Entrega via Nuvem (Tarifado)
Também podemos disponibilizar seus dados por meio de nuvem segura (Google Drive ou OneDrive).
Esse método envolve custos referentes a upload, criptografia e transferência, sempre detalhados previamente em sua proposta.
Local de Retirada
Por motivos de segurança e rastreabilidade, a retirada do dispositivo original e da mídia com os dados recuperados é realizada exclusivamente em nossa matriz, na Vila Mariana (SP). Se preferir, podemos orientar sua transportadora de confiança para coleta segura.
Encerramento e Apagamento Seguro dos Dados
Para garantir sua total privacidade e conformidade com as melhores práticas de segurança da informação, seguimos uma política rigorosa de retenção e eliminação segura de dados.
Após a entrega dos dados recuperados, mantemos uma cópia temporária criptografada em nossos servidores por 7 (sete) dias corridos, exclusivamente para garantir suporte pós-entrega e eventual reenvio, caso necessário.
Passado esse prazo, todo o material é permanentemente apagado de nossos sistemas por meio de procedimentos de data wiping seguro, alinhados aos padrões internacionais e às diretrizes da LGPD.
Após o encerramento, nenhum dado fica armazenado conosco.
Por isso, é fundamental que você confira seus arquivos e realize um backup próprio assim que recebê-los.
Por que Empresas e Departamentos de TI Confiam na E-Recovery?
ACOMPANHAMENTO DEDICADO
Cada projeto recebe um especialista responsável, que será seu ponto de contato único durante todo o processo. Você recebe atualizações proativas sobre cada etapa — diagnóstico, recuperação, validação e entrega — sem precisar solicitar. Seu caso é tratado com prioridade e total transparência.
ESPECIALIZAÇÃO REAL
Não vendemos peças, não formatamos computadores e não atuamos com serviços genéricos. Somos 100% especializados em recuperação de dados corporativos, com laboratório próprio, ferramentas profissionais (como PC-3000) e engenharia reversa de alto nível. Esse foco nos permite atingir taxas de sucesso superiores ao mercado.
ATENDIMENTO 24×7
Ambiente virtual parado significa impacto direto no negócio. Por isso, casos envolvendo servidores, VMs, storages ou datastores recebem atendimento emergencial 24×7. Do diagnóstico à entrega dos dados, nosso fluxo é projetado para ser o mais ágil possível, minimizando downtime e acelerando a retomada da operação.
NO DATA, NO CHARGE
Na grande maioria dos casos, você só realiza o pagamento após confirmar seus dados recuperados. Se não houver dados essenciais recuperáveis, você não paga pelo serviço. Transparência, segurança e risco minimizado para sua empresa.
CONFIDENCIALIDADE E LGPD
A segurança das suas informações é tratada com rigor absoluto. Assinamos Acordos de Confidencialidade (NDA) e seguimos práticas alinhadas à LGPD. Toda recuperação é realizada em ambientes controlados, isolados e com equipe altamente selecionada, garantindo sigilo e proteção integral dos seus dados.
TRANSPARÊNCIA TOTAL
Fornecemos diagnóstico detalhado, lista de arquivos recuperáveis (quando aplicável), explicação clara da falha e estimativa real de chances de recuperação. Você recebe um orçamento fixo, sem letras miúdas, sem surpresas e sem custos ocultos.
O que os Clientes Falam da E-Recovery
Grandes empresas confiam na E-Recovery, você também pode confiar!
“Fiz cotação com duas empresas americanas indicadas pela VMware Brasil (Gilware Data Recovery e DriveSavers), mas ambas não tinham escritório local. Tivemos degradação no arquivo iSCSI sem falha aparente de discos, o que travou o acesso ao VMFS 5 e ocasionou perda de diversas VMs. Após várias tentativas frustradas com a própria VMware, procuramos a E-Recovery por ser especializada nesse tipo de desastre. Eles conseguiram recuperação integral de diversas VMs e, nos casos mais críticos, realizaram uma restauração quase completa dos dados diretamente via iSCSI, algo que salvou nosso negócio. A equipe só parou quando encontrou uma solução. Uma experiência extremamente positiva.”
“Perdemos nosso servidor virtual de e-mails Zimbra. Após alguns desligamentos inesperados devido à falta de energia elétrica, o disco virtual VHDX de 1.6 TB corrompeu e os arquivos ficaram inacessíveis. Escolhemos a E- RECOVERY pelo portfólio da empresa, e principalmente pelo excelente atendimento que recebemos após o primeiro contato, que passou confiança e credibilidade. Enviamos nosso HD para a empresa, que rapidamente nos informou que os dados puderam ser recuperados e liberaram um acesso remoto para validação dos dados. Deixo aqui esse depoimento e indicação para quem precisar de recuperação de dados, parabéns e obrigado a toda equipe da E- RECOVERY.”
“Tivemos uma falha catastrófica no nosso escritório. Um surto de energia fritou nosso no-break e 2 HDs do servidor RAID-5 com 6 HDs de 2 TB, essencialmente destruindo nosso SERVIDOR XENSERVER e todas as VMs existentes. Chamamos a E-Recovery, com poucas esperanças de que recuperaríamos os dados. O pronto-atendimento foi excelente, e eles conseguiram recuperar 100% dos nossos dados. A recuperação foi finalizada antes do prazo de cinco dias solicitado. Nós possuímos diversas regras de segurança, mas, ocasionalmente, um desastre pode acontecer e destruir quatro anos de trabalho. É ótimo saber que podemos contar com a ajuda especializada da E-Recovery para nos ajudar nestes momentos.”
Depoimento do sr. Cardoso da Gráfica de Segurança Formflex de Carapicuíba/SP, que perdeu dados de um NAS com virtualização que estava configurados com 4 discos.
Mais de 250 Depoimentos de Clientes Corporativos Satisfeitos
Com avaliação ⭐⭐⭐⭐⭐ 4.9 / 5.0 em mais de 110 reviews no Google, e centenas de casos reais documentados em vídeo, a E-Recovery possui hoje uma das maiores reputações do mercado de recuperação de dados corporativos.
Empresas, prefeituras, escritórios de advocacia, indústrias, fintechs e provedores de tecnologia confiam em nós para realizar recuperações críticas, envolvendo: datastores VMFS/CSV, VMs VMDK/VHDX, storages NAS/SAN, servidores RAID, ambientes virtualizados VMware / Hyper-V / Proxmox, e incidentes de ransomware.
Cada história registrada pelos nossos clientes reforça o mesmo ponto: a E-Recovery entrega resultados reais, mesmo em cenários considerados “sem solução”.
“Fiz cotação com duas empresas americanas indicadas pela VMware Brasil (Gilware Data Recovery e DriveSavers), mas ambas não tinham escritório local. Tivemos degradação no arquivo iSCSI sem falha aparente de discos, o que travou o acesso ao VMFS 5 e ocasionou perda de diversas VMs. Após várias tentativas frustradas com a própria VMware, procuramos a E-Recovery por ser especializada nesse tipo de desastre. Eles conseguiram recuperação integral de diversas VMs e, nos casos mais críticos, realizaram uma restauração quase completa dos dados diretamente via iSCSI, algo que salvou nosso negócio. A equipe só parou quando encontrou uma solução. Uma experiência extremamente positiva.”
Estudo de Caso: Falha Lógica de iSCSI e Corrupção de Datastore VMFS 5
Recuperação Avançada de Datastore VMFS 5 / iSCSI
Cliente: Netpoint (www.netpoint.com.br)
Responsável: Alessandro Capoferri – Diretor
🧩 1. O Cliente
A Netpoint é uma empresa de tecnologia com forte dependência de infraestrutura virtualizada para operação contínua de serviços e ambientes corporativos. O ambiente utilizava storage com acesso via iSCSI, datastore VMFS 5 e múltiplas Máquinas Virtuais críticas para o funcionamento do negócio.
🚨 2. O Desafio — Um dos desastres lógicos mais complexos
A empresa enfrentou uma falha extremamente rara e grave: degradação do arquivo iSCSI, sem qualquer falha física de disco.
O RAID estava íntegro, mas a camada lógica — responsável pelo mapeamento do LUN — corrompeu-se.
Consequência imediata:
🚫 Perda total do acesso ao datastore VMFS 5
🚫 Múltiplas VMs inacessíveis
🚫 Discos virtuais .VMDK considerados “perdidos” pelo VMware
Mesmo após diversas tentativas com o suporte oficial da VMware, a recuperação não foi possível. Diante da gravidade, o cliente consultou grandes laboratórios internacionais (Gilware Data Recovery, DriveSavers) e, por indicação técnica e disponibilidade local, escolheu a E-Recovery para assumir o caso.
🛠️ 3. A Solução — Engenharia Reversa Forense em iSCSI + VMFS
O desafio era 100% lógico:
➡ Hardware saudável
➡ Storage ok
➡ RAID intacto
➡ Mas iSCSI + VMFS completamente corrompidos
A E-Recovery adotou um processo estruturado, seguro e totalmente forense:
Etapa 1 — Clonagem completa dos discos (Image-Level)
Mesmo sem falha física, todos os discos do Storage foram clonados bit a bit.
👉 Isso garante que qualquer operação é executada em cópias seguras e não compromete o ambiente original.
Etapa 2 — Remontagem virtual do RAID no laboratório
O array RAID foi reconstruído de forma virtual, respeitando os metadados e a topologia original.
O objetivo: montar um LUN idêntico ao ambiente real, mas 100% seguro para engenharia reversa.
Etapa 3 — Engenharia Reversa no LUN iSCSI (o “ponto crítico”)
Com o RAID virtualmente operacional, iniciamos a análise avançada:
Bypass do sistema de arquivos VMFS 5 corrompido
Leitura direta do fluxo bruto (raw) do LUN iSCSI
Identificação de fragmentos estruturais através de ferramentas forenses
Reconstrução manual de estruturas perdidas
Essa etapa é considerada altamente especializada e exige conhecimento profundo de:
🔹 iSCSI
🔹 VMFS
🔹 Page groups
🔹 Metadados de VMDK
🔹 File carving em datastores
Etapa 4 — Reconstrução das Máquinas Virtuais (.VMDK)
Com acesso aos dados brutos do LUN, realizamos:
Carving das extensões de discos virtuais
Reestruturação de fragmentos de VMDK
Reconstrução de cabeçalhos
Verificação e validação de integridade
O resultado foi a restauração completa das VMs, mesmo aquelas consideradas “irrecuperáveis” pelo VMware.
🟢 4. Resultado — Sucesso absoluto
A E-Recovery conseguiu:
✨ Recuperar integralmente as VMs críticas
✨ Reconstruir discos VMDK a partir de dados brutos
✨ Restaurar o datastore funcional
✨ Entregar dados íntegros e validados
✨ Reverter um desastre que nem o suporte oficial da VMware resolveu
O caso foi concluído com 100% de sucesso e zero perda de dados essenciais.
O cliente destacou: “Uma solução que nem os fabricantes conseguiram entregar. A E-Recovery persistiu até encontrar o caminho técnico correto e salvou nosso ambiente.”
Não arrisque seus dados. Fale com um especialista em recuperação de VMs agora mesmo
O tempo é crucial. Quanto mais rápido você agir, maiores as chances de recuperação. Preencha o formulário abaixo para um diagnóstico e orçamento gratuitos ou chame-nos no WhatsApp.
Endereço:
Av Professor Noé de Avevedo 208 cj 65 - Vila Mariana - São Paulo/SP - CEP 04117-000
Telefone / WhatsApp
Voz: (11) 3422-0066
WhatsApp: (11) 93075-5919
contato@e-recovery.com.br
Perguntas Comuns sobre VM
Veja as perguntas mais comuns sobre recuperação de dados de máquinas virtuais. Se a sua dúvida for outra, entre em contato com nossa equipe de atendimento.
O diagnóstico para um ambiente virtualizado (VMware, Hyper-V) é gratuito?
Sim, 100% gratuito e sem compromisso no orçamento no prazo normal. Nossos engenheiros farão uma análise completa de todos os discos do seu Servidor, Storage ou NAS para identificar a falha (seja ela nos discos, no RAID, ou no Datastore/Volume) e o potencial de recuperação. Você receberá um laudo técnico e um orçamento fixo antes de qualquer serviço.
E se minhas VMs não puderem ser recuperadas? Eu pago mesmo assim?
A recuperação de ambientes virtuais é complexa. Em casos raros (como metadados de VMFS/ZFS corrompidos por um “rebuild” forçado ou falha catastrófica de múltiplos discos), os dados podem ser irrecuperáveis. Mas para chegarmos ao resultado final, é necessário clonar todos os discos e remontar virtualmente o ambiente original (o RAID), o que demanda um grande investimento em tempo e alocação de recursos. Então, sim, mesmo que o resultado seja negativo, em alguns casos poderá ser cobrada uma taxa de alocação de recursos (previamente aprovada no orçamento).
Quanto tempo demora a recuperação das minhas VMs?
Entendemos que VMs paradas significam prejuízo. Casos de virtualização têm prioridade máxima (nível emergencial) em nosso laboratório.
Diagnóstico: Concluído em até 24 horas úteis.
Problemas Lógicos/Firmware: (Ex: Datastore VMFS corrompido, Pool ZFS “UNAVAIL”, Volume LVM inativo). Geralmente de 2 a 5 dias úteis.
Problemas Físicos (Ex: 1+ Disco Clicando): Pode levar de 5 a 10 dias úteis. Precisamos primeiro reparar os discos falhos em Sala Limpa para depois cloná-los e remontar o RAID.
Vocês recuperam os arquivos dentro da VM ou a VM inteira?
Nosso objetivo é recuperar a VM inteira e funcional. Não recuperamos apenas “arquivinhos”. Nosso processo extrai os arquivos de disco virtual intactos (ex: .VMDK, .VHDX, .VDI, .qcow2) e os arquivos de configuração (.VMX, etc.). O objetivo é que você possa “importar” esses arquivos em um novo servidor e ligar suas VMs exatamente como elas estavam. Entretanto, em alguns casos apenas a recuperação dos arquivos existentes dentro da VM será possível.
Como eu recebo minhas VMs de volta?
Nós nunca gravamos os dados de volta no seu array de discos original (ele está danificado e instável). Para garantir a segurança, os dados recuperados (seus arquivos .VMDK, .VHDX, etc.) são salvos em uma mídia nova que deve ser fornecida pelo cliente. Após a validação, você nos envia um novo HD externo (ou outro dispositivo) com capacidade suficiente e nós realizamos a cópia segura.