Recuperar um servidor pode exigir atravessar controladora RAID, discos SAS/SATA/NVMe, volume lógico, NTFS/ReFS/EXT4/XFS, datastore VMware, VHDX do Hyper-V, storage Proxmox e banco de dados. A ação correta depende de qual camada realmente falhou.
O que é recuperação de servidor?
Um servidor parado não significa automaticamente que os discos perderam os dados. O problema pode estar em rede, serviço, boot, controladora, cache, RAID, LUN, filesystem ou hipervisor. A primeira decisão de recuperação é identificar a camada da falha sem transformar um incidente de disponibilidade em perda permanente de dados.
Guia completo de recuperação de servidor
Servidor inacessível não é um diagnóstico: primeiro separe quatro cenários
1. Rede ou serviço
Servidor ligado, storage saudável, mas aplicação, SMB, RDP, banco ou serviço não responde. Aqui o primeiro caminho é conectividade, serviço, firewall, DNS e logs, não desmontar o RAID.
2. Boot ou sistema operacional
Windows Server, Linux ou hypervisor não inicializa, mas o volume de dados pode estar íntegro. Reinstalar no mesmo storage antes de preservar pode sobrescrever arquivos úteis.
3. RAID ou hardware de storage
Discos offline, PERC Foreign, Smart Array degraded, cache com alerta, LUN sumiu ou múltiplos membros falharam. Este é o cenário em que a topologia física e os metadados precisam ser preservados.
4. Perda lógica ou ransomware
Servidor continua operacional, mas arquivos, VMs, volumes ou bancos foram apagados, formatados ou criptografados. A estratégia passa a ser contenção, snapshots, backups e análise lógica.
Principais sintomas em servidores com risco de perda de dados
RAID Degraded
Um ou mais membros saíram do array. O servidor pode continuar online, mas a redundância foi reduzida.
Foreign Configuration
Controladora Dell PERC ou Broadcom detecta configuração de discos diferente da atualmente carregada.
Logical Drive Failed
Controladora não consegue apresentar o virtual disk ou logical drive normalmente.
Rebuild travado
Reconstrução desacelera ou para quando outro membro apresenta setores defeituosos ou timeouts.
Servidor não inicializa
POST, bootloader, Windows, Linux ou hypervisor não completam a inicialização.
Predictive Failure
iDRAC, iLO, SSA, SMART ou BMC indicam risco crescente em um ou mais discos.
Datastore offline
ESXi vê o dispositivo, mas VMFS ou o datastore deixou de montar, deixando VMs inacessíveis.
Volume RAW ou corrompido
NTFS, ReFS, EXT4 ou XFS não montam ou pedem repair, format ou fsck.
Ransomware
Arquivos, VMs e bancos são criptografados enquanto hardware e RAID podem permanecer saudáveis.
Por que recuperação de servidor pode exigir reconstruir sete camadas
| Camada | Exemplos | Falha típica | Objetivo da recuperação |
|---|---|---|---|
| 1. Mídia | SAS, SATA, NVMe, HDD, SSD | Bad blocks, heads, firmware, NAND, eletrônica | Obter leitura estável ou clone |
| 2. Controladora | Dell PERC, HPE Smart Array, Broadcom MegaRAID | Foreign, cache, firmware, controller failed | Preservar parâmetros e membros |
| 3. RAID / LUN | RAID 0/1/5/6/10/50/60, Storage Spaces, mdraid | Degraded, offline, paridade inconsistente | Reconstruir fluxo lógico de blocos |
| 4. Filesystem | NTFS, ReFS, EXT4, XFS, ZFS | RAW, corrupt, journal, metadata | Reconstruir diretórios e arquivos |
| 5. Hypervisor | VMware ESXi, Hyper-V, Proxmox | Datastore offline, storage missing | Localizar discos virtuais e configuração |
| 6. Máquina virtual | VMDK, VHDX, QCOW2, raw | Snapshot chain, descriptor, filesystem interno | Validar VM e seus discos |
| 7. Aplicação | SQL Server, Oracle, PostgreSQL, MySQL, ERP | Datafile inconsistente, logs ausentes | Validar integridade transacional e dados úteis |
12 passos para preservar um servidor antes da recuperação
O que não fazer com servidor, RAID ou datastore em falha
Clear Foreign sem preview
Dell documenta que Clear Foreign Configuration apaga informações de virtual disk dos discos anexados. Em dados críticos, preserve e analise antes de limpar.
Rebuild automático com outro membro instável
HPE alerta que uma nova falha durante período sem tolerância pode causar perda do array. Rebuild exige leitura intensa dos sobreviventes.
CHKDSK /f, /r ou /x no único volume
Microsoft informa que esses parâmetros corrigem erros. Em recovery, primeiro preserve o estado que você pode precisar reconstruir.
fsck / xfs_repair sem imagem
Ferramentas de reparo podem modificar filesystem. Red Hat recomenda preservar uma imagem de metadados antes de xfs_repair em troubleshooting.
Atualizar firmware para ver se volta
Update de PERC, Smart Array, discos ou hypervisor é manutenção. Em perda de dados, altera o ambiente sem garantir acesso.
Criar novo datastore, volume ou array
Inicializar, formatar ou criar estruturas novas pode sobrescrever metadados e alocações ainda necessárias para a recuperação.
Veja na prática como a análise de um servidor RAID 5 é estruturada
Este vídeo da SECURITY conecta o conteúdo do artigo ao diagnóstico de um ambiente realista de servidor, mostrando por que cada disco precisa ser analisado individualmente e por que RAID não substitui backup.
No vídeo, a análise do RAID é apresentada em conjunto com clonagem, VMs e o alerta de que RAID não é backup.
Como funciona a recuperação profissional de servidor na SECURITY
Onde entram PC-3000, DeepSpar e análise RAID Low Level?
PC-3000 pode ser utilizado para acesso técnico a HDDs e SSDs suportados, principalmente em falhas físicas, firmware e controladora da própria mídia. DeepSpar pode auxiliar imaging de HDDs instáveis. A análise RAID Low Level entra na reconstrução dos dados distribuídos após a melhor aquisição possível dos membros.
Dell PERC, HPE Smart Array e Broadcom MegaRAID: onde a recuperação pode dar errado
Dell PERC e Foreign Configuration
A documentação Dell oferece funções para visualizar, importar e limpar configurações estrangeiras. Em servidores com discos reinseridos ou movidos, Import pode ser o procedimento correto quando a configuração corresponde ao array que precisa ser recuperado. Clear, por outro lado, remove informações de virtual disk associadas aos discos estrangeiros e a própria Dell alerta para risco de perda.
HPE Smart Array
HPE documenta rebuild como parte normal da restauração de fault tolerance. A mesma documentação alerta que, se outro disco do array falhar enquanto a tolerância está indisponível durante o rebuild, pode ocorrer erro fatal e perda dos dados do array. Isso justifica avaliar predictive failures e mídia instável antes de iniciar uma leitura integral.
Broadcom / LSI MegaRAID
Controladoras MegaRAID também trabalham com virtual drives, foreign configurations, cache e políticas próprias. Em servidores Supermicro, Lenovo, whitebox e storages OEM, o hardware pode variar enquanto a lógica continua semelhante: preserve membros e metadados antes de criar uma configuração nova.
RAID 0, 1, 5, 6, 10, 50 e 60 em servidores
| Nível | Arquitetura | Falha típica | Ponto de recuperação |
|---|---|---|---|
| RAID 0 | Striping sem redundância | Qualquer membro ausente interrompe faixas de dados | Todos os discos são críticos |
| RAID 1 | Espelhamento | Um mirror pode estar mais antigo ou degradado | Comparar cópias antes de escolher a fonte |
| RAID 5 | Uma paridade distribuída | Segundo disco falha durante rebuild | Usar melhores leituras + paridade quando possível |
| RAID 6 | Duas paridades | Terceiro membro com erros ou múltiplas lacunas | Reconstrução depende de quais stripes foram afetadas |
| RAID 10 | Mirrors + striping | Falhas atingem os dois membros de um mesmo mirror | Identificar pares e ordem |
| RAID 50 | Stripe sobre grupos RAID 5 | Falhas concentradas no mesmo grupo | Reconstruir grupos e depois a camada superior |
| RAID 60 | Stripe sobre grupos RAID 6 | Falhas além da paridade dentro de um grupo | Topologia de grupos é essencial |
Hot spare não é backup. Cache de controladora não é backup. RAID reduz indisponibilidade prevista, mas não protege contra exclusão, ransomware, corrupção lógica, erro administrativo ou falhas múltiplas além da tolerância.
NTFS, ReFS, EXT4 e XFS: repair não é sinônimo de recuperação
Windows Server: NTFS e ReFS
A Microsoft descreve CHKDSK como ferramenta que verifica filesystem e metadados. Sem parâmetros, ele pode exibir status; com /f, /r, /x ou /b, corrige erros. Isso é útil em manutenção normal, mas em um volume crítico e sem cópia significa alterar o filesystem antes de saber exatamente o que será preservado.
Linux: EXT4
fsck e e2fsck verificam e podem reparar filesystems. Em RAID ou LVM, o filesystem final só deve ser analisado depois de reconstruir corretamente as camadas inferiores. Rodar fsck em um membro isolado de RAID não representa o volume real.
XFS
Red Hat orienta criar um metadata image antes do xfs_repair para troubleshooting e investigação. Isso ilustra um princípio maior: em dados críticos, registre o estado antes de uma ferramenta que corrige metadados.
VMware, Hyper-V e Proxmox: recuperar o RAID é apenas a primeira etapa
VMware ESXi / VMFS
Broadcom documenta VMFS datastores como repositórios de arquivos de máquinas virtuais. Após recuperar a camada de storage, é preciso localizar VMFS, VMDKs, descriptors, snapshots e arquivos de configuração.
Microsoft Hyper-V
VHD e VHDX são formatos de discos virtuais usados pelo Hyper-V. Checkpoints podem criar dependências adicionais que precisam ser validadas antes de anexar ou mesclar.
Proxmox VE
Documentação Proxmox mostra suporte a ZFS, LVM, LVM-thin, Ceph e outros backends. A recuperação muda conforme onde o disco da VM estava realmente armazenado.
VMFS, VMDK e datastore
Um datastore pode estar sobre um virtual disk da controladora, SAN, iSCSI LUN, FC ou NVMe. Portanto, "recuperar a VM" pode exigir reconstruir mídia, RAID, LUN, datastore e VMDK antes de chegar ao filesystem dentro da máquina virtual.
VHDX e checkpoints
No Hyper-V, um VHDX pode depender de checkpoints e arquivos diferenciais. Copiar apenas um arquivo sem entender a cadeia pode produzir uma VM incompleta. A validação deve identificar base, differencing disks e filesystem interno.
Proxmox, ZFS e Ceph
Em Proxmox, um volume de VM pode estar em ZFS, LVM-thin, Ceph RBD ou storage de arquivos. Em Ceph, o problema deixa de ser RAID local simples e passa a envolver objetos distribuídos e estado do cluster.
SQL Server, Oracle, PostgreSQL e MySQL: arquivo recuperado não significa banco consistente
Depois de reconstruir storage e filesystem, bancos de dados precisam de validação própria. Uma cópia de MDF, LDF, tablespaces, WAL, redo logs ou arquivos InnoDB pode existir fisicamente e ainda apresentar inconsistência transacional.
SQL Server
MDF/NDF e LDF devem ser analisados em conjunto com estado do filesystem, snapshots e momento da falha.
Oracle
Datafiles, control files, redo e archive logs podem ser necessários para uma recuperação consistente do banco.
PostgreSQL / MySQL
Data directories, WAL/binlogs e mecanismos de storage possuem relações próprias. Extração de arquivos é apenas a primeira validação.
Em ambientes virtualizados, ainda existe mais uma camada: o banco pode estar dentro de uma VM que depende de um disco virtual que depende de um datastore que depende de um RAID. É por isso que recuperação de servidor precisa ser conduzida de baixo para cima.
Servidor criptografado: recuperação de dados e resposta ao incidente precisam caminhar juntas
Ransomware pode atingir arquivos locais, compartilhamentos, VMs, snapshots e backups conectados. O primeiro objetivo é impedir novas alterações e preservar informações que permitam entender a variante e o alcance.
A estratégia pode envolver recuperação de arquivos originais apagados, snapshots, cópias offline, reconstrução de VMs ou descriptografia quando existe método válido. Nenhuma dessas rotas deve ser prometida sem analisar a variante e o ambiente.
Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, IBM System x e Supermicro
A marca do servidor ajuda a identificar ferramentas de gerenciamento e controladoras comuns, mas a recuperação é definida pela arquitetura efetiva do storage.
Dell PowerEdge
PERC, iDRAC, SAS/SATA/NVMe, virtual disks e Foreign Configuration são termos frequentes. Preview de Foreign é informação valiosa antes de Import ou Clear.
HPE ProLiant
Smart Array, HPE SSA, iLO e predictive failure ajudam a identificar estado de logical drives e physical drives.
Lenovo ThinkSystem
XClarity, RAID adapters e storage SAS/NVMe aparecem em diferentes gerações. Preserve event logs e mapeamento de bays.
IBM System x
Ambientes legados podem usar ServeRAID e arranjos antigos ainda em produção. Firmware e gerações de controladora precisam ser documentados.
Supermicro
É comum encontrar IPMI/BMC e controladoras Broadcom/LSI, HBAs ou storage definido pelo integrador.
Custom / Whitebox
Servidores montados sob medida podem usar mdraid, ZFS, Storage Spaces ou controladoras avulsas. Inventário é ainda mais importante.
Cenários técnicos de recuperação de servidor
Dell PowerEdge com PERC em Foreign Configuration após falha de controladora
Contexto: o servidor não apresenta o virtual disk original após troca ou reset da controladora. Os membros aparecem como Foreign.
Ação de risco: usar Clear Foreign para "limpar o erro" ou criar um novo virtual disk com os mesmos discos.
Estratégia: registrar preview, seriais, ordem dos bays e configuração observada. Se houver dúvida sobre integridade do conjunto, adquirir os membros e reconstruir virtualmente antes de modificar a controladora.
Aprendizado: Import e Clear são funções reais da PERC. O risco está em escolher sem compreender qual metadata corresponde ao array válido.
HPE ProLiant RAID 5 com segundo disco falhando durante rebuild
Contexto: um membro foi substituído e o Smart Array inicia rebuild. Durante o processo, outro HDD registra media errors e timeouts.
Ação de risco: reiniciar o rebuild repetidamente até tentar completar.
Estratégia: parar novas escritas quando os dados são únicos, avaliar os membros e adquirir primeiro os discos instáveis. A reconstrução usa imagens e paridade conforme os melhores blocos disponíveis.
Aprendizado: rebuild é manutenção legítima. O cenário se transforma em recuperação quando a redundância remanescente também está comprometida.
VMware ESXi com VMFS inacessível após colapso do RAID 6
Contexto: ESXi ainda inicializa por boot separado, mas o datastore que contém VMs desapareceu depois de múltiplas falhas no array.
Ação de risco: criar novo datastore no mesmo LUN ou inicializar o volume para fazê-lo reaparecer.
Estratégia: reconstruir RAID/LUN sobre imagens, localizar VMFS, extrair VMDKs e validar VMs prioritárias em ambiente separado.
Hyper-V com VHDX e banco SQL após corrupção do volume
Contexto: host Windows Server inicia, mas o volume ReFS/NTFS que contém VHDX fica inacessível.
Ação de risco: rodar repair no único volume e depois mesclar checkpoints sem cópia.
Estratégia: preservar o storage, recuperar a árvore de VHDX e checkpoints e, por fim, validar o SQL Server dentro da VM.
Servidor Proxmox com ZFS e múltiplas VMs após falha de HDD
Contexto: pool ZFS fica degradado e uma segunda mídia começa a apresentar erros de leitura.
Ação de risco: insistir em resilver sobre um membro fisicamente instável sem backup confirmado.
Estratégia: adquirir as mídias críticas, reconstruir o pool e depois validar volumes raw/qcow2 e VMs.
Perguntas frequentes sobre recuperação de servidor
Servidor com RAID degradado tem recuperação?
Pode ter. Um RAID degradado ainda pode estar dentro da tolerância prevista ou já ter outros membros com erros de leitura. A viabilidade depende do nível RAID, estado de cada disco, controladora, metadados do array e intervenções já realizadas. Se os dados são críticos e outro disco apresenta alertas, preserve antes de iniciar novo rebuild.
Foreign Configuration na Dell PERC significa que os dados foram perdidos?
Não. Foreign Configuration significa que a controladora detectou metadados de configuração nos discos que não correspondem ao estado atualmente carregado. A Dell fornece funções de preview, import e clear. Import pode ser correto em cenários compatíveis, enquanto Clear apaga informações de configuração e exige extremo cuidado. Em dados sem backup, registre o estado antes de escolher qualquer ação.
Posso trocar a controladora RAID que queimou?
Pode ser possível substituir por hardware compatível em manutenção normal, mas isso não deve ser feito às cegas em perda de dados. Firmware, cache, metadados e políticas da controladora podem afetar a montagem do array. Quando o volume está inacessível, a opção mais conservadora é preservar os discos e reconstruir o RAID virtualmente quando necessário.
Rebuild de RAID é sempre perigoso?
Não. Rebuild é um procedimento normal para restaurar redundância quando apenas o número esperado de membros falhou e os demais estão saudáveis. O risco aumenta quando outro disco apresenta setores defeituosos, timeouts ou predictive failure. A HPE alerta que uma nova falha durante período sem tolerância pode causar perda do array.
CHKDSK pode ser usado para recuperar um servidor?
CHKDSK sem parâmetros pode verificar o status. Com parâmetros como /f, /r, /x ou /b, a Microsoft informa que ele corrige erros no volume. Em dados críticos e storage instável, uma ferramenta que modifica filesystem não deve ser a primeira ação antes de preservar a origem.
fsck ou xfs_repair podem ser executados em volume crítico?
Essas ferramentas existem para verificar e reparar filesystems Linux e podem modificar estruturas quando usadas em modo de reparo. Red Hat recomenda, por exemplo, criar uma imagem de metadados antes de xfs_repair. Em recuperação, trabalhar sobre clone ou imagem reduz o risco de alterar o único estado disponível.
VMware ESXi com datastore VMFS inacessível tem recuperação?
Pode ter. VMFS é um datastore usado para armazenar arquivos de máquinas virtuais e pode estar sobre RAID, SAN, LUN ou armazenamento local. A recuperação normalmente exige estabilizar a camada física, reconstruir RAID ou LUN, localizar o VMFS e depois validar VMDK, snapshots e arquivos de configuração.
Hyper-V com VHDX perdido pode ser recuperado?
Pode ser possível quando o storage subjacente ainda fornece dados. VHD e VHDX são formatos de disco virtual usados pelo Hyper-V. Após recuperar o volume físico ou RAID, é necessário validar a cadeia de VHDX, checkpoints e filesystem interno da máquina virtual.
Proxmox com ZFS, LVM ou Ceph muda a recuperação?
Sim. Proxmox VE suporta diferentes backends de storage, incluindo ZFS, LVM, LVM-thin e Ceph. Cada arquitetura distribui e referencia os discos virtuais de forma diferente. A recuperação precisa reconstruir o backend antes de validar raw, qcow2 ou volumes de VM.
Servidor não inicializa, mas os dados podem estar intactos?
Sim. Falha de boot pode estar no sistema operacional, boot volume, controladora, firmware ou hardware do servidor, enquanto o volume de dados permanece preservado. É importante separar boot do storage de produção antes de reinstalar ou formatar.
iDRAC, iLO, XClarity ou IPMI ajudam na recuperação?
Ajudam no diagnóstico. Esses sistemas de gerenciamento podem registrar falhas de discos, controladora, energia, temperatura e eventos de hardware. Capturar os alertas antes de alterar o servidor fornece contexto sem escrever nos volumes de dados.
Servidor com ransomware deve ser desligado?
Se o ataque está ativo, a prioridade é isolar o servidor da rede e impedir novas gravações ou propagação. O estado ideal de desligamento depende do incidente e da necessidade de preservar evidências voláteis, por isso resposta a ransomware pode envolver equipe de segurança. Para recuperação de dados, não apague arquivos cifrados, ransom notes ou logs antes da análise.
É necessário enviar o servidor inteiro?
Nem sempre. Em muitos casos, discos, SSDs e informações da controladora são suficientes para análise, desde que a ordem das baias e o contexto sejam preservados. Em situações com hardware proprietário, cache, storage externo ou dúvidas sobre backplane, o equipamento ou componentes adicionais podem ser relevantes.
A SECURITY recupera servidores Dell, HPE, Lenovo, IBM e Supermicro?
A SECURITY trabalha com recuperação de dados em ambientes de servidores e arrays de diferentes fabricantes. A análise é baseada na arquitetura real do storage, controladora, RAID, filesystem, virtualização e aplicação, e não apenas na marca do chassi.
A SECURITY atende servidores de todo o Brasil?
Sim. A SECURITY atende clientes de diferentes regiões do Brasil e orienta a logística conforme o equipamento e a criticidade. Em Barueri, este artigo prioriza Alphaville, além de pontos de atendimento em São Paulo e Campinas.
Atendimento para recuperação de servidor em São Paulo e todo o Brasil
A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio ou logística conforme os componentes envolvidos. Em Barueri, este artigo prioriza Alphaville.
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 em recuperação de dados, incluindo RAID, servidores, NAS, HD, SSD, PC-3000, Data Extractor, Linux, banco de dados e análise RAID Low Level.
Servidor por dentro: controladora, RAID, LUN, filesystem, VM e banco de dados
Esta seção aprofunda as estruturas que mais influenciam a recuperação e evita simplificações que podem levar a procedimentos incorretos em ambientes corporativos.
1. A ordem das camadas define a ordem da recuperação
Um arquivo de produção pode estar dentro de um banco SQL que está dentro de uma VM que está dentro de um VMDK que está dentro de um datastore VMFS que está sobre um LUN RAID. Recuperar a camada superior sem reconstruir corretamente a inferior produz dados incompletos ou inconsistentes.
2. Controladora RAID não é o local dos dados
A controladora mantém configuração, cache, políticas e acesso aos membros, mas os dados persistentes estão distribuídos nas mídias. Em muitos casos, é possível reconstruir o layout fora da controladora, desde que se preserve a ordem e o conteúdo dos discos.
3. Metadata Foreign deve ser interpretada, não apagada por reflexo
Dell oferece Preview, Import e Clear Foreign Configuration. O simples aparecimento de Foreign não prova corrupção. Clear é potencialmente destrutivo para as informações de virtual disk nos discos estrangeiros. Import pode ser correto quando a configuração representa o array original. Em recovery, primeiro determine qual estado é válido.
4. Stripe size, ordem, offset e paridade
RAID distribui blocos de acordo com parâmetros específicos. Quando os metadados estão ausentes ou incoerentes, análise Low Level busca assinaturas de filesystem, sequências de dados e relações de paridade para inferir o layout. Em RAID 5 e 6, algoritmo e rotação de paridade importam tanto quanto a ordem física.
5. Cache de controladora e write-back
Controladoras empresariais podem usar cache protegido por bateria ou flash. Uma falha de cache ou energia pode deixar writes em estado diferente do esperado. O diagnóstico deve registrar alertas de cache e não presumir que todo volume offline é resultado de falha de disco.
6. SAS, SATA e NVMe no mesmo servidor
Servidores modernos podem ter boot em M.2 ou BOSS, data RAID em SAS/SATA e tier de NVMe. O inventário precisa separar cada conjunto. Um boot device morto pode impedir inicialização enquanto o array de dados continua íntegro.
7. Rebuild reconstrói redundância, não dados apagados
Rebuild copia ou recalcula o conteúdo necessário para um novo membro. Ele não serve para recuperar arquivo deletado, desfazer ransomware ou reparar filesystem. Seu objetivo é devolver redundância ao array.
8. Por que um segundo disco instável muda tudo
Durante rebuild, todos os membros restantes são lidos extensivamente. HPE documenta o risco de nova falha enquanto a tolerância está indisponível. Se o segundo membro já apresenta media errors, a prioridade pode mudar de manutenção para aquisição.
9. Filesystem repair e data recovery possuem objetivos diferentes
CHKDSK, fsck e xfs_repair tentam levar o filesystem a um estado consistente. Recuperação de dados tenta preservar o máximo de estruturas e conteúdo para extrair informações. Em alguns casos os objetivos convergem; em outros, o repair pode descartar referências que ainda seriam úteis para recuperação manual.
10. VMFS é uma camada de storage especializada
Broadcom descreve VMFS datastore como repositório de arquivos de VM. Uma vez reconstruído o LUN ou RAID, o VMFS precisa ser localizado para recuperar VMDK, VMX, snapshots e outros arquivos. A presença de um VMDK não prova que a VM está consistente.
11. VHDX e checkpoints
Hyper-V usa VHD/VHDX como discos virtuais. Checkpoints podem criar discos diferenciais. A cadeia correta precisa ser preservada antes de merge ou attach, especialmente quando houve perda parcial de arquivos.
12. Proxmox pode não ter um filesystem simples com arquivos QCOW2
Em Proxmox VE, storage pode ser ZFS, LVM-thin ou Ceph, onde o disco da VM pode existir como volume ou objeto e não como arquivo comum. A recuperação deve respeitar o backend original.
13. Bancos de dados exigem integridade além do arquivo
MDF, datafiles, WAL, redo, binlogs e tablespaces podem depender de relações temporais. Uma VM que inicializa não garante que um banco está consistente. A entrega deve validar as estruturas prioritárias sempre que possível.
14. Ransomware pode atingir VMs e backups conectados
Hipervisores e compartilhamentos administrativos podem ampliar o alcance de um incidente. Recuperação deve ser acompanhada de contenção, credenciais novas e restauração em ambiente limpo. Recolocar um volume recuperado no ambiente comprometido pode causar nova criptografia.
15. Hot spare, RAID e snapshots não substituem backup
Hot spare acelera rebuild. RAID reduz indisponibilidade de falhas previstas. Snapshot ajuda a voltar a estados anteriores. Nenhum deles, isoladamente, substitui uma cópia independente e testada fora do domínio de falha principal.
16. Segundo laboratório ou tentativas anteriores
Trocas de controladora, rebuilds, repairs, clonagens e alterações de ordem fazem parte do estado atual. Uma segunda opinião deve reconstruir a cronologia e nunca prometer que o caso voltará ao estado anterior às intervenções.
17. Matriz técnica de decisão
| Sintoma | Camada provável | Prioridade | Evitar |
|---|---|---|---|
| Servidor sem rede, storage saudável | Rede / serviço / sistema | Troubleshooting não destrutivo | Desmontar RAID sem necessidade |
| Foreign Configuration | Controladora / metadados RAID | Preview + registrar topologia | Clear às cegas |
| RAID Degraded | Disco / array | Backup + saúde dos membros | Rebuild com segundo disco instável |
| Rebuild travado | Mídia / paridade | Diagnóstico e clonagem | Repetir sem entender erro |
| Volume RAW | RAID ou filesystem | Preservar camada física | Formatar ou repair no original |
| VMFS offline | LUN / datastore | Reconstruir storage e VMFS | Criar datastore novo |
| VHDX/VM não inicia | Hyper-V / cadeia de discos | Preservar base e checkpoints | Merge sem cópia |
| Banco inconsistente | Aplicação | Validar datafiles + logs | Assumir sucesso pela presença do arquivo |
| Ransomware | Segurança / dados | Isolar e preservar evidências | Conectar backup limpo ao ambiente comprometido |
18. Conclusão técnica
O melhor protocolo de recuperação de servidor não é uma lista universal de proibições. É uma árvore de decisão. Troubleshooting normal continua válido quando o hardware e os dados estão saudáveis. Rebuild e Import Foreign continuam sendo ferramentas legítimas em cenários corretos. A mudança para recuperação especializada acontece quando a redundância acabou, outro disco está instável, o volume já foi alterado ou os dados não possuem cópia validada.
Referências utilizadas neste guia
As páginas da E-Recovery e Crowdertech foram usadas como benchmark editorial, de intenção de busca e cobertura semântica. As afirmações técnicas da SECURITY foram redigidas de forma original e confrontadas com documentação primária de fabricantes e plataformas.
- Dell: Import Foreign Configuration em controladoras RAID
- Dell: Clearing Foreign Configuration e alerta de perda
- HPE Smart Array: Drive Procedures e risco durante rebuild
- Microsoft Learn: CHKDSK
- Microsoft Learn: troubleshooting de corrupção e disk errors
- Red Hat: checking and repairing filesystems
- Broadcom VMware: VMFS Datastore Concepts
- Microsoft: VHD e VHDX
- Proxmox VE: Storage
- SECURITY YouTube: {video_title}
