Av. Prof. Noé de Azevedo, 208 cj. 65 (11) 3422-0066 contato@e-recovery.com.br
Seu Ambiente VMware Está com Algum Desses Problemas?
Datastore VMFS Inacessível ou em RAW
O datastore parou de montar no ESXi ou aparece como inacessível no vCenter — todas as VMs hospedadas ficaram offline simultaneamente.
VM Deletada Acidentalmente do vCenter
A máquina virtual foi removida do inventário do vCenter por engano — junto com todos os seus arquivos VMDK e configurações de snapshot.
VMDK Corrompido ou Arquivo -flat Órfão
O arquivo de cabeçalho .vmdk sumiu ou está corrompido, deixando apenas o arquivo -flat.vmdk — a VM não inicializa e o ESXi não consegue registrar o disco virtual.
vSAN em Estado PDL ou APD
O cluster vSAN entrou em estado "Permanent Device Loss" ou "All Paths Down" — todas as VMs hospedadas no cluster ficaram inacessíveis simultaneamente.
Snapshots Deletados ou Cadeia Corrompida
Snapshots foram removidos acidentalmente ou a cadeia delta ficou inconsistente após falta de espaço no datastore — a VM não consolida e não inicializa.
ESXiArgs ou Ransomware no ESXi
Os arquivos VMDK foram criptografados por ESXiArgs, LockBit ou variante similar — todas as VMs pararam simultaneamente e o datastore está inacessível.
O que é Recuperação de VMware?
A recuperação de VMware ESXi e vSphere exige domínio do sistema de arquivos VMFS — com suas estruturas proprietárias de heartbeat, tabela de alocação de blocos e descritores de arquivo que variam entre VMFS-5 e VMFS-6 — e das camadas de abstração vSAN que distribuem objetos de VM entre múltiplos hosts com políticas de tolerância a falhas próprias. Nenhuma dessas estruturas é interpretada corretamente por ferramentas genéricas de recuperação.
Quando um datastore deixa de montar, volumes vSAN entram em estado Permanent Device Loss ou o vCenter perde acesso ao storage após falha de hardware, executar vmkfstools ou forçar a montagem em outro hipervisor antes do diagnóstico destrói os metadados remanescentes. Em ambientes vSphere com múltiplos hosts, uma ação incorreta num host pode propagar a corrupção para os demais nós do cluster — tornando a recuperação de VMware definitivamente inviável.
A E-Recovery aplica engenharia reversa para reconstruir a lógica de blocos do VMFS-5 e VMFS-6 — recuperando datastores após deleções acidentais, snapshots corrompidos e ataques de ransomware que visam o vCenter, e reconstruindo manualmente a cadeia de snapshots para que bancos de dados e aplicações críticas retornem à última versão estável. Diagnóstico gratuito em até 48 horas e atendimento emergencial 24×7.
Não arrisque seu ambiente VMware. Fale agora com um especialista em recuperação de ESXi/vSphere
O tempo é determinante em falhas de VMFS, VMDK ou datastores inacessíveis. Quanto mais rápido você agir, maiores as chances de recuperação total das suas VMs. Preencha o formulário abaixo para diagnóstico e orçamento gratuitos — ou fale conosco imediatamente pelo WhatsApp.
Empresas que Confiam na E-Recovery para Recuperar VMware
Organizações que operam VMware ESXi e vSphere confiam em nossa engenharia forense para restaurar datastores VMFS, VMDKs e ambientes virtualizados com segurança e precisão.
VMFS 5 e iSCSI Inacessível — VMs Recuperadas Integralmente
"Degradação no arquivo iSCSI travou o acesso ao VMFS 5 e causou perda de diversas VMs. Após tentativas frustradas com a própria VMware, a E-Recovery conseguiu recuperação integral das VMs e, nos casos mais críticos, restauração completa dos dados diretamente via iSCSI. Uma experiência extremamente positiva."
VHDX de 1.6TB Corrompido — Servidor Zimbra Recuperado
"Perdemos nosso servidor virtual de e-mails Zimbra após desligamentos inesperados por falta de energia. O disco VHDX de 1.6TB corrompeu e os arquivos ficaram inacessíveis. A E-Recovery nos passou confiança desde o primeiro contato, confirmou a viabilidade rapidamente e disponibilizou acesso remoto para validação antes da entrega."
VHDX Corrompido — Recuperação Rápida após Outros Falharem
"Consultamos outras empresas mas nenhuma sabia como resolver a corrupção do disco virtual VHDX. A E-Recovery recuperou todos os dados em pouco tempo, com profissionalismo e atendimento diferenciado. A escolha foi pela competitividade e pela confiança transmitida desde o primeiro contato — algo que as outras empresas não conseguiram oferecer. Recomendo sem hesitar."
RAID 5 Destruído, XenServer Comprometido — 100% Recuperado
"Num único surto elétrico perdemos o no-break e o servidor. Dois discos queimaram simultaneamente, destruindo o XenServer e todas as VMs — quatro anos de trabalho em risco. A E-Recovery recuperou 100% dos dados antes do prazo de cinco dias solicitado. É ótimo saber que podemos contar com ajuda especializada quando um desastre acontece."
Netpoint
Datastore VMware VMFS 5 Inacessível — Recuperação Integral via iSCSI
O Problema
A Netpoint operava um ambiente VMware com datastore VMFS 5 acessado via iSCSI quando o sistema apresentou degradação progressiva no arquivo de configuração iSCSI — sem nenhuma falha física detectável nos discos. O resultado foi o bloqueio completo do acesso ao datastore e a perda simultânea de diversas VMs críticas para a operação da empresa.
O diferencial deste caso: antes de acionar a E-Recovery, a Netpoint consultou duas referências internacionais indicadas pela própria VMware Brasil — Gilware Data Recovery e DriveSavers. Nenhuma possuía operação local no Brasil para um caso dessa complexidade. O suporte técnico da própria VMware também avaliou o ambiente sem conseguir avançar. Com todas as alternativas esgotadas, a E-Recovery foi acionada como especialista nacional em virtualização avançada — exatamente o tipo de cenário onde engenharia forense local faz a diferença que empresas internacionais não conseguem entregar.
Como Resolvemos
A Solução
O diagnóstico identificou que o problema estava na camada de metadados do VMFS 5 — não nos discos físicos. A degradação do arquivo iSCSI havia corrompido os ponteiros de alocação do datastore, tornando as VMs invisíveis para o hipervisor sem comprometer os blocos de dados subjacentes.
Com as imagens forenses protegidas em modo somente leitura, a equipe reconstruiu manualmente a estrutura de metadados do VMFS 5 via análise hexadecimal — identificando e corrigindo os ponteiros corrompidos que impediam a montagem do datastore.
Nos casos mais sensíveis, os dados foram extraídos diretamente da camada iSCSI — contornando completamente o VMFS e acessando os blocos brutos das VMs sem depender do hipervisor original.
O trabalho só foi encerrado após confirmação do cliente de que todos os dados estavam íntegros — incluindo validação remota do conteúdo das VMs antes da entrega final.
O Resultado
Recuperação integral de todas as VMs críticas. Nos casos mais sensíveis, reconstrução direta via iSCSI sem necessidade de remontar o datastore. Operação da Netpoint restabelecida sem perda de dados.
O Cliente: “Degradação no arquivo iSCSI bloqueou o VMFS 5 e derrubou diversas VMs. Após tentativas frustradas com a própria VMware, a E-Recovery recuperou tudo — incluindo restauração direta via iSCSI nos casos mais críticos. Experiência extremamente positiva.” – Alessandro Capoferri, Diretor — Netpoint
FAQ – Recuperação de VMware ESXi / vSphere / VMFS / VMDK
O diagnóstico para ambientes VMware é realmente gratuito?
Sim. Avaliamos seu ambiente sem custo: datastore VMFS/VMFS-L não montando, VMDK inacessível, snapshots presos, LUN iSCSI corrompido, entre outros cenários. Você só aprova o serviço após receber laudo preliminar, prazo e valor.
Preciso desligar o host ou cluster quando ocorre a falha?
Sim. Manter o ambiente ligado pode sobrescrever metadados e comprometer VMDKs e snapshots. A recomendação é desligar imediatamente o host afetado e não tentar remount, rebuild ou ferramentas de repair.
O que não devo fazer de jeito nenhum em um datastore VMware corrompido?
- Não recriar datastore
- Não rodar comandos de “Create / Initialize Disk”
- Não usar CHKDSK/FSCK via appliances
- Não tentar reparar VMDKs manualmente
Essas ações podem tornar a recuperação impossível.
É possível recuperar VMDKs parcialmente corrompidos?
Sim. Na maioria dos casos reconstruímos cabeçalhos, blocos faltantes, chains de snapshots e segmentos fragmentados — mesmo quando o VMware reporta o disco como unreadable ou inconsistente.
A E-Recovery consegue recuperar snapshots, thin disks e clones?
Sim. Restauramos cadeias de snapshots, discos thin, thick, delta, redo logs, templates, linked clones e arquivos auxiliares (CTK, VMX, etc.).
Quanto tempo dura a recuperação de um ambiente VMware?
Depende do tamanho do datastore, nível de corrupção e volume de VMs. Casos simples levam horas; cenários complexos (iSCSI, storages SAN, clusters ESXi) podem exigir alguns dias. Atendemos emergencial 24×7.
Preciso enviar o storage inteiro ou só os discos?
Você pode enviar apenas os discos físicos do storage/servidor. Clonamos tudo no laboratório e trabalhamos apenas nas imagens — preservando os originais.
Vocês recuperam apenas arquivos específicos ou a VM inteira?
Ambos. Podemos entregar:
- A VM completa pronta para importar no vSphere
- Apenas arquivos críticos (bancos SQL, AD, ERP, documentos etc.)
- Somente o VMDK reconstruído
Vocês conseguem recuperar quando o datastore aparece RAW?
Sim, esse é um dos cenários mais comuns. Mesmo com VMFS gravemente corrompido, reconstruímos a estrutura lógica e extraímos os VMDKs diretamente do LUN.
É possível recuperar ambientes VMware afetados por ransomware?
Sim, em muitos casos é possível fazer uma recuperação parcial. Trabalhamos com VMDKs criptografados, snapshots excluídos, datastores corrompidos e reconstrução de discos parciais — sem risco de reinfecção.
É seguro enviar meus dados?
Sim. Trabalhamos com NDA, laboratório isolado, cadeia de custódia e processos alinhados à LGPD.
Pagarei apenas se meus dados forem recuperados?
Sim, para a maioria dos casos lógicos (no data, no charge). Se não houver dados essenciais recuperáveis, não há cobrança..
Vocês trabalham com qualquer versão de VMware?
Sim: ESXi 4.x, 5.x, 6.x, 7.x e 8.x — incluindo vCenter, vSAN, clusters HA/DRS, iSCSI, NFS, Fibre Channel e storages OEM.
Conseguem recuperar um datastore mesmo após falhas em RAID?
Sim. Reconstruímos RAID virtualmente (Dell, HP, Lenovo, QNAP, Synology, NetApp, EMC, etc.) e depois restauramos o VMFS e os VMDKs.
Não arrisque seu ambiente VMware. Fale agora com um especialista em recuperação de ESXi/vSphere
O tempo é determinante em falhas de VMFS, VMDK ou datastores inacessíveis. Quanto mais rápido você agir, maiores as chances de recuperação total das suas VMs. Preencha o formulário abaixo para diagnóstico e orçamento gratuitos — ou fale conosco imediatamente pelo 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
FORMULÁRIO DE SOLICITAÇÃO DE ORÇAMENTO:
Guia Técnico
Estrutura Interna do VMFS: Por Que a Recuperação de Datastore VMware Vai Além das Ferramentas Nativas
Para recuperar datastore VMFS de forma segura, é fundamental entender o que o ESXi não consegue reparar sozinho — e por quê cada tentativa de reparo automático pode ser a última.
O VMFS (Virtual Machine File System) é um sistema de arquivos em cluster desenvolvido pela VMware com características que o tornam radicalmente diferente de sistemas convencionais como NTFS ou EXT4. Sua estrutura é organizada em três camadas interdependentes: os heartbeat regions (regiões de sincronia entre hosts do cluster), o resource allocation bitmap (mapa de alocação de blocos de 1 MB ou 8 MB dependendo da versão) e os file descriptors (ponteiros que mapeiam cada VMDK ao seu conjunto de blocos no datastore).
O mecanismo crítico que diferencia o VMFS-5 do VMFS-6 é o journaling de metadados. O VMFS-5 utiliza um journal de tamanho fixo que pode saturar em ambientes de alta carga de I/O — quando isso ocorre, as operações de escrita de metadados ficam pendentes e o datastore entra em estado inconsistente sem nenhuma falha física detectável. O VMFS-6 corrigiu esse problema com journaling dinâmico, mas introduziu o mecanismo de Auto-UNMAP (desmapeamento automático de blocos livres) que pode destruir blocos de VMs deletadas antes que qualquer tentativa de recuperação seja iniciada — tornando a recuperação de VMDK deletado inviável em minutos após a exclusão.
O comando vmkfstools -x repair, frequentemente sugerido em fóruns como primeira tentativa de recuperar VMware, opera diretamente sobre os metadados do datastore montado — sem criar nenhuma imagem forense prévia. Em um datastore com inconsistência de journaling, esse comando pode aplicar transações pendentes incorretas, sobrescrevendo permanentemente os ponteiros que levam aos arquivos VMDK. A única abordagem segura para recuperar dados VMware é a clonagem bit-a-bit do datastore antes de qualquer análise — o que o vmkfstools não faz.
Em laboratório, a reconstrução do VMFS começa pela análise hexadecimal dos primeiros 2 MB de cada disco membro do datastore — onde ficam armazenados os metadados primários incluindo o VMFS label, o UUID do volume e o resource allocation bitmap. Com esses metadados mapeados, é possível reconstruir a topologia completa do datastore independentemente do estado do ESXi e sem necessidade do hardware original.
Guia Técnico
O que Fazer nas Primeiras Horas após Falha no VMware ESXi
Quando um datastore VMFS desaparece, uma VM entra em estado Inaccessible, a consolidação de snapshots trava ou o vSAN reporta componentes em estado Absent, as ações tomadas nas primeiras horas determinam se a recuperação será completa, parcial ou impossível. O VMware ESXi tem mecanismos automáticos que podem agravar o dano — o Auto-UNMAP do VMFS-6 apaga blocos de VMs deletadas em minutos, o HA tenta reiniciar VMs em outros hosts com storage inconsistente e o vSAN inicia rebalanceamento de objetos que pode sobrescrever blocos válidos.
O primeiro passo é documentar o estado exato antes de qualquer intervenção: capturar a saída do esxcli storage vmfs extent list e do vmkfstools -P no datastore afetado, registrar o estado de cada VM no vCenter — Inaccessible, Invalid, Orphaned ou simplesmente ausente do inventário —, fotografar os alertas no vSphere Client e verificar os logs do vmkernel.log e hostd.log via SSH antes de qualquer reinicialização do host. Em ambientes vSAN, capturar a saída do esxcli vsan health cluster get e do cmmds-tool find antes de qualquer operação — esses metadados são sobrescritos durante tentativas de rebalanceamento e contêm o mapa exato de quais blocos estão em quais discos.
O segundo passo é verificar se o problema é de conectividade antes de assumir corrupção: confirmar se o storage iSCSI ou FC está respondendo, se o LUN está apresentado corretamente ao host e se o datastore simplesmente precisa ser remontado — situação comum após reinicialização de host sem resignature do volume. Se o datastore remonta e as VMs aparecem normalmente, monitorar ativamente os eventos do vCenter antes de qualquer outra ação.
O terceiro passo — e o mais crítico — é saber quando parar. Se o VMFS aparece como RAW, se a consolidação de snapshots trava e não progride, se o vSAN reporta PDL em algum disk group ou se VMs entram em loop de inicialização com erro de disco, a única ação segura é interromper imediatamente qualquer operação automática do ESXi e encaminhar para diagnóstico forense. Não execute vmkfstools -x repair, não force a consolidação de snapshots pelo vCenter, não reinstale o ESXi no host, não crie novo datastore no mesmo LUN e não inicie evacuação de hosts do vSAN sem diagnóstico — cada uma dessas ações pode destruir permanentemente os metadados VMFS ou os blocos vSAN que ainda seriam recuperáveis.
Guia Técnico
VMDK Corrompido e Arquivo -flat Órfão: Como Recuperamos sem o Arquivo Descritor
Um dos cenários mais frequentes em recuperação de VMware é o arquivo -flat.vmdk presente no datastore mas sem o arquivo descritor correspondente — a VM aparece como “órfã” no vCenter e o ESXi não consegue registrá-la.
O VMDK é composto por dois arquivos distintos: o arquivo descritor (um arquivo de texto de poucos KB contendo o mapa de extensões, parâmetros de hardware virtual e cadeia de snapshots) e o arquivo -flat.vmdk (o arquivo binário que contém os dados reais da VM, com tamanho igual ao disco virtual provisionado). Sem o descritor, o ESXi não consegue determinar a geometria do disco, o tipo de provisionamento ou a posição dos dados — tornando o -flat.vmdk inacessível por qualquer ferramenta convencional.
A reconstrução forense do arquivo descritor é possível porque suas informações são parcialmente redundantes com os metadados do VMFS e com o cabeçalho interno do próprio -flat.vmdk. Os primeiros setores do arquivo flat contêm assinaturas de sistema de arquivos (NTFS, EXT4, XFS) que permitem identificar o sistema operacional da VM e validar os parâmetros de geometria. Com essas informações, reconstruímos o descritor manualmente — especificando o tipo de disco (monolithicFlat), o tamanho em setores, o adapter type e os parâmetros de DDB (Disk Database) — e remontamos a VM sem depender de nenhuma ferramenta da VMware.
O cenário mais complexo é o Thin Provisioning com sparse extents — onde o -flat.vmdk não é um arquivo contíguo mas uma série de extents espalhados pelo datastore em blocos não sequenciais. Para recuperar dados VMware em Thin Provisioning, é necessário mapear a allocation table do VMFS e identificar a sequência exata de blocos que compõem o arquivo antes de qualquer tentativa de leitura — processo impossível com ferramentas de recuperação genéricas que não interpretam o formato de alocação proprietário do VMFS.
Guia Técnico
Snapshots VMware: Por Que a Consolidação Falha e Como Reconstruímos a Cadeia Delta
Recuperar VMware com cadeia de snapshots corrompida é tecnicamente o cenário mais delicado — porque cada tentativa de consolidação forçada pelo ESXi pode destruir irrecuperavelmente blocos válidos da VM.
Os snapshots VMware são implementados como arquivos delta no formato VMDK (com extensão -000001.vmdk, -000002.vmdk, etc.) que registram apenas as diferenças em relação ao disco base. A cadeia funciona como uma árvore de dependências: cada arquivo delta aponta para o seu pai via o campo parentFileNameHint no descritor — e o ESXi precisa montar toda a cadeia em ordem para apresentar o estado atual da VM.
A consolidação falha em quatro cenários principais: falta de espaço no datastore durante o processo (o ESXi cria um arquivo temporário do tamanho completo do disco antes de comprimir o resultado), queda de energia durante a consolidação (deixa o disco base parcialmente atualizado e o delta parcialmente esvaziado — estado que o ESXi não consegue recuperar automaticamente), snapshot tree muito profunda (cadeias com mais de 32 níveis — limite oficial da VMware — onde a reconstrução se torna exponencialmente mais complexa) e backup VADP interrompido (onde o agente de backup cria um snapshot temporário que nunca é removido, deixando a VM em estado de “snapshot orphan” invisível no vCenter).
Para recuperação de VMware com cadeias delta corrompidas, o processo em laboratório começa pelo mapeamento completo de todos os arquivos delta presentes no datastore — incluindo os snapshots órfãos não visíveis no vCenter. Com o mapa da cadeia, identificamos os parentFileNameHints incorretos e os blocos duplicados entre deltas adjacentes. A reconstrução é feita block-by-block, mesclando manualmente os deltas em ordem cronológica até chegar ao estado mais recente possível da VM — sem usar o mecanismo de consolidação nativo do ESXi em nenhuma etapa.
Guia Técnico
ESXiArgs e Ransomware em VMware: Recuperação de Datastore VMFS Criptografado
O ESXiArgs, identificado pela primeira vez em fevereiro de 2023, representa um vetor de ataque específico contra infraestruturas VMware ESXi — e o cenário de recuperar dados VMware após ransomware tem particularidades técnicas que o diferenciam completamente do ransomware convencional em Windows.
O ESXiArgs e suas variantes não criptografam os arquivos -flat.vmdk diretamente — eles criptografam os arquivos descritores VMDK e os arquivos de configuração .vmx das VMs. O -flat.vmdk (onde os dados reais estão armazenados) frequentemente permanece intacto. Isso significa que em muitos casos de ataque ESXiArgs, os dados das VMs estão fisicamente presentes no datastore — o que está criptografado é a “chave de acesso” lógica que o ESXi usa para montar a VM.
A recuperação de datastore VMFS após ESXiArgs envolve a reconstrução manual dos descritores VMDK a partir das assinaturas dos -flat.vmdk — exatamente o mesmo processo descrito para arquivos descritores órfãos, mas com a complexidade adicional de que os metadados do datastore também podem ter sido parcialmente modificados pelo ransomware para impedir a remontagem do volume.
O segundo vetor de ataque, usado por variantes mais recentes como o LockBit ESXi, criptografa diretamente os blocos de dados do -flat.vmdk — tornando a recuperação dependente da disponibilidade de backup ou da obtenção de decriptores. Nesses casos, o processo forense foca em identificar exatamente quais blocos foram criptografados e quais permaneceram intactos — muitas VMs têm blocos de dados antigos não sobrescritos que podem ser extraídos mesmo sem decriptor.
Para recuperar VMware após ransomware, a regra mais importante é não reinicializar o host ESXi após o ataque. Cada reinicialização pode acionar mecanismos de recuperação automática do VMFS que sobrescrevem metadados essenciais para a análise forense — reduzindo drasticamente as chances de recuperação parcial ou total.
Guia Técnico
vSAN com Falha de Disk Group: Recuperar Dados VMware em Storage Distribuído
O vSAN (Virtual SAN) representa o cenário mais complexo de recuperação de VMware — porque os dados não estão em um storage centralizado mas distribuídos entre os discos locais de múltiplos hosts ESXi em um cluster.
O vSAN organiza os dados em disk groups, cada um composto por um disco de cache (SSD) e um ou mais discos de capacidade (SSD ou HDD). Os objetos de VM são distribuídos entre os disk groups de acordo com as storage policies definidas no vCenter — com réplicas, paridade e tolerância a falhas configuráveis por VM. Quando um disk group falha, o impacto depende diretamente da storage policy: VMs com RAID-1 têm seus dados disponíveis na réplica do disk group sobrevivente; VMs com RAID-5 ou RAID-6 podem ser reconstruídas matematicamente desde que o número de falhas não exceda a tolerância configurada.
O cenário crítico é o Permanent Device Loss (PDL) — quando o vSAN perde acesso permanente a um disk group e as réplicas não são suficientes para cobrir a perda. Nesse estado, as VMs afetadas ficam em estado “Inaccessible” no vCenter e o cluster para de aceitar operações de escrita para proteger a integridade dos dados remanescentes.
Para recuperar datastore VMFS em ambiente vSAN após PDL, o processo não pode ser feito com o cluster ativo — qualquer operação de rebalanceamento iniciada pelo vSAN pode sobrescrever os blocos dos disk groups afetados. Em laboratório, os discos de todos os hosts do cluster são clonados individualmente antes de qualquer análise. Com os clones, mapeamos a distribuição de objetos entre disk groups via análise dos vSAN metadata (LSOM — Log-Structured Object Manager) — identificando quais blocos de cada VM estão em quais discos e em qual estado (válido, stale, ausente).
A reconstrução é feita virtualmente — remontando o vSAN offline com os parâmetros originais de RAID e storage policy — sem necessidade do cluster original. Para recuperar dados VMware em vSAN com múltiplas falhas, a viabilidade depende do número de réplicas disponíveis e do estado dos blocos de paridade — análise que só é possível após o mapeamento completo do LSOM de todos os discos membros do cluster.
Guia Técnico
Quanto Custa Recuperar VM VMware ESXi? Prazo e Investimento
O custo de recuperação de um ambiente VMware ESXi depende de quatro variáveis principais: o tipo de falha — VMFS corrompido, VMDK com arquivo -flat órfão, cadeia de snapshots quebrada, ataque ransomware ESXiArgs ou vSAN com disk group em PDL —, a escala do ambiente — datastore standalone, cluster vSphere com vMotion ou vSAN distribuído entre múltiplos hosts —, o histórico de intervenções realizadas antes do diagnóstico e a urgência do atendimento. Um datastore VMFS com VMDK órfão em host standalone sem intervenções anteriores exige menos horas de engenharia do que um vSAN com três disk groups em PDL, VMs com storage policy RAID-5 e tentativa de evacuação forçada anterior. Cada variável adicional aumenta a complexidade e o investimento necessário.
O prazo segue a mesma lógica. O diagnóstico é gratuito — em até 24 horas úteis em casos convencionais ou emergencial em poucas horas para ambientes com múltiplas VMs de produção fora do ar. Em casos com storage físico comprometido subjacente ao VMFS — RAID degradado, SSD com bad blocks, NAS inacessível —, a clonagem forense prévia pode demandar prazo adicional, definido após avaliação inicial. A partir do diagnóstico, casos com VMFS corrompido ou VMDK órfão em ambiente standalone costumam ser concluídos entre 2 e 5 dias úteis. Casos com cadeia de snapshots extensa, ataque ESXiArgs ou ambiente vSphere com cluster Failover demandam entre 5 e 12 dias úteis. Casos com vSAN e múltiplos disk groups comprometidos — exigindo mapeamento completo do LSOM em todos os hosts — demandam entre 10 e 20 dias úteis dependendo da escala do cluster.
A E-Recovery não cobra pelo diagnóstico e opera com política sem dados sem cobrança para a maioria dos casos — a cobrança ocorre apenas após o cliente visualizar e confirmar remotamente os dados recuperados ou após inicialização das VMs em ambiente de teste controlado. Em ambientes de alta complexidade técnica — vSAN com múltiplos hosts, datastores com cadeias de snapshots extensas, ataques de ransomware com VMFS parcialmente sobrescrito ou casos com intervenções anteriores que agravaram os danos — pode ser aplicada uma taxa de engajamento para início dos trabalhos, acordada previamente com total transparência antes de qualquer decisão. Atendimento emergencial 24×7 está disponível para ambientes onde as VMs hospedam sistemas críticos para a operação.
