O que é Recuperação de Dados de Servidores?
A recuperação de servidor consiste em restaurar dados e serviços essenciais após falhas físicas ou lógicas em ambientes Dell, HPE, Lenovo, IBM ou Supermicro. O processo inclui clonagem forense dos discos, identificação dos parâmetros do RAID, reconstrução virtual do volume e extração segura dos dados.
É utilizada quando o servidor não inicia, apresenta discos em “failed”, volumes RAW, corrupção de LUN ou falhas nas controladoras. O objetivo é reconstruir o ambiente do servidor, recuperar volumes, arquivos e aplicações críticas e devolver a operação ao cliente com segurança e integridade.
- 🛑 Servidor no inicia (tela azul, kernel panic, boot failure)?
- 🧩 RAID degradado (foreign config, failed, missing drive)?
- 🚨 Luzes de alerta piscando no servidor ou na controladora?
- 📂 Pastas, bancos de dados ou sistemas inacessíveis?
A E-Recovery é especialista em recuperação de servidores RAID, com tecnologia avançada e ambiente seguro para lidar com falhas complexas, garantindo a máxima integridade e confidencialidade das informações corporativas.
Veja o que não fazer para piorar a situação!
Uma falha de servidor é um dos piores cenários para um departamento de ti. Um servidor dell poweredge, hpe proliant, lenovo thinksystem ou supermicro parado não significa apenas arquivos perdidos; significa que toda a operação da empresa fica offline: bancos de dados (sql, oracle), sistemas erp/crm, aplicações críticas e todas as máquinas virtuais (vms) dependentes daquele servidor.
A sua primeira reação pode ser tentar “consertar” o problema rapidamente. Cuidado. Em um ambiente de servidor, uma única ação incorreta pode transformar uma falha totalmente recuperável em perda permanente de dados. Siga estas orientações essenciais:
🚫 Não force o array (raid) online
Se o servidor reiniciar e a controladora raid (dell perc, hpe smart array, lsi, lenovo serveraid) exibir um disco como “failed” (falho) ou “foreign configuration” (configuração estrangeira), não clique em “force online”, “import foreign” ou qualquer comando semelhante.
Se o disco estiver stale (obsoleto), forçá-lo ao array irá corromper matematicamente 100% dos seus dados, destruindo volumes, luns e vms.
💻 Não rode chkdsk ou fsck
Se o volume do servidor aparece como “raw” ou “corrompido”, rodar chkdsk (windows server) ou fsck (linux) é um erro crítico.
Essas ferramentas são projetadas para corrigir erros de arquivo, não para preservar dados.
Ao tentar “corrigir”, elas podem sobrescrever metadados essenciais, apagando estruturas de vms, bancos de dados, logs e diretórios, tornando a recuperação impossível até para laboratórios especializados.
📞 Desligue o servidor e contate nossos especialistas
Se os dados são críticos, a única ação realmente segura é desligar imediatamente o servidor, especialmente se houver barulhos de clique ou travamentos repetidos.
Entre em contato conosco para um diagnóstico gratuito, onde identificamos a falha física (discos), lógica (sistema de arquivos, lun, vmfs/ntfs/xfs) ou de controladora, e informamos a viabilidade real da recuperação, sem compromisso.
Especialistas nas Marcas Líderes de Servidores do Mercado
Especialistas nas Principais Marcas e Arquiteturas de Servidores
Veja os problemas mais comuns em servidores RAID que solucionamos diariamente, incluindo falhas em controladoras, discos, sistemas de arquivos e ambientes virtualizados.
Recuperação de Servidor Dell (PowerEdge, PERC)
Seu servidor Dell PowerEdge parou? A controladora PERC acusa “Foreign Configuration”? Não importe a configuração! Nós somos especialistas em recuperar arrays RAID de controladoras Dell PERC, mesmo em cenários de múltiplas falhas.
O seu servidor Dell (PowerEdge, PowerVault) está apresentando algum destes sintomas?
🚨 Erro “foreign configuration” – O servidor reinicia após uma queda de energia e a controladora PERC (H310, H710, H730, etc.) não monta o RAID, exibindo “foreign configuration found”.
🚫 Múltiplos discos “failed” ou “offline” – O painel LCD ou o iDRAC exibe alertas âmbar indicando que dois ou mais discos falharam em um RAID 5 ou 6.
🖥️ “No boot device found” – O servidor não encontra mais o array onde o Windows Server, Linux ou VMware estava instalado.
🧩 Metadados corrompidos – A controladora perde a “receita” do RAID e exibe discos como “ready” (prontos), sugerindo que um novo array seja criado.
Entendendo a falha do servidor Dell (a armadilha da PERC)
Os servidores Dell PowerEdge dependem das controladoras PERC para gerenciar o RAID. Essa placa mantém a “receita” de funcionamento do array: ordem dos discos, tamanho de bloco, posição da paridade e estado de cada disco.
Quando ocorre falha de energia, falha dupla de discos ou instabilidade, a PERC protege o array e marca alguns discos como “foreign” ou “stale”. É nesse momento que muitos administradores, tentando resolver rápido, acabam destruindo definitivamente os dados.
A regra de ouro: não importe e não limpe uma “foreign configuration”
A primeira reação é entrar no menu da PERC (Ctrl+R) e clicar em “import foreign configuration”. Não faça isso!
Se um dos discos estiver “stale” (com dados antigos), a importação mistura informações inconsistentes e corrompe matematicamente o array inteiro. Da mesma forma, clicar em “clear configuration” apaga os metadados dos discos e remove informações essenciais para a recuperação.
Perguntas frequentes (FAQ): Recuperação de servidor Dell
1 – Quais modelos de servidor Dell podem ser recuperados?
Recuperamos todas as linhas Dell PowerEdge e Dell EMC. Os casos mais comuns incluem as séries T (torre), R (rack), PowerVault e qualquer configuração com controladoras PERC como H310, H330, H700, H710, H730, H740 e H750.
2 – O que significa “foreign configuration”?
Significa que a PERC detectou uma configuração de RAID válida nos discos, mas que não corresponde ao estado salvo na controladora. Importar essa configuração pode corromper o array se algum disco estiver desatualizado.
3 – Posso substituir a minha controladora PERC por outra igual?
É extremamente arriscado. Uma controladora com firmware diferente pode reescrever metadados, tentar atualizar a configuração ou até “limpar” o estado do array. Isso destrói os dados.
4 – O iDRAC mostra dois discos “failed” em RAID 5. O que devo fazer?
Desligue o servidor imediatamente. RAID 5 só suporta a falha de um disco. Com dois discos fora, qualquer tentativa de “rebuild”, “import” ou “force online” destruirá os dados remanescentes.
5 – Como a E-Recovery recupera um array PERC?
Nosso processo é 100% seguro e não depende da sua controladora física.
- Clonagem: Criamos clones bit-a-bit de todos os discos, inclusive os que falharam.
- Reparo em sala limpa: Se necessário, realizamos reparos físicos nos discos danificados.
- Engenharia reversa: Usamos ferramentas forenses de RAID para identificar a receita exata do array (ordem, bloco, paridade, discos stale).
- Remontagem virtual: Montamos o RAID de forma totalmente virtual, sem risco para os dados.
- Extração: O volume reaparece com arquivos, VMs e bancos de dados intactos, pronto para ser copiado com segurança.
Recuperação de Servidor HPE (ProLiant, Smart Array)
Seu servidor HPE ProLiant não “dá boot”? A controladora Smart Array acusa falha de “Accelerator Battery”? Não desabilite o cache! Nós somos especialistas em falhas de controladoras Smart Array, cache FBWC e gerenciamento iLO.
O seu servidor HPE (ProLiant, StoreVirtual) está apresentando algum destes sintomas?
🚨 Luz vermelha piscando – O “Health LED” no painel frontal do servidor (DL/ML) está piscando em vermelho ou âmbar.
🖥️ POST Error 1783 / 1720 – O servidor para na inicialização com erros como “Drive Array Failure” ou “Smart Array Controller Failure”.
🔋 Falha na bateria de cache – Um erro comum: “Array Accelerator Battery Failure”. A controladora P410, P420 ou P440 desativa o cache de gravação e pode colocar o array offline.
🚫 Múltiplos discos “Failed” – O iLO ou o ACU exibe dois ou mais discos falhos em um RAID 5 ou 6.
Entendendo a falha do servidor HPE (A armadilha da bateria de cache)
Os servidores HPE ProLiant utilizam controladoras Smart Array que dependem do FBWC (Flash-Backed Write Cache) ou do FSA (Flash Storage Accelerator) para proteger dados em caso de queda de energia.
Quando essa bateria ou capacitor falha, a controladora não sabe se existem dados pendentes no cache. Para evitar corrupção, ela pode recusar-se a montar o array RAID, gerando erros como o 1783 e impedindo o carregamento do servidor.
A regra de ouro: Não tente “Forçar Online” o array e não desabilite o cache
Se o cache falhou, sua primeira reação pode ser desabilitar o Write Cache ou tentar “Force Online” no menu da Smart Array. Não faça isso!
Se havia dados pendentes no cache, forçar a montagem do RAID sem validação pode corromper matematicamente o volume, destruindo bancos de dados, sistemas e máquinas virtuais.
Perguntas Frequentes (FAQ): Recuperação de Servidor HPE
1 – Quais modelos de Servidor HPE vocês recuperam?
Trabalhamos com todas as linhas HPE e HP legacy, incluindo:
Servidores ML (ML30, ML110, ML350), servidores DL (DL360, DL380, DL385), servidores Blade BL e Storages MSA (P2000, 2040, 2050, 2060).
2 – O que significa “Array Accelerator Battery Failure” e por que isso “quebra” o RAID?
O “Array Accelerator” é o cache de escrita da Smart Array. Ele utiliza uma bateria FBWC ou um capacitor FSA para proteger os dados em caso de falha elétrica. Quando a bateria morre, a controladora não tem como garantir que os dados pendentes foram gravados e, por segurança, pode derrubar o RAID inteiro até que a bateria seja substituída.
3 – O iLO está mostrando dois discos falhos em um RAID 5. O que fazer?
Desligue o servidor imediatamente. O RAID 5 tolera apenas um disco falho. Com dois discos “Failed”, o array está matematicamente quebrado. Qualquer tentativa de rebuild destrói os dados restantes.
4 – Como a E-Recovery recupera um array de uma Smart Array?
- Clonagem: Clonamos bit-a-bit todos os discos do array ProLiant.
- Reparo: Tratamos fisicamente discos com defeito em Sala Limpa quando necessário.
- Engenharia Reversa: Analisamos os clones para reconstruir os metadados específicos da Smart Array.
- Remontagem Virtual: Identificamos a receita exata do RAID (ordem, tamanho do bloco, paridade) e remontamos o array.
- Extração: O volume retorna íntegro (VMs, bancos de dados, arquivos), permitindo a cópia segura.
Recuperação de Servidor Supermicro (SuperServer, LSI/Broadcom)
Seu servidor Supermicro não inicia? A controladora LSI/Broadcom acusa “Foreign Configuration”? O pool ZFS do TrueNAS não monta? Nós somos especialistas em falhas de controladoras LSI MegaRAID, HBAs em modo IT e ambientes SuperServer usados como servidores de virtualização.
O seu servidor Supermicro (SuperServer, LSI/Broadcom, TrueNAS) está apresentando algum destes sintomas?
🚨 Luz âmbar no chassi – O servidor Supermicro exibe LEDs de falha no painel frontal ou no backplane, indicando falha de múltiplos discos ou problemas de comunicação com a controladora.
🧩 “Foreign Configuration” – A controladora LSI/Broadcom (MegaRAID 9271, 9361, 9300, etc.) detecta uma configuração RAID incompatível e não monta o array.
💾 Discos “Offline” ou “Missing” – Após uma queda de energia ou travamento, dois ou mais discos aparecem como “Offline”, quebrando o RAID 5 ou 6.
🖥️ Falha em servidores TrueNAS/FreeNAS – O sistema não consegue “importar” o pool ZFS, exibindo erros como “POOL UNAVAIL” ou “Pool Faulted”.
Entendendo a falha do servidor Supermicro (A armadilha do hardware aberto)
Servidores Supermicro são extremamente populares em datacenters, clusters Ceph, ambientes de virtualização e appliances TrueNAS. Eles funcionam com controladoras LSI/Broadcom ou HBAs em modo IT, o que permite configurar tanto RAIDs tradicionais quanto ZFS nativo.
O problema é que, por serem mais flexíveis, exigem cuidados maiores:
- Um RAID LSI pode quebrar se um disco estiver “stale” (obsoleto) e for reinserido no array.
- Um sistema ZFS pode falhar catastróficamente se for “forçado a montar” enquanto há corrupção de transações (TXGs).
- Um JBOD Supermicro pode deixar discos “invisíveis” se o backplane ou o cabo mini-SAS apresentar falha.
A regra de ouro: Não “importe” a configuração e não “force” o ZFS a montar
Se o seu servidor Supermicro apresentou falha, a sua primeira reação será entrar na BIOS da LSI (Ctrl+H) e clicar em “Import Foreign Configuration”. Não faça isso!
Se houver um disco “stale”, a importação incorreta destrói a paridade do RAID, causando perda total dos dados.
Da mesma forma:
- Não execute “zpool import -f” em um pool ZFS quebrado.
- Não rode “Clear” ou “Rebuild” em discos que estavam instáveis.
- Não tente atualizar firmware da controladora com o RAID quebrado.
Qualquer ação errada pode transformar dados recuperáveis em perda definitiva.
Perguntas Frequentes (FAQ): Recuperação de Servidor Supermicro
1 – Quais modelos de servidor Supermicro vocês recuperam?
Recuperamos todas as linhas SuperServer e SuperStorage, incluindo:
- SuperServer 1U/2U/4U (X9, X10, X11, X12)
- SuperStorage SSG (24, 36, 45, 60 baias)
- JBODs com backplanes SAS2/SAS3
- Ambientes TrueNAS, FreeNAS, ZFS, Ceph e Proxmox com ZFS
2 – O que causa o erro “Foreign Configuration” em controladoras LSI?
Esse erro aparece quando a controladora detecta metadados de RAID que não batem com o array. Geralmente ocorre após:
- Queda de energia
- Disco “stale” reinserido
- Rebuild interrompido
- Falha de backplane ou cabo SAS
3 – Meu TrueNAS diz “POOL UNAVAIL”. Isso significa que perdi tudo?
Não necessariamente. Pools ZFS falham quando:
- Dois discos falham em RAID-Z1
- Três falham em RAID-Z2
- Há corrupção de TXGs
- Há falhas de memória (RAM com ECC defeituosa)
Mesmo em cenários graves, é possível reconstruir os uberblocks e acessar o pool virtualmente.
4 – Como a E-Recovery recupera um servidor Supermicro?
Nosso processo é totalmente seguro e não depende da sua controladora ou do seu sistema operacional:
- Clonagem: Fazemos imaging bit-a-bit de todos os discos do servidor (bons ou falhos).
- Reparo (Sala Limpa): Tratamos fisicamente discos com defeito, se necessário.
- Engenharia Reversa: Analisamos os metadados LSI ou a estrutura ZFS (uberblocks/TXGs).
- Remontagem Virtual: Reconstruímos o RAID ou o ZFS em ambiente controlado.
- Extração: Recuperamos VMs, bancos de dados e arquivos diretamente dos volumes remontados.
Recuperação de Servidor IBM (System x, ServeRAID)
Seu servidor IBM (System x ou BladeCenter) parou? A controladora ServeRAID exibe “Defunct” (extinto)? Não recrie o array! Somos especialistas em falhas de controladoras IBM ServeRAID e sistemas System x/Blade.
O seu servidor IBM está apresentando algum destes sintomas?
🚨 Luz de alerta âmbar (laranja) – O painel frontal (light path diagnostics) indica falha de disco (drive fault), falha de RAID ou erro de controladora.
🚫 Array “Defunct” ou “Offline” – A BIOS da ServeRAID (ex: M5015, M5110) exibe o seu “Logical Drive” como “Defunct” ou “Offline”, impedindo o boot.
💾 “Missing Configuration” – Após uma queda de energia, a controladora “esquece” a configuração do RAID e mostra os discos como “Unconfigured Good”.
🖥️ Servidor travado no boot – O servidor para na inicialização ao tentar carregar a BIOS da controladora ServeRAID ou LSI.
Entendendo a falha do servidor IBM (A armadilha da ServeRAID)
Servidores IBM System x utilizam controladoras ServeRAID — muitas vezes baseadas em LSI/Broadcom, porém com firmware personalizado. Esse firmware proprietário armazena a “receita” do RAID (ordem, tamanho de bloco, paridade) nos discos e na NVRAM da placa.
Quando ocorre falha de múltiplos discos, queda de energia, corrupção de NVRAM ou incompatibilidade de firmware, a controladora marca o array como “Defunct” — o equivalente a “morto”. Isso normalmente significa:
- Falha simultânea de dois discos em RAID 5,
- Falha de um par em RAID 10,
- Rebuild interrompido,
- Disco “stale” reinserido no array.
A regra de ouro: Não limpe a configuração e não recrie o array
Se a BIOS da ServeRAID mostrar os discos como “Unconfigured Good” ou o array como “Defunct”, a sua primeira reação será usar as opções “Clear”, “Rebuild” ou “Re-create Array”. Não faça isso!
“Clear Configuration” apaga os metadados originais do RAID.
“Re-create Array” formata os discos e zera a receita do array.
Qualquer uma dessas ações destrói permanentemente a possibilidade de recuperação.
A ação correta é desligar o servidor e enviar os discos para análise.
Perguntas Frequentes (FAQ): Recuperação de Servidor IBM
1 – Quais modelos de servidor IBM vocês recuperam?
Temos experiência em todas as famílias IBM x86, incluindo:
- System x Tower: x3100, x3300, x3500 (M4, M5).
- System x Rack: x3530, x3550, x3650 (M4, M5).
- BladeCenter: HS22, HS23 e modelos correlatos.
- Storages IBM DS e Storwize associados.
- Controladoras ServeRAID e LSI (M1015, M5015, M5110).
2 – Minha ServeRAID queimou. Posso trocar por outra “igual”?
É altamente arriscado. Mesmo controladoras “idênticas” podem ter firmware diferente. Uma mudança mínima pode:
- Não reconhecer a receita do RAID,
- Atualizar metadados incorretamente,
- Corromper o array durante a inicialização.
A recuperação 100% segura é feita sem usar a controladora original.
3 – O que significa “Array Defunct”?
“Defunct” é o estado em que a ServeRAID declara que o array está irrecuperável — geralmente após falha acima da tolerância de RAID. É um estado deliberado para evitar mais corrupção. O array não pode ser forçado online.
4 – Como a E-Recovery recupera um array da ServeRAID?
Nosso processo é técnico e totalmente seguro:
- Clonagem: Realizamos imaging bit-a-bit de todos os discos do array.
- Reparo (sala limpa): Tratamos discos com falha física se necessário.
- Engenharia reversa: Utilizamos simuladores forenses para analisar os metadados IBM/LSI gravados nos discos.
- Remontagem virtual: Reconstruímos a receita do RAID (ordem, bloco, paridade).
- Extração: O volume (com VMs, bancos de dados, arquivos) é restaurado para exportação segura.
Recuperação de Servidor Lenovo (ThinkSystem, System x)
Seu servidor Lenovo ThinkSystem (ou System x) está offline? O XClarity reporta falha de disco? Não “inicialize” o RAID! Somos especialistas em recuperar arrays RAID de servidores Lenovo.
O seu servidor Lenovo (ThinkSystem, ThinkServer, System x) está apresentando algum destes sintomas?
🚨 Luz de alerta laranja (âmbar) – O painel frontal do servidor está indicando uma falha de disco ou de RAID.
🚫 RAID “inoperante” (inoperative) – O gerenciador de RAID (XClarity, LSI, etc.) mostra o “virtual drive” (array) como “inoperante” ou “failed”.
🖥️ Erro 1801 / 1805 – O servidor para no boot com erros como “erro 1801: config de RAID incompatível” ou “erro 1805: falha no array RAID”.
🧩 “Foreign configuration” – A controladora detecta os discos, mas os marca como “configuração estrangeira” e não consegue importar.
Entendendo a falha do servidor Lenovo (a herança da IBM)
A Lenovo comprou a divisão de servidores x86 da IBM em 2014, continuando a linha System x e lançando a nova e poderosa linha ThinkSystem. Por causa dessa herança, os servidores Lenovo usam controladoras de alta performance (LSI/Broadcom MegaRAID ou controladoras Intel embarcadas em modelos de entrada).
A falha mais comum é idêntica à de Dell e HPE: múltiplos discos falham em um RAID 5 (superando a paridade), a controladora entra em estado crítico após uma queda de energia, ou os metadados ficam corrompidos, impedindo o array de montar.
⚠️ A REGRA DE OURO: NÃO IMPORTE A “FOREIGN CONFIGURATION”!
Assim como nas controladoras Dell PERC, se o seu servidor Lenovo detectar os discos como “foreign”, não utilize a opção “import foreign configuration”.
Se um dos discos estiver “stale” (obsoleto), importar a config pode corromper toda a paridade do array RAID e destruir permanentemente 100% dos dados.
Perguntas Frequentes (FAQ): Recuperação de servidor Lenovo
1 – Quais modelos de servidor Lenovo vocês recuperam?
Nós recuperamos todas as linhas atuais e legadas, incluindo:
- Servidores torre (ThinkSystem ST / ThinkServer TS): st50, st250, st550, st650 v2; ts140, ts440
- Servidores rack (ThinkSystem SR / System x): sr250, sr550, sr630, sr650; system x3650 m5, x3550 m5
- Controladoras: Lenovo RAID 530/730/930, LSI/ Broadcom Megaraid, Intel Vroc
2 – O XClarity está mostrando 2 discos falhos em RAID 5. O que fazer?
Desligue o servidor imediatamente. O RAID 5 só tolera 1 disco falho. Com 2 discos, o array está logicamente morto. Qualquer tentativa de rebuild pode agravar a corrupção.
3 – Qual a diferença entre recuperar um IBM System x e um Lenovo System x?
Tecnicamente, quase nenhuma. Ambos utilizam controladoras baseadas em LSI/Broadcom, gravando metadados equivalentes nos discos. A recuperação segue a mesma engenharia reversa usada em IBM.
4 – Como a E-Recovery recupera um array de um Lenovo?
O processo é 100% forense e totalmente seguro:
- Clonagem: Clonamos (bit-a-bit) todos os discos do seu array ThinkSystem.
- Reparo (sala limpa): Discos com falha física são reparados e estabilizados.
- Engenharia reversa: Usamos um simulador forense para reconstruir a “receita” exata do RAID (ordem, bloco, paridade).
- Remontagem virtual: Remontamos seu RAID 5, 6 ou 10 virtualmente, sem usar a controladora original.
- Extração: O volume (com suas VMs, banco de dados, arquivos) reaparece intacto e é extraído com segurança.
Recuperação de Servidor de Virtualização
Seu Datastore (VMFS) está “offline” ou “inacessível”? Suas VMs (VMDK/VHDX) sumiram? Não tente “recriar” o Datastore! Somos especialistas em recuperar ambientes de virtualização complexos, incluindo VMware, Hyper-V, Proxmox e XenServer.
O seu ambiente de virtualização está apresentando algum destes sintomas?
🚫 Datastore inacessível (VMFS/CSV) – O Host VMware ESXi/vSphere não vê mais o Datastore, ou o Cluster Hyper-V mostra o Volume Compartilhado (CSV) como “offline”.
📂 Arquivos .VMDK / .VHDX sumiram – A pasta do Datastore está vazia, os discos virtuais desapareceram, ou o volume aparece como “não formatado” (RAW).
❌ VM corrompida – A máquina virtual não liga e exibe erros como “arquivo não encontrado”, “disco corrompido” ou “snapshot chain broken”.
🧩 LUN perdida – O Storage (Dell, HPE, Lenovo, Supermicro) perdeu a LUN que continha o Datastore, normalmente após uma falha grave de RAID.
Entendendo a falha de virtualização (a dupla camada)
A perda de VMs acontece em duas camadas simultâneas:
- Camada de hardware (o RAID): Primeiro ocorre a falha física do array – RAID 5 com 2 discos falhos, RAID 6 com 3 discos falhos, ou falha da controladora Dell PERC, HPE Smart Array, Lenovo RAID, LSI ou Broadcom.
- Camada lógica (o Datastore): O volume lógico (LUN) que estava acima desse RAID agora está inacessível. O VMware (VMFS) ou o Hyper-V (NTFS/CSV) não consegue mais montar o volume.
Os arquivos de VM (.VMDK, .VHDX) continuam fisicamente nos discos, mas “fatiados” pelo RAID e presos dentro de um sistema de arquivos que está quebrado.
⚠️ A regra de ouro: não tente “recriar” o Datastore VMFS!
Quando o Datastore some, o vSphere sugere “Create New Datastore”. Não faça isso. Criar um novo Datastore formata a LUN e apaga os metadados (o “mapa”) do VMFS original, destruindo todos os ponteiros dos arquivos .VMDK. O mesmo vale para ferramentas como VMFS-Tools, FSCK ou qualquer tentativa de reparo em cima de um volume instável.
Perguntas frequentes (FAQ): recuperação de máquinas virtuais
1 – Quais sistemas de virtualização vocês recuperam?
Nós recuperamos todas as principais plataformas corporativas, incluindo:
- VMware ESXi / vSphere / vSAN
- Microsoft Hyper-V
- Citrix XenServer / Citrix Hypervisor
- Proxmox VE
- KVM/QEMU
- Oracle VM
- VirtualBox (VDI)
2 – A falha do RAID afeta a recuperação das VMs?
Sim. A recuperação de VM depende 100% da reconstrução forense do RAID.
Não recuperamos “arquivos soltos”, e sim máquinas virtuais inteiras: discos .VMDK, .VHDX, arquivos -flat, snapshots delta e metadados.
3 – Meu Datastore VMFS está “inacessível”. É problema do VMware ou do RAID?
Quase sempre é falha do RAID. O VMFS é extremamente robusto, mas depende totalmente do RAID. Quando o RAID quebra, o VMFS se torna ilegível.
4 – Como a E-Recovery recupera minhas VMs?
O processo é uma reconstrução forense de múltiplas camadas:
- Clonagem: Clonamos bit-a-bit todos os discos físicos do servidor ou Storage.
- Remontagem do RAID: Fazemos engenharia reversa da controladora (Dell PERC, HPE Smart Array, Lenovo RAID, LSI, Broadcom) e reconstruímos o RAID virtualmente (RAID 5, RAID 6, RAID 10).
- Reparo do Datastore: No RAID virtual, reconstruímos o VMFS ou o NTFS/CSV para restaurar os ponteiros dos discos virtuais.
- Extração dos discos virtuais: Recuperamos seus arquivos .VMDK/.VHDX intactos (incluindo snapshots) prontos para importar em um novo Host VMware ou Hyper-V.
Recuperação de Servidor de Banco de Dados
Seu banco de dados (SQL Server, MySQL) está “corrompido”, “suspect” ou “offline”? Não tente o “recovery mode”! Somos especialistas em reparar arquivos mdf/ldf e bancos de dados corrompidos.
O seu servidor de banco de dados (database server) está apresentando algum destes sintomas?
❌ Banco “suspect” (suspeito) – O seu Microsoft SQL Server não consegue montar o banco, exibindo estados como “suspect” ou “recovery pending”.
📄 Arquivo .mdf/.ldf corrompido – O arquivo de dados principal (.mdf) ou o arquivo de log (.ldf) está danificado, ilegível ou foi deletado, impedindo o banco de iniciar.
💾 Falha de RAID – O servidor Dell, HPE ou Lenovo que hospedava o banco falhou (ex: 2 discos em RAID 5) e agora o arquivo do banco está inacessível.
🚫 Tabelas “quebradas” (mysql/mariadb) – O seu banco MySQL ou MariaDB está reportando tabelas “crashed” ou corrupção do InnoDB (ex: “innodb corruption”).
Entendendo a falha do banco de dados (a corrupção lógica)
A recuperação de um banco de dados é um dos processos mais delicados. Na maior parte dos casos, o hardware falhou primeiro. Uma queda de energia ou falha de disco interrompeu a gravação no arquivo do banco (ex: .mdf), causando corrupção interna.
O RAID pode até voltar depois de trocar o disco, mas o arquivo permanece danificado e o motor do banco (SQL, MySQL, Oracle) se recusa a montá-lo por motivos de integridade.
⚠️ A regra de ouro: não rode comandos de reparo (repair_allow_data_loss)!
Quando um banco SQL entra em estado “suspect”, muitos tutoriais sugerem usar DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS. Não faça isso jamais!
Esse comando “conserta” o banco deletando todas as páginas que não consegue ler. O banco até pode subir, mas com perda permanente de tabelas, índices e registros críticos.
Perguntas frequentes (faq): recuperação de banco de dados
1 – Quais bancos vocês recuperam?
Nós recuperamos todas as principais plataformas de banco de dados:
- Microsoft SQL Server (.mdf, .ldf, .ndf)
- MySQL / MariaDB (.ibd, .frm, .myi, ibdata1)
- Oracle (.dbf, .ora)
- PostgreSQL, Firebird e bancos legados como dbase e foxpro
2 – O RAID 5 do meu servidor falhou. A recuperação do banco é separada?
Sim. É um processo em duas etapas:
- Etapa 1: remontamos virtualmente o RAID (Dell PERC, HPE Smart Array, Lenovo RAID, LSI).
- Etapa 2: com o arquivo .mdf/.dbf recuperado, reconstruímos as tabelas e índices por meio de análise forense.
3 – O que significa um banco SQL “suspect”?
Significa que o SQL Server detectou inconsistências graves durante a inicialização e colocou o banco em modo de proteção, impedindo a montagem para evitar danos adicionais.
4 – Como a e-recovery recupera bancos .mdf corrompidos?
Nosso processo é estruturado em quatro fases:
- Clonagem: criamos um clone seguro do arquivo .mdf/.ldf.
- Análise: utilizamos ferramentas forenses específicas para SQL Server, MySQL e Oracle.
- Leitura de páginas: analisamos o arquivo página por página (ex: blocos de 8 kb no SQL Server), recuperando tudo que não foi destruído.
- Extração: reconstruímos tabelas, registros, procedures e índices em um novo banco íntegro, maximizando a preservação dos dados.
Por que Empresas e Departamentos de TI Confiam na E-Recovery
ACOMPANHAMENTO
Cada caso de servidor recebe um especialista dedicado, que será seu ponto de contato exclusivo durante todo o processo de recuperação de dados. nós mantemos você informado de cada etapa de forma proativa, garantindo total transparência sem que você precise solicitar atualizações.
ESPECIALIZAÇÃO
Nós não vendemos peças e não fazemos manutenção geral em computadores. somos 100% focados e especializados em recuperação de dados corporativos. essa dedicação exclusiva nos permite operar com ferramentas avançadas e infraestrutura de laboratório, garantindo índices de sucesso muito superiores ao mercado.
ATENDIMENTO 24X7
Sabemos que um servidor parado significa prejuízo imediato. por isso, casos de alta criticidade recebem prioridade máxima em nosso laboratório. nosso fluxo foi projetado para ser o mais ágil possível, desde o diagnóstico até a entrega dos dados, para que sua empresa volte a operar no menor tempo.
SEM DADOS, SEM CUSTOS
Na grande maioria dos casos, você só realiza o pagamento após validar que os dados essenciais para a sua operação foram recuperados. se, por qualquer motivo, não for possível recuperar o que você precisa, não existe cobrança pelo serviço. todo o risco fica conosco.
CONFIDENCIALIDADE
A segurança dos seus dados é nossa prioridade absoluta. assinamos acordo de confidencialidade (nda) em todos os serviços e operamos em redes isoladas e controladas. nossa equipe é formada por profissionais rigorosamente selecionados, garantindo proteção total das suas informações.
TRANSPARÊNCIA
Oferecemos um diagnóstico preciso e sem compromisso, detalhando causas da falha, arquivos recuperáveis (quando possível) e chances reais de sucesso. com isso, você recebe um orçamento fixo, claro e sem surpresas, sabendo exatamente o investimento necessário antes de autorizar qualquer serviço.
Como Funciona o Processo?
Veja como funciona o processo de recuperação de dados corporativos da E-Recovery — claro, transparente e acompanhado por especialistas em cada etapa.
Contato Inicial e Entrega do Dispositivo
Entre em contato conosco pelo formulário, WhatsApp ou telefone. Assim que seu caso for registrado, um especialista dá as primeiras orientações para garantir a preservação dos dados.
Para entregar os seus servidores, storages, RAIDs, datastores e ambientes virtuais (VMware, Hyper-V, Proxmox):
Matriz – Vila Mariana (SP) – (única unidade habilitada para receber equipamentos corporativos de grande porte)
- Ou você poderá enviar por Correios ou transportadora com rastreamento
Importante: Embale o dispositivo em plástico-bolha e utilize uma caixa firme para protegê-lo durante o transporte.
Diagnóstico e Orçamento
Realizamos uma análise completa do seu dispositivo para identificar a causa da falha e confirmar a viabilidade da recuperação. Após o diagnóstico, você recebe um orçamento detalhado por e-mail, dentro do prazo da modalidade escolhida. O valor é cobrado por dispositivo.
- Avaliação Emergencial (8 horas corridas): R$ 400,00
- Avaliação Expressa (24 horas corridas): R$ 200,00
- Avaliação Gratuita (48 horas úteis): R$ 0,00
Observação Importante:
Para casos de alta complexidade — como servidores com RAID, storages corporativos ou ambientes de virtualização (VMware, Hyper-V, Proxmox, Citrix, etc.) — os valores de análise podem sofrer acréscimo. Antes de iniciar qualquer procedimento, sempre informamos eventuais ajustes e aguardamos sua aprovação.
Recuperação em Laboratório
O serviço de recuperação dos seus dados só é iniciado após sua aprovação formal do orçamento. Todo o processo é realizado exclusivamente em nosso laboratório próprio (localizado na matriz – Vila Mariana), onde utilizamos equipamentos profissionais, ferramentas forenses e técnicas avançadas para garantir a extração segura dos seus dados. Somente após a conclusão das etapas de engenharia reversa, clonagem e reconstrução dos volumes é que iniciamos a extração final dos arquivos ou discos virtuais.
Validação dos Dados Recuperados
Esta é uma das etapas mais importantes do processo. Assim que concluirmos a recuperação, enviaremos a lista completa dos arquivos encontrados no seu storage ou máquina virtual. Você fará a validação diretamente, por acesso remoto (AnyDesk ou UltraViewer), abrindo e testando os arquivos mais importantes para confirmar que tudo está íntegro e utilizável. Só após essa validação é que seguimos para a etapa final.
Pagamento do Serviço
A regra “Sem Dados, Sem Cobrança” (No Data, No Charge) se aplica à grande maioria dos casos. Isso significa que você só realiza o pagamento do serviço de recuperação depois de validar os arquivos e aprovar o resultado. Entretanto, existem situações específicas em que é necessária uma taxa inicial.
Nossa Política de Risco Compartilhado (Importante)
Alguns tipos de recuperação demandam alto investimento em tempo técnico, equipamentos ou peças especializadas. Nesses cenários, é cobrada uma taxa inicial destinada a cobrir parte dos custos de análise, engajamento ou preparação técnica, independentemente do resultado final. Essa taxa se aplica nos seguintes casos:
- Avaliações Expressa e Emergencial
- Casos envolvendo ransomware
- Dispositivos formatados ou com dados deletados
- Discos severamente danificados
- Serviços que exigem compra de peças (como doadores de HD)
- Projetos de alta complexidade (como servidores RAID, volumes muito grandes ou storages corporativos)
Qualquer taxa inicial será sempre informada e detalhada previamente em sua proposta comercial, antes de qualquer aprovação da sua parte.
Entrega e Retirada dos Dados
Após sua aprovação e o pagamento, os dados recuperados são preparados para devolução de forma segura e organizada:
Cópia em mídia física (sem custo adicional) — Você pode fornecer um HD ou SSD novo, e realizaremos a cópia completa dos dados recuperados sem qualquer taxa de gravação.
Entrega via nuvem (serviço opcional) — Caso prefira receber os dados por Google Drive ou OneDrive, a transferência será feita de forma segura. Trata-se de um serviço adicional, com custo informado previamente na proposta.
Local de retirada — Por motivos de segurança e controle de acesso, a retirada do dispositivo original e da nova mídia com os dados é feita exclusivamente em nossa matriz, na Vila Mariana (SP).
Encerramento e Apagamento Seguro dos Dados
Para garantir sua privacidade e a segurança total das informações, seguimos uma política rígida de retenção e eliminação de dados. Após a entrega dos seus dados recuperados, mantemos uma cópia de segurança em nossos servidores por um período de 7 (sete) dias corridos, exclusivamente como medida preventiva caso você precise baixar novamente algum arquivo.
Passado esse prazo, essa cópia é permanentemente excluída de nossos sistemas por procedimentos automáticos e auditáveis. A partir desse momento, o serviço é considerado totalmente encerrado.
Por isso, é fundamental que você revise os arquivos entregues e faça seu próprio backup assim que recebê-los, garantindo a proteção contínua dos seus dados.
O Que Gerentes de TI Falam sobre a E-Recovery
Grandes empresas confiam na E-Recovery, você também pode confiar!
Depoimento do sr. Cardoso da Gráfica de Segurança Formflex (Carapicuíba/SP) referente recuperação de dados de um NAS Seagate configurado com RAID 5.
Depoimento de Christian Uhlmann sobre um NAS QNAP configurado em RAID 1 que ficou subitamente inacessível pela rede, causado por dois discos danificados
“Excelente profissionalismo da empresa. Tive problemas de queda de energia onde danificaram alguns HDs e desmontou todo o Array do RAID. Falei que precisava com urgência dos dados, o Sr. Orlando juntamente com sua equipe se prontificou de imediato, e deu uma atenção excepcional, atendendo todas as minhas expectativas. Negociei os valores também, explicando nossa (empresa) situação. E o mesmo nós ajudou também com a parte financeira. Excelente empresa e profissionais.”
Estudo de Caso: Falha de RAID 5 em Servidor Dell Pós-Queda de Energia
O Cliente: O Comitê Paralímpico Brasileiro / Fernando Andrade Ulhôa.
O Desafio (O Problema): O Comitê enfrentou um cenário de desastre em seu data center após uma queda de energia que ocasionou falhas físicas em vários discos de um Servidor Dell configurado com 7 HDs em RAID 5. A oscilação elétrica causou danos graves, resultando em múltiplos discos com defeitos e na completa desestruturação do array RAID, deixando todos os dados inacessíveis em um momento crítico para a instituição.
A Solução (O Processo da E-Recovery): Diante da urgência, nossa equipe iniciou o processo imediatamente. A recuperação de um RAID 5 com vários discos fisicamente degradados é altamente complexa e exige precisão técnica:
Diagnóstico e Reparo: Todos os 7 discos passaram por análise individual. Aqueles com falhas físicas decorrentes da queda de energia foram encaminhados para nossa Sala Limpa, onde foram estabilizados para permitir a extração segura dos dados.
Clonagem Forense: Cada disco foi submetido à clonagem bit-a-bit utilizando equipamentos forenses de alta precisão, garantindo a obtenção da maior quantidade possível de dados, mesmo em áreas com setores danificados.
Engenharia Reversa (RAID 5): Com os clones estabilizados, nossos engenheiros realizaram a engenharia reversa para identificar a ordem exata dos discos, o tamanho do bloco, a paridade e quais unidades estavam “stale” (obsoletas), condição típica em falhas simultâneas.
Remontagem Virtual: Após identificar os parâmetros corretos, reconstruímos virtualmente o RAID 5 em nossos servidores especializados. A paridade dos discos íntegros foi usada para regenerar as partes faltantes dos discos danificados.
O Resultado (Sucesso Total): O array de 7 discos foi totalmente reconstruído, permitindo a recuperação integral dos dados críticos do Comitê Paralímpico Brasileiro. O processo atendeu plenamente à urgência do cliente e demonstrou a eficácia da engenharia forense aplicada pela E-Recovery.
Mais de 250 Depoimentos de Clientes Satisfeitos
Com uma avaliação ⭐⭐⭐⭐⭐ de 4.9 / 5.0 em mais de 110 depoimentos no Google, e muitas outras história de sucesso compartilhadas diretamente em nosso site, a satisfação dos nossos clientes fala por si.
Descubra por que tantos confiam em nós para a recuperação de seus dados mais valiosos. Clique no botão abaixo e veja porque a E-Recovery é empresa com melhor reputação do mercado.
Não arrisque seus dados. Fale com um especialista em Servidores agora!
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
FORMULÁRIO DE SOLICITAÇÃO DE ORÇAMENTO:
Dúvidas Gerais sobre a Recuperação de Servidor
Veja as perguntas mais comuns sobre recuperação de dados de RAID. Se a sua dúvida for outra, entre em contato com nossa equipe de atendimento.
O diagnóstico para um Servidor (Dell, HPE, IBM) é gratuito?
Sim, 100% gratuito e sem compromisso paara orçamentos feito no prazo normal. Entendemos que uma falha de servidor é um evento crítico. Nossos especialistas farão uma análise completa de todos os discos para identificar a falha (seja ela nos discos, na controladora RAID ou lógica/VMs) e o potencial de recuperação. Você receberá um laudo técnico e um orçamento fixo antes de qualquer serviço.
E se meus dados não puderem ser recuperados? Eu pago mesmo assim?
Nossa política “Sem Dados, Sem Custo” (No Data, No Fee) é válida para a grande maioria dos casos, EXCETO volumes formatados, dados deletados, ataque de ransomware, HDs com necessidade de investimento em peças ou servidores com muitos discos ou volumes de grande capacidade.
Eu preciso enviar o Servidor (gabinete, rack) inteiro?
NÃO. Envie APENAS OS DISCOS (HDs/SSDs). Nós não precisamos do seu hardware (o chassi do PowerEdge, ProLiant, etc.). Nosso laboratório possui controladoras e equipamentos forenses próprios para remontar todos os tipos de RAID.
A ordem dos discos dento do servidor importa?
SIM! ESTE É O PASSO MAIS IMPORTANTE! Antes de remover os discos, use uma fita crepe ou caneta de retroprojetor e numere a ordem exata em que eles estavam nas baias do servidor (ex: Disco 0, Disco 1, Disco 2, Disco 3…). Enviar os discos fora de ordem pode atrasar o diagnóstico (ou, em casos raros, inviabilizar a recuperação).
Quanto tempo demora a recuperação de um Servidor?
Entendemos que um servidor parado significa prejuízo. Casos de Servidor/RAID têm prioridade máxima em nosso laboratório.
Diagnóstico: Concluído em até 24 horas úteis.
Problemas Lógicos/Firmware: (Ex: RAID 5 com 2 discos falhos, “Foreign Configuration”, VMs corrompidas). 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 (um processo de “transplante”) para depois cloná-los e remontar o RAID.
Meu servidor rodava Máquinas Virtuais (VMware/Hyper-V). Vocês recuperam as VMs?
Sim. Essa é a nossa especialidade. Não recuperamos apenas “arquivos”; nós recuperamos sistemas inteiros. Nosso processo inclui a reconstrução do datastore (como VMFS, no caso do VMware) e a extração dos arquivos de máquina virtual (VMDK, VHDX) intactos, prontos para serem “importados” em um novo servidor
Como eu recebo meus dados de volta?
Nós nunca gravamos os dados de volta no seu array de discos original (ele está danificado e instável). Os dados recuperados (suas VMs, bancos de dados, etc.) são salvos em uma mídia nova (geralmente um novo HD externo de grande capacidade), que você deverá fornecer.
