Av. Prof. Noé de Azevedo, 208 cj. 65 (11) 3422-0066 contato@e-recovery.com.br
Atendemos todo Brasil via Sedex ou recuperação remota.
Seu Ambiente Hyper-V Está com Algum Desses Problemas?
Storage Repository Inacessível
O host XenServer ou XCP-ng perdeu acesso ao SR — erros "SR unavailable" ou "Cannot see required storage" no XenCenter. O pool inteiro para de responder e todas as VMs ficam inacessíveis simultaneamente. Não tente reatachar o SR sem análise prévia dos metadados LVM.
VMs Inacessíveis após Falha de RAID
Falha de disco no array físico que sustenta o SR corrompeu o LVM. As VMs aparecem no inventário mas não inicializam — "VDI missing" ou "disk not found". A recuperação exige clonagem forense dos discos físicos antes de qualquer tentativa de acesso ao SR.
LVM Corrompido
O volume group ou logical volumes do SR foram corrompidos — resultado de queda de energia durante escrita, falha de disco no array ou timeout de iSCSI. O host perde o mapeamento dos VDIs e as VMs somem do inventário. Executar pvscan ou vgscan nesse estado pode sobrescrever o mapeamento original.
Host XenServer não Inicializa
O Dom0 não completa o boot após falha de disco no sistema operacional do host. As VMs estão intactas no SR mas inacessíveis porque o hipervisor não sobe. A recuperação pode ser feita diretamente nos discos virtuais sem o host original.
Cadeia de Snapshots Quebrada
Snapshots .vhd em estado inconsistente — resultado de consolidação interrompida, falta de espaço no SR ou falha durante operação de merge. O XenServer não consegue montar a VM porque a cadeia diferencial está corrompida. Não force a consolidação manualmente.
SR Corrompido após Migração ou Atualização
Migração de XenServer para XCP-ng malsucedida ou atualização de versão que corrompeu os metadados do SR. O pool perde a referência dos VDIs — volumes que existem fisicamente mas tornaram-se invisíveis para o hipervisor.
O que é Recuperação de XenServer e XCP-ng?
A recuperação de XenServer e XCP-ng exige domínio da arquitetura de Storage Repositories — com metadados LVM proprietários que organizam VDIs em volumes lógicos sobre iSCSI, Fibre Channel ou armazenamento local, e cadeias de snapshots .vhd que, quando rompidas, tornam toda a VM inacessível. Diferente de outros hipervisores, uma falha no SR afeta imediatamente todas as VMs hospedadas nele.
Quando o SR entra em estado unavailable ou VDIs ficam missing, executar pvscan, vgscan ou lvrepair sem análise forense prévia sobrescreve o mapeamento dos volumes lógicos — destruindo permanentemente as referências para reconstruir a cadeia de discos virtuais. Em clusters XCP-ng com multipath ativo, uma tentativa de reparo num nó pode replicar a corrupção para os demais hosts simultaneamente.
A E-Recovery é especialista em recuperação de XenServer e XCP-ng — reconstruindo Storage Repositories via engenharia reversa dos metadados LVM, consolidando snapshots quebrados e restaurando bancos de dados e aplicações com integridade total. Atendemos desde SRs locais até clusters com multipath iSCSI e Fibre Channel — com diagnóstico gratuito em até 48 horas e atendimento emergencial 24×7.
XenServer Offline, SR Inacessível ou VMs que não Inicializam?
Recuperar XenServer e XCP-ng exige reconstrução forense dos metadados LVM e análise da cadeia de snapshots antes de qualquer acesso ao SR. Envie seu caso para análise especializada — diagnóstico gratuito, sem compromisso.
Empresas que Confiam na E-Recovery para Recuperar XenServer e XCP-ng
Seu XenServer ou XCP-ng está com SR inacessível e as VMs pararam? A E-Recovery atende incidentes em clusters Xen com diagnóstico gratuito e atendimento emergencial 24×7 — sem necessidade do hardware original.
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."
O Cliente:“Tivemos um incidente extremamente sério em nossa infraestrutura. Ter o suporte especializado da E-Recovery em um momento tão crítico fez toda a diferença.” – Gregory Brown — Diretor de Operações, VBETA
Versão Beta
Servidor XenServer com RAID 5 Destruído por Surto Elétrico — 100% Recuperado em 5 Dias
O Problema
Um surto elétrico simultâneo comprometeu o nobreak e o servidor Dell PowerEdge da VBETA, queimando dois discos de um array RAID composto por seis unidades de 2TB. O impacto foi imediato e total — o Storage Repository do ambiente XenServer tornou-se completamente inacessível e todas as máquinas virtuais pararam simultaneamente. Gregory Brown, Diretor de Operações, acionou a E-Recovery já preparado para o pior — com dois discos falhados simultaneamente em um array sem tolerância suficiente, o cenário apontava para perda definitiva.
Como Resolvemos
O Processo
Com seis discos do array isolados em laboratório, cada unidade foi clonada individualmente via PC-3000 em modo somente leitura — incluindo os dois discos com falha elétrica, que passaram por estabilização antes da clonagem para extrair o máximo possível sem agravar o dano físico.
Com todos os clones gerados, a equipe analisou a estrutura do LVM local que sustentava o Storage Repository XenServer. Os metadados do volume group e dos logical volumes foram extraídos e reconstruídos — mapeando a posição exata de cada VDI no SR sem reatachar o storage no hardware original. A cadeia de snapshots de cada VM foi analisada individualmente para identificar inconsistências antes da extração.
Com o SR remontado virtualmente em laboratório, os discos virtuais foram extraídos diretamente — sem depender do host XenServer original — e o ambiente completo foi reconstituído com integridade total.
O Resultado
100% dos dados recuperados em poucos dias — todas as máquinas virtuais restauradas integralmente, incluindo configurações, bancos de dados e sistemas operacionais guest. Um ambiente que a equipe de TI considerava irrecuperável foi devolvido sem nenhuma perda.
“EMC Iomega PX12-400R — 12 discos HGST de 3TB / 36TB brutos — NAS enterprise com ambiente XenServer corporativo. Equipamento recebido para recuperação de Storage Repository inacessível após falha simultânea de discos.”
Hospital de Porte Médio de São Paulo
Recuperação de Ambiente XenServer — EMC Iomega PX12-400R, 36TB
O Problema
Um hospital de médio porte em São Paulo perdeu acesso completo ao ambiente XenServer hospedado em um NAS EMC Iomega StorCenter PX12-400R — 12 discos HGST de 3TB totalizando 36TB de dados críticos. Sistemas clínicos, prontuários eletrônicos e aplicações administrativas dependiam integralmente das máquinas virtuais hospedadas nesse ambiente.
O que começou como uma falha em quatro discos simultaneamente evoluiu ao longo de semanas para um colapso total do array — após múltiplas tentativas de rebuild malsucedidas, intervenções incorretas de suporte técnico, reinicializações sucessivas e comandos de recuperação executados sem análise forense prévia.
Cada intervenção agravou progressivamente o estado dos metadados LVM, transformando um cenário inicialmente recuperável em um caso que outros laboratórios declararam como perda total definitiva.
Como Resolvemos
A Cronologia do Desastre
Em 23 de janeiro de 2019, os LEDs do storage indicaram problemas simultâneos nos discos 6, 7, 10 e 11. O equipamento foi reinicializado e os serviços restabelecidos temporariamente. Dois dias depois, novas falhas nos discos 6 e 8 forçaram a substituição do disco 8 e o início de um processo de rebuild — que parou antes de concluir, derrubando todas as VMs.
Entre os dias 26 e 29 de janeiro, a equipe de TI substituiu o disco 6, reiniciou o storage — que voltou sem apresentar os volumes — e contatou o suporte do Lenovo, que orientou a não remover o disco 6 por risco de quebra de paridade. Com o suporte da empresa Indyxa, um novo rebuild foi iniciado com o disco original na posição 6 e disco novo na posição 8. O rebuild completou a primeira fase com sucesso — mas os volumes voltaram a ficar indisponíveis. O disco 12, que era o hot spare configurado, havia deixado de ser reconhecido como tal. Após reinicialização, o storage iniciou a segunda fase do rebuild — mas voltou a falhar.
Nos dias seguintes, um storage IBM V7000 alugado foi conectado para tentativa de cópia dos dados. O rebuild atingiu 96% e falhou novamente. O storage parou de responder ao login na interface de gerenciamento. Tentativas sucessivas de remover e recolocar os discos 6 e 8 em diferentes combinações não restabeleceram os volumes. O comando de recuperação do console avançado — “O storage está corrompido. Talvez seja possível recriar e recuperar os dados” — foi executado sem sucesso. O array estava completamente inacessível.
O Processo
Com o storage declarado irrecuperável após semanas de intervenções, o caso chegou à E-Recovery. Dado o volume, a criticidade e a complexidade acumulada pelas intervenções anteriores, a recuperação foi coordenada em colaboração com especialistas internacionais em virtualização Xen.
Os 12 discos foram clonados individualmente em laboratório e os parâmetros do array foram recalculados via engenharia reversa — ordem exata dos discos, stripe size e geometria — sem depender do hardware original nem do histórico de rebuilds malsucedidos.
O caso apresentou uma complexidade técnica incomum: o iSCSI desse ambiente operava sobre partições LVM diretamente — não sobre arquivos armazenados em disco EXT, que é a implementação mais comum em ambientes XenServer. Nessa arquitetura, os VDIs são partições criadas e gerenciadas diretamente pelo LVM, sem camada intermediária de arquivos. As múltiplas tentativas de rebuild e as reinicializações sucessivas haviam corrompido severamente os metadados LVM — exigindo o desenvolvimento de um protocolo específico para mapear e reconstruir as partições sem as referências originais.
O Resultado
Ambiente XenServer recuperado integralmente — todas as máquinas virtuais restauradas com integridade total. O hospital retomou as operações sem perda de dados clínicos ou administrativos — um resultado considerado impossível após a extensão das intervenções anteriores.
FAQ – Recuperação de XenServer / XCP-ng
A recuperação de ambientes XenServer e XCP-ng envolve camadas técnicas específicas — SR, LVM, VHD e cadeias de snapshots — que exigem diagnóstico especializado antes de qualquer intervenção. Tire suas dúvidas sobre o processo, prazos e chances de recuperação.
É possível recuperar um Storage Repository (SR) que não monta mais?
Sim. Mesmo quando o XenCenter informa que o SR está “broken” ou não consegue anexá-lo, ainda é possível reconstruir metadados do LVM/EXT e recuperar os VDIs. Na maioria dos casos, os dados continuam fisicamente presentes.
Meu LVM foi corrompido. Ainda existe chance de recuperar as VMs?
Sim. Corrupção de LVM é um dos cenários mais comuns em XenServer e não significa perda definitiva. Reconstruímos manualmente a estrutura de alocação e reconstituímos o SR para extrair os discos virtuais.
O XenServer apagou snapshots após um merge automático. Isso é reversível?
Em muitos casos, sim. Merges interrompidos ou snapshots órfãos podem ser reconstruídos manualmente, desde que não tenham sido sobrescritos por operações posteriores do host.
É seguro tentar recriar o SR pelo XenCenter?
Não. Recriar SR, forçar attach ou executar coalesce pode sobrescrever metadados críticos e inviabilizar a recuperação. A integridade do SR depende de não executar operações destrutivas após a falha.
Meu VHD/VHDX aparece como corrompido. Ainda é possível recuperar?
Sim. Restauramos cabeçalhos, blocos desalinhados, chains de snapshots e setores inconsistentes. Até discos reportados como “invalid” pelo XenCenter podem ser recuperados.
O pool database está inconsistente. Isso impede a recuperação das VMs?
Não. O pool database é importante para o gerenciamento, mas os dados das VMs residem no SR. Recuperamos os VDIs diretamente do storage, independentemente do estado do pool.
Após queda de energia, algumas VMs desapareceram da interface. Isso é normal?
Sim. Quando o SR perde referência interna aos VDIs, as VMs deixam de aparecer, embora continuem fisicamente dentro do LVM. É um dos cenários em que a recuperação é mais eficiente.
Posso tentar montar o SR em outro host?
Não é recomendado. Cada tentativa de attach pode disparar operações automáticas que alteram journal, snapshots ou metadados. Quanto menos ações após a falha, maior o sucesso.
Vocês recuperam ambientes XenServer em SAN, iSCSI ou NFS?
Sim. Trabalhamos diariamente com SAN Fibre Channel, iSCSI multipath, NFS, servidores bare-metal e pools híbridos. O tipo de storage não impede a recuperação.
Preciso enviar o servidor completo ou apenas os discos?
Apenas os discos físicos ou LUNs. Todo o trabalho é feito em laboratório, em clones bit-a-bit.
Quanto tempo dura a recuperação de um ambiente XenServer?
Depende do tamanho do SR, da quantidade de snapshots, do nível de corrupção e da integridade do RAID. Casos simples duram horas; casos complexos podem exigir vários dias.
Vocês trabalham com XCP-ng também?
Sim. XenServer e XCP-ng compartilham arquitetura semelhante e ambos são totalmente suportados no processo de recuperação.
Existe risco de perda total das VMs?
O risco aumenta quando o cliente tenta anexar SR, rodar coalesce, excluir snapshots ou reconstruir LVM. Quando o ambiente chega sem intervenção posterior, a taxa de sucesso é muito alta.
Vocês aceitam casos de emergência 24×7?
Sim. Ambientes XenServer críticos podem ser atendidos em regime emergencial, com diagnóstico inicial imediato.
O que fazer imediatamente quando o SR XenServer fica inacessível?
Quatro regras críticas: (1) desligue o host imediatamente — não tente reatachar o SR nem reiniciar o pool; (2) não execute pvscan, vgscan nem lvrepair — esses comandos sobrescrevem o mapeamento dos volumes lógicos; (3) não tente recriar o SR pelo XenCenter — apaga os metadados que ainda permitiriam recuperar os VDIs; (4) anote os erros exibidos no XenCenter — “SR unavailable”, “VDI missing” ou “Cannot see required storage” são informações valiosas para o diagnóstico forense.
Qual a diferença entre recuperar XenServer e XCP-ng?
A arquitetura base é a mesma — ambos usam LVM para gerenciar o SR e VHD/VHDX para os discos virtuais. A diferença está na versão dos metadados e nos caminhos de configuração. XCP-ng é open source com atualizações mais frequentes — em alguns casos os metadados do SR divergem do XenServer original após migração, exigindo análise específica da versão antes da reconstrução virtual.
Quanto custa recuperar XenServer ou XCP-ng?
O diagnóstico é gratuito e o orçamento é apresentado antes de qualquer intervenção. Só cobramos se os dados forem recuperados com sucesso. O valor varia conforme o número de discos físicos, tipo de SR — LVM local, iSCSI ou NFS — número de VMs, presença de snapshots corrompidos e complexidade da reconstrução dos metadados LVM. Entre em contato para avaliação sem compromisso.
XenServer Offline, SR Inacessível ou VMs que não Inicializam?
Seu XenServer ou XCP-ng parou de montar o Storage Repository e as VMs ficaram inacessíveis? A E-Recovery atende incidentes em clusters Xen com diagnóstico gratuito e atendimento emergencial 24×7 — sem necessidade do hardware original.
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
O que é XenServer e XCP-ng — Arquitetura SR e LVM
O Citrix XenServer e seu fork open source XCP-ng são hipervisores corporativos baseados no projeto Xen — amplamente utilizados em infraestruturas de alta disponibilidade, clusters de servidores e ambientes de virtualização críticos. A arquitetura central que diferencia o XenServer de outros hipervisores é o Storage Repository (SR) — a camada de abstração que gerencia todos os discos virtuais (VDIs) do ambiente.
O SR é implementado sobre LVM — Logical Volume Manager — que organiza o armazenamento físico em volume groups e logical volumes. Cada VM do ambiente tem seus discos virtuais (.vhd ou .vhdx) mapeados como logical volumes dentro do SR. Essa arquitetura oferece flexibilidade e performance, mas tem uma característica crítica: qualquer inconsistência nos metadados do LVM torna todas as VMs do SR inacessíveis simultaneamente — não apenas uma máquina, mas o pool inteiro.
O XenServer suporta diferentes tipos de SR — LVM local, iSCSI, Fibre Channel, NFS e SMB — cada um com características distintas de recuperação. O SR local é o mais comum em ambientes de pequeno e médio porte; o iSCSI e Fibre Channel são típicos de ambientes enterprise com storage dedicado. Em todos os casos, a recuperação de XenServer depende do domínio da lógica LVM e da capacidade de reconstruir os metadados sem o host original.
Guia Técnico
Por que o XenServer Falha — Causas Reais
Ambientes XenServer e XCP-ng operam sobre uma arquitetura que exige sincronia absoluta entre camada física e lógica de volumes. Quando essa sincronia é quebrada, a interrupção é sistêmica. As causas mais frequentes que chegam ao laboratório da E-Recovery:
Falha física no array de discos: queda de energia, falha simultânea de múltiplos discos ou falha de controladora corrompem o LVM fisicamente. O SR torna-se inacessível com erros “SR unavailable” ou “Cannot see required storage” — todas as VMs param imediatamente.
Corrupção de metadados LVM: desligamentos abruptos durante operações de escrita deixam os metadados do volume group em estado inconsistente. O host não consegue montar o SR na inicialização — as VMs aparecem no inventário mas não inicializam.
Cadeia de snapshots corrompida: operações de merge ou consolidação de snapshots interrompidas por falta de espaço no SR ou queda de energia deixam os arquivos .vhd em estado inconsistente. O XenServer não consegue montar a VM porque a cadeia diferencial está quebrada.
Timeout de iSCSI ou Fibre Channel: latência alta ou perda de conectividade com o storage durante operação de escrita corrompe os blocos em trânsito. O LVM registra os blocos como escritos mas o conteúdo está inconsistente — gerando corrupção silenciosa em bancos de dados e sistemas de arquivos guest.
Migração ou atualização malsucedida: upgrade de XenServer para XCP-ng ou entre versões do XenServer pode gerar incompatibilidade nos metadados do SR — fazendo com que o pool perca a referência dos VDIs mesmo com os dados físicos intactos.
Intervenção incorreta de terceiros: tentativas de reparo com pvscan, vgscan ou lvrepair sem análise prévia sobrescrevem o mapeamento dos logical volumes — transformando um SR recuperável em perda total.
Guia Técnico
XenServer vs XCP-ng — Diferenças na Recuperação de Dados
Embora compartilhem a mesma arquitetura base, recuperar XenServer e recuperar XCP-ng apresentam diferenças técnicas que impactam diretamente o protocolo de intervenção.
Formato de metadados: o XenServer comercial e o XCP-ng usam estruturas de metadados LVM similares mas com versões e caminhos de configuração distintos. Após migrações de XenServer para XCP-ng, os metadados do SR podem divergir — exigindo análise específica da versão antes de qualquer tentativa de reconstrução virtual.
Gestão de snapshots: o XCP-ng implementa melhorias no gerenciamento de snapshots em relação ao XenServer original. Em ambientes que migraram parcialmente — com alguns hosts em XenServer e outros em XCP-ng — cadeias de snapshots mistas podem criar inconsistências adicionais que exigem tratamento específico por VM.
Dom0 e DomU: o Dom0 é o domínio privilegiado que controla o hardware — o sistema operacional do host XenServer. Os DomUs são os domínios guest — as VMs. Quando o Dom0 falha por corrompimento do disco de sistema, as VMs nos DomUs podem estar completamente íntegras. A E-Recovery recupera os dados diretamente dos discos virtuais sem precisar do Dom0 funcional — extraindo VHDs e restaurando o ambiente em um novo host.
Suporte a storage enterprise: ambientes XCP-ng enterprise frequentemente usam iSCSI multipath ou Fibre Channel com múltiplos caminhos redundantes. Falhas de multipath que causam split-brain — onde dois hosts tentam escrever no mesmo LUN simultaneamente — geram corrupção severa no LVM que exige análise forense das duas cópias antes da reconstrução.
Guia Técnico
Como Recuperamos XenServer e XCP-ng — Protocolo E-Recovery
A recuperação de XenServer e XCP-ng na E-Recovery segue um protocolo forense desenhado para preservar os metadados LVM e reconstruir o SR virtualmente — sem reatachar o storage no hardware original e sem risco de sobrescrita dos VDIs.
1. Isolamento e Clonagem Forense dos Discos Físicos Cada disco do array físico que sustenta o SR é clonado individualmente via PC-3000 em modo somente leitura. Discos com bad blocks recebem leitura adaptativa — extraindo o máximo possível sem forçar leituras destrutivas. O estado original de cada unidade permanece imutável durante todo o processo.
2. Análise e Reconstrução dos Metadados LVM Extraímos e analisamos os metadados do volume group e dos logical volumes — identificando a estrutura exata do SR, o mapeamento de cada VDI e o estado das cadeias de snapshots. Em casos com metadados corrompidos, reconstruímos a estrutura LVM a partir dos dados remanescentes nos próprios discos, sem depender do host XenServer original.
3. Reconstrução Virtual do Storage Repository O SR é remontado virtualmente em ambiente de laboratório controlado — sem o hardware original e sem reatachar o storage em nenhum host XenServer. Isso garante que nenhum processo automático do hipervisor possa sobrescrever os VDIs durante a extração.
4. Consolidação de Snapshots e Extração dos VHDs Com o SR virtualmente íntegro, consolidamos as cadeias de snapshots de cada VM individualmente — identificando e corrigindo inconsistências antes da extração. Os discos virtuais são extraídos em formato VHD/VHDX com validação de integridade, permitindo a restauração em qualquer host XenServer ou XCP-ng compatível.
5. Validação e Entrega Bancos de dados, sistemas operacionais guest e aplicações críticas são verificados antes da entrega. O cliente valida o conteúdo remotamente — sem pagamento antes da confirmação.
Guia Técnico
SR Inacessível em XenServer — Ainda tem Recuperação?
Sim — e é o cenário mais comum que chega ao laboratório da E-Recovery.
Quando o Storage Repository do XenServer torna-se inacessível com erros “SR unavailable”, “VDI missing” ou “Cannot see required storage”, o instinto do administrador é tentar reatachar o SR pelo XenCenter ou executar comandos de reparo no LVM. Essas ações são as mais destrutivas possíveis — porque sobrescrevem exatamente os metadados que ainda permitiriam recuperar as VMs.
O protocolo da E-Recovery para SR inacessível segue três etapas críticas. Primeiro, diagnosticamos a causa raiz — falha física nos discos, corrupção de metadados LVM ou timeout de conectividade — sem ligar o host ou tentar montar o SR. Segundo, clonamos os discos físicos via PC-3000 e reconstruímos os metadados LVM a partir dos dados remanescentes. Terceiro, remontamos o SR virtualmente e extraímos os VDIs sem o host original.
Em nossa experiência, a grande maioria dos casos de SR inacessível tem recuperação total — desde que nenhum comando de reparo tenha sido executado antes da chegada ao laboratório. Casos com pvscan ou vgscan executados previamente têm complexidade maior mas frequentemente ainda têm recuperação parcial ou total dependendo da extensão da sobrescrita.
Guia Técnico
⚠️ O que NUNCA Fazer em XenServer com Falha
Em ambientes XenServer e XCP-ng, as ações tomadas nos primeiros minutos após a falha determinam se a recuperação será possível ou não:
Reatachar o SR pelo XenCenter — força o host a tentar montar um SR com metadados inconsistentes, sobrescrevendo estruturas LVM que ainda estariam íntegras.
Executar pvscan, vgscan ou lvrepair — reescrevem o mapeamento dos logical volumes com base no estado atual do LVM — que pode estar incorreto. A sobrescrita dos metadados originais é frequentemente irreversível.
Recriar o SR pelo XenCenter — inicializa um novo LVM sobre os dados existentes, destruindo permanentemente os VDIs e todos os dados das VMs.
Reiniciar o host repetidamente — cada boot força o Dom0 a tentar montar o SR, executando verificações automáticas do LVM que podem sobrescrever metadados críticos.
Tentar migrar VMs para outro host sem análise prévia — em ambientes com SR compartilhado via iSCSI ou Fibre Channel, uma migração com SR inconsistente pode propagar a corrupção para outros hosts do pool.
Executar xe sr-repair ou xe vdi-introduce sem diagnóstico — comandos da CLI do XenServer que alteram os metadados do SR sem análise forense prévia podem destruir as referências dos VDIs.
O protocolo correto é universal: desligue o host imediatamente, não execute nenhum comando na CLI do XenServer ou XenCenter e envie os discos para diagnóstico. Nossa análise forense identifica a causa raiz da falha e reconstrói o SR sem colocar os dados em risco.
Guia Técnico
Quanto Custa Recuperar XenServer ou XCP-ng? Diagnóstico Gratuito
A recuperação de XenServer e XCP-ng na E-Recovery segue o mesmo princípio de todas as nossas recuperações: só cobramos se os dados forem recuperados com sucesso. O diagnóstico é sempre gratuito — em até 48 horas úteis ou em até 8 horas para casos emergenciais — e o orçamento é apresentado antes de qualquer intervenção.
O valor varia conforme a complexidade: número de discos físicos, tipo de SR — LVM local, iSCSI, Fibre Channel ou NFS — número de VMs, presença de snapshots corrompidos, estado dos metadados LVM e necessidade de consolidação de cadeias de snapshots. Casos com multipath e split-brain têm complexidade maior — o diagnóstico determina o cenário real antes de qualquer cobrança.
Atendemos todo o Brasil via Sedex com orientação de embalagem segura. Para clientes em São Paulo, temos 5 unidades de recebimento. A validação dos dados recuperados é feita remotamente pelo cliente antes do pagamento — como fez Gregory Brown da VBETA, que recuperou 100% do ambiente XenServer após queima simultânea de dois discos do array.
