RAID 0, 1, 5, 6, 10, 50 e 60, Dell PERC, HPE Smart Array, Broadcom MegaRAID, mdadm, Storage Spaces, Intel VROC e ZFS exigem diagnósticos diferentes. Em dados críticos, a prioridade é registrar a topologia, avaliar cada membro e separar manutenção normal de um caso real de recuperação.
O que é recuperação de RAID?
RAID é uma camada de armazenamento. O dado útil pode estar muito acima dela: NTFS, ReFS, EXT4, XFS, Btrfs, ZFS, VMFS, VMDK, VHDX, LVM, iSCSI LUN, SQL Server, Oracle, PostgreSQL e outros formatos. Por isso, fazer o virtual disk reaparecer na controladora não significa que a recuperação terminou.
Guia completo de recuperação de RAID corrompido
Principais sintomas de um RAID corrompido ou inacessível
RAID Degraded
Um membro foi marcado como failed, missing ou foreign. O array pode continuar acessível, mas perdeu parte da redundância.
Virtual Disk Offline
O conjunto ultrapassou a tolerância, a controladora perdeu membros ou a topologia não é mais reconhecida.
Foreign Configuration
Uma controladora detecta configuração nos discos que não coincide com o estado atualmente carregado. Não limpe ou importe sem verificar o conjunto.
Rebuild travado
Reconstrução para, fica extremamente lenta ou registra read errors. Outro membro pode estar degradado.
Volume RAW ou sem partição
O RAID pode estar montado fisicamente, mas o filesystem, LUN ou tabela de partições ficou incoerente.
Controladora ou backplane falhou
Problemas de PERC, Smart Array, MegaRAID, HBA, expander ou alimentação podem fazer vários discos sumirem ao mesmo tempo.
Múltiplos discos falharam
RAID 5 com dois membros indisponíveis ou RAID 6 com três já ultrapassam sua redundância prevista.
Initialize, delete ou format
Virtual disk removido, array recriado ou partição formatada pode manter dados antigos em regiões ainda não sobrescritas.
Ransomware ou corrupção lógica
O array pode estar íntegro e o problema existir em filesystem, VM, banco de dados ou arquivos criptografados.
Níveis de RAID: o que cada arquitetura protege e o que muda na recuperação
Os níveis abaixo descrevem comportamento de redundância em condições normais. Recuperação de dados é diferente de tolerância operacional: um membro que a controladora classificou como failed pode ainda fornecer setores úteis, enquanto um disco online pode esconder regiões instáveis.
RAID 0 - Striping
Blocos são distribuídos entre dois ou mais membros. Capacidade e desempenho aumentam, mas não existe paridade ou mirror. Se um disco está totalmente perdido, faltam partes do fluxo lógico. Se ele ainda puder ser imageado parcialmente, a reconstrução usa o melhor conteúdo disponível de todos os membros.
RAID 1 - Espelhamento
Os membros contêm cópias correspondentes. Em um mirror simples de dois discos, uma falha pode ser tolerada. Em recovery, é importante comparar as cópias quando houve corrupção lógica, rebuild parcial ou divergência temporal.
RAID 5 - Paridade distribuída
Dados e paridade são distribuídos pelos discos. RAID 5 tolera uma falha de membro em operação normal. Com um segundo membro instável durante rebuild, setores ausentes em dois discos na mesma stripe podem impedir a reconstrução daquela região.
RAID 6 - Dupla paridade
Usa duas informações de paridade por stripe. Em controladoras e implementações comuns, isso permite continuar operando com até dois membros falhos. A reconstrução com mais falhas depende do que cada mídia ainda consegue fornecer, e não de um percentual fixo.
RAID 10 - Stripe de mirrors
Combina pares espelhados com striping entre os mirrors. Pode tolerar múltiplas falhas se não eliminarem todas as cópias de um mesmo mirror. A recuperação precisa identificar os pares corretos e o estado temporal de cada cópia.
RAID 50 e RAID 60
RAID 50 faz striping sobre grupos RAID 5; RAID 60 faz striping sobre grupos RAID 6. O primeiro desafio é identificar a composição de cada grupo. Depois é necessário reconstruir a camada superior de striping. A tolerância depende de onde as falhas ocorreram.
ZFS usa VDEVs e paridade própria. RAIDZ1, 2 e 3 toleram uma, duas ou três falhas por VDEV em condições normais.
Não é um nível RAID com paridade. Dependendo da implementação, discos podem ser concatenados. Falha de um membro pode afetar faixas específicas do volume.
Microsoft oferece Simple, Mirror e Parity, inclusive dual parity em cenários suportados. A reconstrução usa metadata e abstrações próprias do Windows.
Quando o rebuild é procedimento correto e quando pode aumentar o risco
Fabricantes como Dell e HPE documentam rebuild como parte normal da manutenção de arrays degradados. O erro está em transformar uma regra de manutenção em regra universal de recuperação. Antes de rebuild, três perguntas são essenciais: existe backup validado, os membros restantes estão realmente saudáveis e o array ainda está dentro da tolerância?
| Cenário | Conduta mais coerente | Motivo |
|---|---|---|
| RAID 5 com 1 disco falho, demais membros saudáveis, backup validado | Seguir procedimento do fabricante para substituição e rebuild | É o cenário operacional previsto pelo RAID 5 |
| RAID 6 com 1 ou 2 falhas, membros restantes estáveis e backup | Rebuild controlado conforme plataforma | O array ainda está dentro da tolerância prevista |
| RAID 5 com 1 disco falho e outro com erros de leitura | Considerar aquisição antes do rebuild | O rebuild precisa ler extensivamente os membros restantes |
| RAID 5 com 2 membros indisponíveis | Não criar rebuild cego | A redundância normal já foi ultrapassada |
| Rebuild anterior travou | Preservar estado e diagnosticar membros | Repetir a mesma carga sem entender a falha pode agravar |
| Virtual Disk apagado ou config perdida | Não inicializar novo volume | Um novo array pode escrever metadata sobre o estado anterior |
O Kernel Linux também documenta que um RAID 5 ou RAID 6 simultaneamente dirty e degraded pode apresentar risco de corrupção porque a paridade pode não ser confiável enquanto existem blocos ausentes. Isso mostra por que estado transacional e histórico importam, não apenas quantos discos ainda aparecem online.
Foreign não significa automaticamente metadados perdidos
Dell PERC e Broadcom MegaRAID possuem mecanismos oficiais para detectar e importar Foreign Configuration. A documentação Dell orienta verificar o estado dos physical disks e fazer preview da configuração antes de importar. Isso contradiz a simplificação de que qualquer estado Foreign significa que a controladora perdeu o mapa original.
Preview antes de import
Em plataformas suportadas, visualize quais physical disks e virtual disks fariam parte da configuração importada antes de confirmar.
Clear Foreign exige certeza
Limpar Foreign Configuration pode ser correto para um disco substituto que trouxe metadata antiga, mas pode ser errado se aqueles metadados representam o array que você precisa recuperar.
Slot e identidade importam
Registre Device ID, Backplane ID, Slot, serial, tamanho e status antes de aceitar qualquer alteração.
DDF e metadata on-disk
Broadcom documenta controladoras MegaRAID com DDF-compliant configuration on disk e suporte a Foreign Configuration Import. Outras plataformas usam formatos próprios.
12 passos quando um RAID fica inacessível
O que não fazer em um RAID corrompido
Initialize ou Fast Initialize
Essas funções pertencem à criação e manutenção de arrays. Não use quando o objetivo é recuperar o estado anterior.
Trocar discos de posição
Misturar bays adiciona uma variável desnecessária e pode confundir spans, mirrors e grupos internos.
Rebuild no membro errado
Se o disco escolhido como fonte ou destino está incorreto, o rebuild pode propagar um estado ruim.
Clear Foreign sem preview
Uma metadata marcada Foreign pode ser irrelevante ou pode representar justamente o array que precisa ser preservado.
CHKDSK, fsck ou repair no original
Reparo busca consistência do estado atual e altera metadata. Em recuperação, primeiro faça aquisição.
Atualizar firmware para tentar recuperar
Firmware update é manutenção. Em storage instável, preserve o estado antes de introduzir nova mudança.
Como funciona a recuperação profissional de RAID
O processo é adaptado ao hardware e ao tipo de falha. A sequência abaixo é uma arquitetura de trabalho segura, não um tutorial para reconstruir arrays críticos em produção.
Onde entram PC-3000, DeepSpar, MRT e Data Extractor?
Essas tecnologias podem atuar em diagnóstico, firmware, controle de leitura, aquisição e análise lógica conforme a mídia e a família suportada. Nenhuma ferramenta substitui a identificação correta da topologia RAID e do estado dos membros.
Dell PERC, HPE Smart Array, Broadcom MegaRAID, Adaptec e Intel VROC
Dell PERC
Famílias PERC suportam diferentes níveis conforme a geração. Documentação Dell atual lista controladoras com RAID 0, 1, 5, 6, 10, 50 e 60 e possui procedimento oficial para preview/import de Foreign Configuration.
HPE Smart Array
HPE documenta RAID 5, RAID 6, RAID 10 e processos de Automatic Data Recovery ou rebuild. Tempo e comportamento dependem de tamanho, carga e controladora.
Broadcom MegaRAID
MegaRAID usa ferramentas como StorCLI e pode manter DDF-compliant configuration on disk, além de suportar Foreign Configuration Import em modelos compatíveis.
Microchip Adaptec SmartRAID
Controladoras SmartRAID usam ARCCONF/maxView e mantêm estados, eventos e metadata próprios. O suporte varia conforme geração e firmware.
Intel VROC
Intel VROC oferece RAID integrado para SSDs NVMe conectados à CPU, com RAID 0/1/10 e RAID 5 em licenças e plataformas compatíveis.
SAS, SATA e NVMe
A interface física não define o nível RAID. Servidores podem combinar SAS/SATA em controladoras dedicadas ou NVMe via VROC, PERC e outras arquiteturas modernas.
Substituir uma controladora por outra idêntica pode resolver falha de hardware em alguns cenários, mas não deve ser tratado como passo automático de recuperação. Firmware, cache, encryption, foreign config e estado dos discos precisam ser compatíveis.
Linux mdadm, Windows Storage Spaces e ZFS RAIDZ
Linux md
O kernel Linux documenta RAID 1, 4, 5, 6, 10 e metadata de arrays MD. Estados dirty/degraded e mecanismos contra write hole mostram que consistência transacional também influencia recovery.
Storage Spaces
Microsoft oferece layouts Simple, Mirror e Parity. Paridade pode ser single ou dual em cenários suportados e os metadados pertencem à abstração de Storage Spaces.
ZFS / RAIDZ
TrueNAS usa VDEVs, mirrors, RAIDZ1, RAIDZ2 e RAIDZ3. A redundância está dentro de cada VDEV. Labels, datasets, zvols e snapshots adicionam estruturas próprias.
VMware, Hyper-V, Proxmox, bancos de dados e volumes corporativos
Em servidores corporativos, reconstruir o array físico pode ser apenas o início. A Broadcom documenta cenários em que uma LUN removida no nível da controladora deixa VMs VMware inacessíveis porque o VMFS dependia daquele virtual disk. Isso ilustra a cadeia entre hardware e aplicação.
VMware ESXi
RAID ou SAN pode apresentar uma LUN com VMFS. Depois vêm diretórios das VMs, VMX, VMDK, snapshots e filesystems convidados.
Hyper-V
Windows pode usar NTFS/ReFS, CSV ou Storage Spaces antes de VHDX e checkpoints. O volume precisa ser reconstruído na ordem correta.
Proxmox
LVM-thin, ZFS, Ceph, QCOW2 e raw podem existir sobre RAID local ou storage externo. A arquitetura precisa ser inventariada.
SQL Server
MDF, NDF e LDF precisam ser validados como banco, não apenas copiados. Corrupção pode existir dentro da VM mesmo com RAID reconstruído.
Oracle
Datafiles, control files, redo logs, ASM ou filesystem podem criar várias camadas de dependência.
PostgreSQL / MySQL
Data directories, WAL/binlogs, tabelas e índices precisam de consistência lógica após a extração.
RAID 5 na prática: servidor, máquinas virtuais e banco de dados
O vídeo abaixo complementa este guia mostrando a abordagem técnica da SECURITY em um cenário de servidor RAID 5 e as camadas que podem existir acima do array físico.
Vídeo do canal SECURITY Recuperação de Dados. Abrir no YouTube
Cenários técnicos de recuperação de RAID
RAID 5 Degraded com segundo HDD instável durante rebuild
Contexto: uma controladora marca um disco como failed e o administrador inicia rebuild com um novo membro. Durante a reconstrução, outro HDD começa a registrar read errors.
Ação de risco: repetir o rebuild, trocar o segundo disco ou forçar online sem preservar o primeiro estado.
Estratégia: parar novas escritas, mapear bays, adquirir os membros instáveis e reconstruir virtualmente as stripes usando os melhores blocos disponíveis.
Aprendizado: o rebuild não era errado no início; o cenário mudou quando apareceu a segunda falha.
Dell PERC mostra Foreign Configuration após intervenção no servidor
Contexto: discos são removidos e recolocados após manutenção de backplane. A PERC detecta foreign metadata.
Ação de risco: Clear Foreign ou Import sem preview e sem conferir quais physical disks pertencem ao virtual disk original.
Estratégia: registrar slots e serials, revisar o preview da configuração, determinar se a topologia encontrada é coerente e, em dados únicos, adquirir antes de modificar.
RAID 10 com duas falhas no mesmo mirror
Contexto: um array de quatro discos perde dois membros. Embora RAID 10 possa tolerar múltiplas falhas em posições favoráveis, as duas ocorreram no mesmo par espelhado.
Ação de risco: assumir que qualquer combinação de dois discos é tolerada.
Estratégia: identificar os pares, tentar obter imagens parciais dos membros falhos e reconstruir a stripe apenas onde pelo menos uma cópia do mirror existe.
VMware VMFS sobre RAID com virtual disk removido
Contexto: o RAID é alterado na controladora e a LUN que sustentava um datastore VMFS deixa de existir.
Ação de risco: criar um novo datastore com o mesmo nome ou formatar o volume apresentado novamente.
Estratégia: reconstruir primeiro o virtual disk RAID com geometria e offset corretos, depois localizar VMFS e somente então validar VMDKs e máquinas virtuais.
Perguntas frequentes sobre recuperação de RAID
RAID Degraded ainda pode ser usado normalmente?
Degraded significa que o array perdeu parte da redundância ou possui membro ausente ou com falha. Se os dados ainda estão acessíveis, a prioridade é validar uma cópia independente. O rebuild pode ser procedimento correto quando o array está dentro da tolerância, os demais membros estão saudáveis e existe backup validado.
RAID 5 com dois discos falhos tem recuperação?
RAID 5 tolera uma falha de membro em operação normal. Com dois membros indisponíveis, a paridade isoladamente já não reconstrói todas as stripes. Ainda pode existir viabilidade de recuperação dependendo de quais discos realmente falharam, qualidade das imagens, setores legíveis e distribuição dos arquivos. Não existe percentual universal de recuperação.
RAID 6 com três discos falhos está perdido?
RAID 6 normalmente tolera duas falhas de membro. Com três discos indisponíveis, o conjunto ultrapassa a redundância prevista, mas a viabilidade deve ser avaliada setor a setor. Se um dos membros classificados como falhos ainda puder ser parcialmente adquirido, algumas regiões podem ser reconstruídas.
Devo iniciar rebuild imediatamente quando um disco falha?
Não existe uma resposta única. Em array saudável, com uma única falha dentro da tolerância e backup validado, o rebuild é manutenção normal prevista pelos fabricantes. Em dados sem backup, rebuild anterior travado ou outros discos com erros, pode ser mais seguro preservar e clonar antes de iniciar uma leitura integral.
Foreign Configuration significa que a configuração foi perdida?
Não necessariamente. Controladoras Dell PERC, Broadcom MegaRAID e outras plataformas possuem mecanismos oficiais para detectar, visualizar e importar configurações foreign. Em perda de dados, não limpe nem importe automaticamente. Primeiro confirme quais discos pertencem ao array, o estado do virtual disk e a coerência da configuração.
A controladora RAID queimada precisa ser reparada para recuperar os dados?
Nem sempre. Muitas controladoras mantêm informações de configuração nos próprios discos ou em formatos de metadata que podem ajudar na reconstrução. Dependendo da plataforma, o array pode ser reconstruído virtualmente a partir das imagens dos membros sem depender da controladora original.
Qual a diferença entre RAID hardware e software na recuperação?
RAID hardware usa controladora dedicada e metadados específicos da plataforma. RAID software usa componentes do sistema operacional, como Linux md, Windows Storage Spaces ou ZFS. Ambos podem ser recuperáveis, mas parâmetros, metadata, paridade e filesystem precisam ser interpretados de acordo com a implementação real.
RAID 0 com um disco perdido pode ser recuperado?
RAID 0 não possui redundância. Se um membro está totalmente ausente, os blocos que estavam nele não podem ser recriados por paridade. Ainda pode haver análise parcial ou identificação de estruturas em determinados cenários, mas arquivos distribuídos pelos membros tendem a ficar incompletos. Se o disco falho puder ser estabilizado e imageado, a situação muda.
RAID 10 pode perder quantos discos?
Depende de quais membros falham. RAID 10 combina mirrors com striping. Em uma topologia típica, pode tolerar uma falha em cada par espelhado, mas perder todos os membros do mesmo mirror pode tornar parte do conjunto indisponível. A topologia precisa ser identificada.
RAID 50 e RAID 60 são iguais a RAID 5 e RAID 6?
Não. RAID 50 combina striping sobre grupos RAID 5. RAID 60 faz o mesmo sobre grupos RAID 6. A tolerância depende de como as falhas se distribuem entre os grupos. A recuperação precisa reconstruir os grupos internos e depois a camada de striping superior.
RAIDZ do TrueNAS é a mesma coisa que RAID 5?
Não. RAIDZ pertence ao ZFS e possui organização própria. RAIDZ1, RAIDZ2 e RAIDZ3 usam uma, duas e três paridades por VDEV, respectivamente, mas não devem ser reconstruídos como se fossem um RAID 5 ou RAID 6 de controladora convencional.
É seguro trocar a controladora e importar a configuração?
Pode ser procedimento oficial em plataformas compatíveis, mas deve ser feito apenas quando a topologia e o estado dos discos são conhecidos. Em cenário de perda de dados, uma importação errada, clear foreign, initialization ou criação de novo virtual disk pode alterar o estado e dificultar a reconstrução.
VMware ou Hyper-V dentro do RAID muda a recuperação?
Sim. Depois de reconstruir o array ainda pode existir VMFS, ReFS, NTFS, Storage Spaces, VMDK, VHDX, LVM ou outro contêiner. A recuperação deve atravessar essas camadas até validar as máquinas virtuais e aplicações que o cliente realmente precisa.
É possível recuperar banco SQL Server, Oracle ou PostgreSQL de um RAID?
Pode ser possível quando o storage físico e as camadas lógicas podem ser reconstruídos. Recuperar MDF, LDF, datafiles, WAL ou outros arquivos não garante consistência da base. Bancos de dados devem ser validados estruturalmente depois da extração.
A SECURITY atende recuperação de RAID em todo o Brasil?
Sim. A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio seguro dos discos, storage ou componentes conforme o caso. Em Barueri, este artigo prioriza Alphaville, além de pontos de atendimento em São Paulo e Campinas.
Atendimento para recuperação de RAID em São Paulo e todo o Brasil
A SECURITY atende clientes de diferentes regiões do Brasil e orienta o envio seguro dos discos, storage ou componentes conforme o cenário. 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, NAS, servidores, Linux, banco de dados, HD, SSD, PC-3000, Data Extractor e análise RAID Low Level.
RAID por dentro: stripe size, disk order, paridade, metadata, filesystems e recuperação Low Level
Esta seção aprofunda os elementos que determinam se um array pode ser reconstruído quando a controladora não oferece mais acesso normal.
1. Disk order não é apenas a ordem física dos cabos
A sequência lógica dos membros define quais chunks aparecem em cada posição da stripe. Metadados podem registrar essa associação, mas após troca de discos, spans ou intervenções, a ordem física observada pode não representar o estado original. Fotografar bays e seriais evita uma camada de incerteza.
2. Stripe size e chunk size
Controladoras dividem o espaço lógico em unidades distribuídas entre membros. O tamanho pode variar conforme plataforma e configuração. Um stripe size incorreto produz fragmentação periódica, quebra de boot sectors, diretórios e arquivos grandes. Em análise Low Level, padrões repetidos ajudam a validar o parâmetro.
3. Offset e início efetivo dos dados
Metadata da controladora, alignment e reserved areas podem fazer o primeiro bloco lógico do volume começar depois do início físico do disco. Mesmo com disk order e stripe corretos, um offset errado desloca toda a reconstrução.
4. Paridade do RAID 5
RAID 5 distribui paridade entre os membros. A paridade permite reconstruir o dado de uma unidade ausente por stripe quando os demais blocos necessários estão íntegros. Em recovery, a paridade também pode ajudar a decidir qual versão de um setor é coerente quando um disco retorna leitura instável.
5. Dupla paridade do RAID 6
RAID 6 mantém duas relações de redundância e tolera duas falhas de membro em operação normal. A implementação matemática pode variar conforme a controladora. O conceito importante para recuperação é que dois membros ausentes ainda podem ser reconstruídos se todos os blocos restantes da stripe estiverem disponíveis e coerentes.
6. RAID 10 e pares espelhados
O mapa de mirrors é tão importante quanto a ordem global. Identificar qual membro é cópia de qual permite escolher o melhor exemplar e entender combinações de falhas. Após rebuild parcial, os dois lados de um mirror podem não representar exatamente o mesmo ponto temporal.
7. RAID 50 e RAID 60 possuem duas camadas
Primeiro existem grupos RAID 5 ou RAID 6. Depois existe striping entre esses grupos. Uma falha que seria tolerável se distribuída entre grupos pode ser fatal se concentrada dentro do mesmo grupo. A reconstrução precisa respeitar essa hierarquia.
8. DDF e metadados proprietários
Algumas controladoras usam formatos compatíveis com Disk Data Format; outras usam metadata própria. Broadcom documenta DDF-compliant configuration on disk em MegaRAID. Dell PERC e outras famílias também mantêm informações nos membros que podem permitir preview ou import de uma foreign configuration.
9. Foreign Configuration é estado, não diagnóstico
Foreign pode aparecer após mover discos, trocar controladora ou inserir uma unidade com configuração anterior. A decisão entre importar, limpar ou preservar depende do contexto. Para recuperação, nunca transforme a existência de foreign metadata em uma resposta automática.
10. Write hole e arrays dirty/degraded
O kernel Linux documenta o risco do RAID 5 write hole quando uma interrupção deixa dados e paridade fora de sincronismo. Se o array também está degradado, pode não haver informação suficiente para reconstruir de forma confiável blocos que dependem de paridade desatualizada. Journaling e PPL existem justamente para mitigar esse tipo de cenário.
11. Filesystem pode estar corrompido mesmo com RAID perfeito
NTFS, ReFS, EXT4, XFS, Btrfs, ZFS e VMFS possuem metadados próprios. Um rebuild que devolve o virtual disk à controladora não corrige automaticamente journal, MFT, superblocks, trees ou outros objetos lógicos.
12. VMFS e discos virtuais
Em VMware, a camada RAID pode apresentar uma LUN que contém VMFS. Dentro dele existem VMDKs e arquivos de configuração. Um VMDK pode conter NTFS, EXT4 ou banco de dados. Recuperação precisa seguir essa pilha de baixo para cima.
13. ReFS e Storage Spaces
Storage Spaces pode apresentar virtual disks com mirror ou parity e ReFS pode existir acima. A metadata do pool, virtual disk e filesystem deve ser mantida separada no diagnóstico. Recriar um pool não equivale a reconstruir o anterior.
14. ZFS RAIDZ é outro modelo
ZFS combina volume manager e filesystem, usa VDEVs, labels, checksums, copy-on-write e snapshots. RAIDZ1, RAIDZ2 e RAIDZ3 não devem ser tratados como simples variantes de PERC RAID 5 e RAID 6.
15. Clonagem com setores faltantes
Uma imagem de disco degradado pode conter gaps. Quando a redundância do array fornece os blocos equivalentes, algumas lacunas podem ser recalculadas. Se dois ou mais membros têm lacunas na mesma stripe além da tolerância, aquela região pode permanecer incompleta.
16. Priorizar arquivos críticos
Nem todo projeto exige ler o array inteiro antes de entregar valor. Depois de reconstruir metadata e localizar o filesystem, arquivos ou VMs prioritários podem ser extraídos primeiro, desde que a estratégia não exponha as mídias originais a novas leituras desnecessárias.
17. Banco de dados exige validação própria
Arquivos recuperados podem abrir parcialmente e ainda conter páginas, redo logs ou índices incoerentes. SQL Server, Oracle, PostgreSQL, MySQL e outros DBMS devem ser analisados como estruturas, principalmente após perda de setores ou desligamento abrupto.
18. Matriz de decisão
| Sintoma | Camada principal | Prioridade | Evitar |
|---|---|---|---|
| RAID Degraded, volume acessível | Membro físico / redundância | Backup validado e health dos demais | Rebuild sem conhecer o segundo disco |
| RAID Offline com múltiplas falhas | Discos + geometria do array | Mapear e adquirir membros | Initialize ou novo virtual disk |
| Foreign Configuration | Metadata da controladora | Preview e inventário | Clear/import automático |
| Rebuild travado | Segundo membro instável | Clonar e preservar estado | Repetir rebuild |
| Volume RAW | RAID + filesystem | Confirmar geometria e analisar FS | Formatar |
| Controladora queimada | Hardware + metadata on-disk | Preservar discos e configuração | Criar array novo em controladora substituta |
| VMware datastore perdido | RAID + LUN + VMFS | Reconstruir camada por camada | Criar novo datastore |
| Ransomware | Dados / filesystem / snapshots | Isolar e preservar | Apagar evidências |
19. Conclusão técnica
O melhor procedimento de recuperação de RAID não é uma regra absoluta como "nunca rebuild" ou "sempre importe foreign". É uma decisão baseada no estado real dos membros, redundância, metadata e objetivo dos dados. Quanto mais cedo o cenário é documentado e preservado, mais opções técnicas permanecem disponíveis.
Referências técnicas utilizadas neste guia
Os sites E-Recovery e Crowdertech foram usados como benchmark de arquitetura, intenção de busca e frontend. As explicações técnicas da SECURITY foram redigidas de forma original e confrontadas com documentação oficial de fabricantes e projetos.
- Dell: níveis RAID e paridade
- Dell: preview e import de Foreign Configuration
- Dell: famílias PERC e níveis suportados
- HPE Smart Array: RAID 5
- HPE Smart Array: RAID 6
- Broadcom: StorCLI Reference Manual
- Broadcom MegaRAID: DDF e Foreign Configuration
- Microchip Adaptec SmartRAID: ARCCONF
- Intel VROC: RAID para NVMe
- Linux Kernel: MD RAID arrays
- Linux Kernel: RAID5 Partial Parity Log e write hole
- Microsoft: Storage Spaces overview
- TrueNAS: ZFS Primer e RAIDZ
- Broadcom VMware: VMFS inacessível após remoção de LUN/Virtual Disk
