Storages corporativos combinam discos, controladoras, RAID ou Distributed RAID, pools, volumes, LUNs, snapshots, tiering e virtualização. Quando o acesso cai, o problema pode estar em uma única mídia ou em várias camadas de metadata. A recuperação segura identifica a arquitetura antes de Initialize, Re-create Pool, Delete Volume, Clear Configuration ou novo filesystem.
O que é um storage corporativo?
Um storage não é simplesmente "um servidor com muitos discos", mas também não é correto dizer que ele não possui CPU, firmware ou sistema operacional interno. Appliances de storage executam software próprio para administrar controladoras, pools, protocolos e proteção de dados. A diferença principal é a função: entregar armazenamento confiável aos hosts.
Guia completo de recuperação de dados em storage corporativo
Disco, RAID, pool, LUN, filesystem e aplicação: storage é uma pilha de camadas
A recuperação de storage normalmente é mais complexa que a de um disco isolado porque uma LUN pode depender de disk groups, pools, virtual pages, snapshots, mappings e depois de um filesystem pertencente ao host.
Storage recovery é uma reconstrução por camadas. A ordem correta evita interpretar um problema de pool como simples falha de disco.
Dell PowerVault ME5 e HPE MSA, por exemplo, documentam disk groups adicionados a pools e volumes criados sobre esses pools. NetApp organiza RAID groups em aggregates/local tiers. IBM FlashSystem usa distributed arrays, pools e virtual volumes. Hitachi VSP trabalha com parity groups, LDEVs e pools. A terminologia muda, mas o princípio é o mesmo: o host enxerga uma abstração construída sobre várias camadas internas.
SAN, NAS e DAS: o local do filesystem muda o caminho da recuperação
Storage SAN
Apresenta blocos a hosts por Fibre Channel, iSCSI ou NVMe-oF em plataformas compatíveis. O host cria VMFS, ReFS, NTFS, LVM ou outro filesystem sobre a LUN.
Storage NAS
Apresenta arquivos por SMB/NFS e mantém o filesystem no próprio appliance. A recuperação inclui RAID/pool e a camada de arquivos interna.
Storage DAS
Conecta diretamente ao host por SAS/FC ou interfaces específicas. O enclosure pode apresentar volumes de bloco ao servidor sem uma SAN Ethernet/FC dedicada.
| Arquitetura | O host recebe | Camadas comuns | Exemplo de recuperação |
|---|---|---|---|
| SAN | LUN / bloco | Pool → Volume/LUN → Host FS | Reconstruir pool e LUN, depois VMFS/VMDK |
| NAS | Arquivos | RAID/Pool → Filesystem interno → SMB/NFS | Reconstruir pool/volume e filesystem do appliance |
| DAS | Bloco diretamente ao servidor | Disk group/RAID → Volume → Host FS | Reconstruir array e filesystem do host |
Quando o storage sai de manutenção normal e entra em cenário de recuperação
LUN inacessível
O host perde o volume, multipath fica sem caminho ou VMFS/CSV não monta.
Pool Degraded / Offline
Falhas de disk group, distributed RAID ou metadata retiram capacidade do pool.
Controller A/B em falha
Failover pode não restaurar acesso se a falha está na camada comum do array.
Rebuild travado
Media errors ou outra falha podem impedir a reconstrução de um disk group.
Volume RAW / corrupt
A LUN pode estar online, mas o host não reconhece o filesystem esperado.
VMs Orphaned / Inaccessible
O storage pode apresentar a LUN, mas VMFS, VMDK ou a tabela de partição foi alterada.
Dell PowerVault ME5: disk groups, pools, volumes e ADAPT
A documentação Dell ME5 é especialmente útil para entender a diferença entre RAID e virtualização. Um disk group agrega discos de um mesmo tipo sob um nível de proteção. Um pool agrega um ou mais disk groups e funciona como contêiner para volumes.
Virtual storage
Dell mapeia páginas lógicas dos volumes em storage físico do pool. Páginas adjacentes de uma LUN não precisam ser fisicamente adjacentes nos discos.
Linear storage
Em modo linear, o disk group e o pool ficam muito mais próximos conceitualmente, com menor camada de virtualização.
RAID 5 / 6 / 10
Disk groups tradicionais usam níveis RAID específicos e limites próprios.
ADAPT
Dell ME5 documenta ADAPT em grupos virtuais de 12 a 128 drives, com expansão do grupo e comportamento distribuído.
Por isso, dizer que "a controladora conhece tudo e sem ela os parâmetros desaparecem" é absoluto demais. O storage possui metadata distribuída, pools e disk groups que precisam ser interpretados em conjunto. Controladora e cache ainda podem ser muito importantes em casos específicos.
HPE MSA: disk groups, pools, volumes e MSA-DP+
HPE MSA 1060/2060/2062 documenta disk groups como conjuntos de discos sob um nível de RAID, adicionados a pools que servem de contêiner para volumes. O virtual storage habilita tiering, snapshots, replication, quick rebuild e overcommit.
Disk group
RAID e membros físicos formam a base. O menor disco pode limitar capacidade em grupos tradicionais.
Pool
Um ou mais disk groups contribuem capacidade para volumes virtuais.
MSA-DP+
Proteção distribuída documentada em gerações MSA atuais, distinta de RAID 5/6 tradicional.
Controller A/B
Alta disponibilidade de controladora não substitui integridade do disk group/pool compartilhado.
NetApp ONTAP: aggregates/local tiers, plexes, RAID groups, volumes e WAFL
NetApp ONTAP usa uma arquitetura própria. Documentação REST mostra que um aggregate/local tier contém RAID groups e pode conter plexes. Os volumes e sua metadata ocupam espaço dentro do aggregate. WAFL administra metadata e estrutura de volumes.
RAID-DP
NetApp documenta dupla paridade e proteção contra até duas falhas de disco simultâneas dentro das condições suportadas.
RAID-TEC
Tripla paridade suportada em plataformas e tipos de disco compatíveis, com proteção para até três falhas simultâneas.
Plex / RAID group
ONTAP expõe estado, reconstruction e discos por RAID group dentro de plexes.
WAFL metadata
Volumes e metadata têm organização própria, além de snapshots e recursos de eficiência.
É seguro dizer que recuperação NetApp exige compreender WAFL e o layout ONTAP. Já afirmar que RAID-DP usa necessariamente uma "rotação proprietária incompatível com Reed-Solomon" sem documentação específica é desnecessário. A fonte oficial sustenta a dupla paridade, a topologia de RAID groups e o papel dos aggregates.
IBM FlashSystem e Storage Virtualize: Distributed RAID, rebuild areas e pools
IBM FlashSystem usa Storage Virtualize e documenta Distributed RAID. Em DRAID, dados, paridade e áreas de rebuild são distribuídos pelo conjunto, reduzindo a dependência de um hot spare físico tradicional em muitos cenários.
DRAID1
Mirrored strips distribuídos. IBM documenta rebuild areas e rebuild-in-place conforme estado do array.
DRAID5
Uma parity strip por stripe. Suporta uma falha de membro dentro das condições suportadas.
DRAID6
Duas parity strips por stripe e tolerância normal a duas falhas simultâneas de membros.
Storage pools
Arrays internos e MDisks externos podem alimentar pools e volumes virtuais em Storage Virtualize.
IBM publica em 2026 limites de FlashSystem/SVC com até 128 member drives em diversos distributed arrays. Esse cenário é mais complexo que um RAID estático pequeno porque os volumes virtuais dependem também do mapping do storage pool.
ThinkSystem DE Series: pools, volume groups e shelf/drawer loss protection
Lenovo DE Series diferencia pools e volume groups. A documentação System Manager mostra pools com proteção distribuída configurada como RAID 6 pelo sistema e volume groups com RAID 0, 1, 10, 5 e 6.
Pool
Conjunto de drives usado para criar volumes e suportar thin volumes em versões compatíveis.
Volume group
Conjunto de drives sob um RAID selecionado pelo administrador.
Shelf loss protection
Lenovo documenta critérios de distribuição de drives entre shelves para evitar que a perda de uma gaveta derrube o conjunto.
Drawer loss protection
Arrays de alta densidade podem distribuir membros entre drawers para tolerância a falha de uma unidade física compartilhada.
DM Series, por outro lado, é baseada em ONTAP e deve ser analisada segundo arquitetura NetApp. Isso evita misturar DE, DM e IBM Storwize de origem histórica.
Hitachi VSP: parity groups, LDEVs, pools e volumes virtuais
Hitachi VSP documenta uma cadeia própria: drives formam parity groups, LDEVs podem ser criados sobre esses grupos e pool volumes alimentam pools de Dynamic Provisioning. APIs atuais expõem RAID level, parity group IDs, pool IDs e estado de LDEVs.
Parity Group
Grupo físico protegido por uma configuração RAID específica.
LDEV
Logical Device criado sobre parity group ou pool, dependendo da arquitetura.
DP Pool
Pool de Dynamic Provisioning construído a partir de pool-VOLs e metadata de gerenciamento.
V-VOL / LUN
Volume virtual apresentado aos hosts por portas e host groups.
Fujitsu ETERNUS, Huawei OceanStor e Oracle ZFS Storage possuem outras abstrações. Em um artigo genérico, o ponto principal é não transportar automaticamente parâmetros de Dell, HPE ou NetApp para uma arquitetura diferente.
RAID clássico e distributed RAID não são a mesma camada
Mirror
RAID 1/10, cópias sem P/Q
Single parity
RAID 5 / DRAID5 conforme plataforma
Double parity
RAID 6 / RAID-DP / DRAID6
Distributed
ADAPT, MSA-DP+, pools e rebuild areas
RAID 1 / 10
Proteção por espelhamento. Rebuild usa cópia sobrevivente do mirror.
RAID 5 / 6
Paridade simples ou dupla em disk groups tradicionais.
Distributed RAID
DRAID, ADAPT, MSA-DP+ e pools distribuem dados/paridade/rebuild de forma específica por fabricante.
NetApp RAID-DP / TEC
Políticas ONTAP de dupla e tripla paridade integradas à organização de local tiers e RAID groups.
Para SEO e IA, a distinção é importante: nem todo storage com "RAID 6" deve ser desmontado como um conjunto clássico de N discos com stripe fixo. A virtualização interna pode adicionar pages, extents, pool metadata e mappings.
Storage all-flash: NVMe, SSD enterprise, FTL e firmware
Em arrays all-flash, o problema pode estar no pool e também dentro de cada SSD. NVMe e SAS/SATA SSD usam controladores, firmware, FTL e NAND. Endurance, power loss, media errors, namespaces e firmware precisam ser analisados sem aplicar automaticamente técnicas de HDD.
NVMe
Namespaces, PCIe paths, firmware e controladora do SSD fazem parte do diagnóstico.
SSD SAS/SATA
A interface é familiar ao storage, mas a falha interna ainda depende de FTL e NAND.
FCM / proprietary flash
IBM FlashCore Modules e outros módulos proprietários possuem arquitetura diferente de SSD commodity.
Thin provisioning, snapshots, deduplicação e compressão mudam a relação entre bloco físico e dado lógico
Storages modernos podem armazenar mais dados lógicos do que capacidade efetivamente escrita, compartilhar blocos entre snapshots ou reduzir dados por compressão/deduplicação. A consequência para recuperação é simples: reconstruir o RAID pode não ser suficiente para localizar cada arquivo de forma linear.
Thin provisioning
Volumes podem ter capacidade lógica maior que o espaço físico já alocado. Mappings do pool definem quais pages/extents existem.
Snapshots
Snapshots dependem de metadata e blocos compartilhados ou copy-on-write conforme a plataforma.
Deduplicação
Blocos podem ser referenciados por múltiplos objetos. A metadata de eficiência participa da reconstrução lógica.
Compressão
Blocos físicos precisam ser interpretados conforme o formato da plataforma para gerar os dados lógicos esperados.
Não é seguro generalizar que a recuperação sempre "reconstrói tabelas de hash" em qualquer storage. Cada fabricante implementa eficiência de modo diferente. O artigo da SECURITY usa o termo correto: recuperar a metadata de eficiência pertinente à plataforma.
LUN recuperada não significa datastore recuperado: VMFS, CSV, VMDK e VHDX vêm depois
Em SAN, o storage apresenta blocos e o host cria seu filesystem. Broadcom documenta datastores VMFS Inaccessible quando o backend LUN desaparece ou quando headers LVM/VMFS são corrompidos. Em 2026, a Broadcom também documentou um cenário em que uma LUN VMFS foi reformatada como ReFS por um host Windows, deixando as VMs Orphaned/Inaccessible.
VMware VMFS
Depois de reconstruir a LUN, é necessário validar GPT, LVM/VMFS, VMDK, descriptors e snapshots.
Hyper-V / CSV
ReFS ou NTFS podem conter VHDX e checkpoints. A VM precisa ser validada internamente.
Broadcom recomenda preservar
Quando lost data precisa ser recuperado, a documentação orienta não escrever novos dados ou criar novo filesystem na LUN.
Multipath
LUN inacessível também pode ser caminho FC/iSCSI, zoning ou MPIO e não perda física do pool.
12 passos quando um storage corporativo perde acesso aos dados
O que pode transformar indisponibilidade em perda de metadata
Re-create Pool
Cria uma nova estrutura de alocação e pode substituir referências necessárias à recuperação.
Initialize Disk Group
Inicialização é operação de provisionamento/manutenção, não de recuperação de dados.
Format LUN / New Datastore
Pode sobrescrever GPT, VMFS, ReFS ou outras estruturas existentes.
Controller swap por tentativa
Substituição pode ser suportada, mas ações automáticas ou incompatíveis precisam ser evitadas em dados únicos.
Rebuild repetido
Se os sobreviventes possuem media errors, novas passagens podem agravar a aquisição física.
Apagar logs
Event history ajuda a diferenciar drive failure, path loss, controller failover e corrupção lógica.
Como a SECURITY conduz a recuperação de dados de storage
O processo é orientado por evidência: preservar as mídias, identificar a arquitetura e reconstruir o caminho entre bloco físico e dado útil.
Caio Bruno F. Garcia, RAID Low Level e WinHex em storages de extrema complexidade
WinHex pode auxiliar na inspeção hexadecimal de clones, comparação de metadata e validação de RAID em cenários compatíveis. Em storage, o uso é contextual: depois da aquisição física, a análise pode identificar padrões de disk groups, headers, offsets, stripes e estruturas que ajudam a confirmar a reconstrução virtual.
Metadata de array
Comparar headers e áreas reservadas de membros antes/depois de operações no storage.
Disk order / stripe
Validar parâmetros de RAID tradicional em imagens quando a controladora não monta o conjunto.
Pages / extents
Localizar estruturas de pool ou volume quando há virtualização interna, sem presumir um filesystem linear.
VMFS e volumes
Inspecionar GPT, LVM headers e assinaturas após a LUN ser reconstruída.
Principais ecossistemas encontrados em projetos de storage
O diagnóstico é orientado pela arquitetura real. A marca ajuda a localizar a terminologia e a documentação correta para pools, RAID, volumes e controladoras.
Vídeos da SECURITY sobre RAID, servidor, VMs e banco de dados
O vídeo pilar complementa este artigo porque mostra a lógica por camadas que também se aplica a storage: mídia, RAID, volume, VM e aplicação.
Cenários técnicos de recuperação de storage
Dell PowerVault ME com pool virtual offline e VMware
Contexto: um disk group degrada, o rebuild encontra media errors e as LUNs VMFS deixam de montar.
Estratégia: preservar todos os membros, reconstruir disk group/pool virtual, reconstituir LUNs e depois validar VMFS/VMDK.
HPE MSA com controladora A em falha e pool inacessível
Contexto: a controladora B permanece ligada, mas o host perde as LUNs.
Estratégia: separar failover de controladora de integridade do pool, salvar logs, adquirir mídias instáveis e reconstruir volumes sem recriar disk groups.
NetApp FAS com local tier degraded e volume crítico
Contexto: RAID-DP está degradado e existem eventos adicionais de disco/WAFL.
Estratégia: preservar evidências do ONTAP, mapear RAID groups/plexes e evitar transportar procedimentos de RAID 6 genérico para WAFL/ONTAP.
IBM FlashSystem com DRAID6 e volume virtual offline
Contexto: múltiplos member drives apresentam falhas e a camada de pool deixa de apresentar o volume ao host.
Estratégia: analisar distributed RAID/rebuild areas, reconstruir pool e volume virtual e depois validar o filesystem do host.
SAN com LUN VMFS sobrescrita por ReFS
Contexto: uma LUN VMware é apresentada por engano a Windows e recebe nova GPT/ReFS.
Estratégia: interromper novas escritas, preservar imagem da LUN e analisar estruturas VMFS residuais sem criar novo datastore.
FAQ sobre recuperação de dados em storage corporativo
O que é um storage corporativo?
Storage corporativo é um sistema dedicado a fornecer capacidade de armazenamento a servidores e aplicações por blocos, arquivos ou, em algumas plataformas, objetos. Ele possui controladoras, firmware ou sistema operacional interno, pools, volumes/LUNs, cache e proteção de dados. Diferente de um servidor de aplicação, sua função principal é apresentar e gerenciar armazenamento.
O que é recuperação de dados em storage?
É o processo de preservar as mídias e reconstruir as camadas que ligam discos físicos a pools, LUNs, volumes, filesystems, máquinas virtuais e bancos de dados quando o storage deixa de apresentar os dados. A recuperação pode envolver RAID, distributed RAID, metadata de pool, thin provisioning, snapshots, virtualização e arquivos de aplicação.
Qual a diferença entre SAN, NAS e DAS?
SAN apresenta armazenamento em bloco por uma rede dedicada, normalmente Fibre Channel ou iSCSI. NAS fornece arquivos pela rede usando protocolos como SMB e NFS. DAS conecta storage diretamente a um servidor por SAS, Fibre Channel ou outra interface. A recuperação depende de onde ficam o filesystem e as camadas de volume.
O que é uma LUN?
LUN é uma unidade lógica apresentada pelo storage a um host. Em SAN, o servidor normalmente enxerga a LUN como um dispositivo de bloco e cria sobre ela VMFS, NTFS, ReFS, LVM ou outro filesystem. Recuperar a LUN pode ser apenas uma etapa antes de recuperar o conteúdo do host.
O que é um storage pool?
Pool é uma camada de agregação de capacidade. Em Dell PowerVault ME5 e HPE MSA, por exemplo, pools contêm disk groups e servem de contêiner para volumes. Em outras plataformas, como IBM FlashSystem, NetApp e Hitachi, a terminologia e a implementação variam.
Disk group e pool são a mesma coisa?
Nem sempre. Dell ME5 e HPE MSA documentam disk groups como conjuntos de discos em um nível de proteção RAID e pools como contêineres que podem incluir um ou mais disk groups. Em storage linear, alguns produtos aproximam os conceitos. Em virtual storage, a distinção é importante.
Storage com duas controladoras não deveria continuar funcionando se uma falhar?
Muitos arrays possuem alta disponibilidade entre controladoras e conseguem manter serviço em várias falhas. Porém, se o problema está em pool, metadata, discos, cache compartilhado, quorum, LUN ou caminho comum, a segunda controladora não corrige automaticamente a camada lógica. O diagnóstico precisa separar falha de controladora de falha do conjunto.
Falha de controladora apaga a configuração do storage?
Não como regra universal. Storages podem manter metadata em discos, controladoras, cache ou áreas distribuídas. Plataformas com controladoras duplas podem compartilhar ou replicar estado. A falha do controller pode retirar acesso sem apagar os blocos. A recuperação deve preservar discos e, quando relevante, controladoras e cache.
Posso trocar a controladora por outra igual?
Em manutenção suportada, substituição de controladora pode ser procedimento correto. Em perda de dados, não deve ser feita por tentativa. O risco está em ações posteriores como inicialização, import, clear, pool recreation ou firmware incompatível. Preserve o estado e valide o procedimento da plataforma.
Reiniciar o storage várias vezes destrói os dados?
Não existe uma regra universal. Alguns storages executam recovery, replay de journal, ownership failover, background verify ou outras tarefas após boot; outros apenas retomam o estado. Reboots repetidos podem alterar evidências ou aumentar a atividade em mídias instáveis, mas não devem ser descritos como inevitavelmente destrutivos.
Rebuild é sempre perigoso em storage?
Não. Rebuild, reconstruction e rebuild-in-place são funções normais de arrays redundantes. O risco aumenta quando o array já perdeu mais redundância, outros membros possuem media errors, a topologia está incerta ou um rebuild anterior falhou. Em dados únicos, aquisição prévia pode ser mais segura.
O que é RAID distribuído?
Distributed RAID distribui dados, paridade e áreas de rebuild por um conjunto maior de drives. IBM FlashSystem documenta DRAID1, DRAID5 e DRAID6. Dell PowerVault ME5 possui ADAPT e HPE MSA 1060/2060 possui MSA-DP+. Lenovo DE utiliza pools com proteção distribuída. Essas tecnologias não devem ser tratadas como RAID 5/6 clássico sem considerar a implementação.
O que é RAID-DP da NetApp?
RAID-DP é a política de dupla paridade do ONTAP. A NetApp documenta proteção contra até duas falhas simultâneas de disco no RAID-DP. ONTAP também suporta RAID-TEC com tripla paridade em cenários compatíveis. Esses níveis fazem parte da organização de local tiers/aggregates do ONTAP.
O que é WAFL?
WAFL é a camada de filesystem e gestão de blocos do ONTAP. Volumes vivem dentro de aggregates/local tiers e usam metadata própria. Em recuperação NetApp, a arquitetura do ONTAP, RAID groups, plexes, volumes e snapshots precisa ser entendida como conjunto.
O que é ADAPT no Dell PowerVault ME5?
ADAPT é um nível de proteção distribuída do PowerVault ME5 que pode usar de 12 a 128 drives em um disk group virtual e permite expansão do grupo. Ele é diferente dos disk groups RAID 5, RAID 6 e RAID 10 tradicionais.
O que é MSA-DP+?
MSA-DP+ é uma opção de proteção distribuída nas gerações HPE MSA compatíveis. HPE MSA 1060/2060 organiza disks em disk groups adicionados a pools e documenta MSA-DP+ como uma tecnologia diferente dos grupos RAID tradicionais.
O que é Distributed RAID no IBM FlashSystem?
IBM Storage Virtualize distribui strips de dados, paridade e rebuild areas pelos membros do array. Documentação atual de FlashSystem mostra DRAID1, DRAID5 e DRAID6, com DRAID6 capaz de tolerar duas falhas simultâneas de membros em condições normais.
O que é Dynamic Disk Pool em Lenovo DE Series?
Lenovo DE Series trabalha com pools e volume groups. A documentação de System Manager mostra pools com proteção equivalente a RAID 6 e volume groups que podem usar RAID 0, 1, 10, 5 e 6. O pool distribui dados e redundância pelo conjunto e possui regras próprias de shelf/drawer loss protection.
LUN Quarantined, Offline ou Pool Degraded significa perda total?
Não. Esses estados indicam que a plataforma retirou ou limitou acesso por condição de proteção, falha de membros, metadata ou policy. A viabilidade depende da marca, do estado dos discos e do que foi alterado depois. Não recrie pools ou inicialize discos sem compreender a plataforma.
VMware com datastore Inaccessible em storage pode ser recuperado?
Pode existir viabilidade. Primeiro é necessário verificar se o backend LUN está visível e se a camada de storage está coerente. Depois se analisa GPT/LVM/VMFS, VMDK e snapshots. Broadcom orienta não escrever novos dados ou criar novo filesystem quando a recuperação do conteúdo perdido é necessária.
Hyper-V e CSV em storage podem ser recuperados?
Pode. A sequência pode envolver pool/LUN, NTFS ou ReFS, Cluster Shared Volumes, VHDX e checkpoints. O objetivo é validar as máquinas e aplicações, não apenas fazer a LUN reaparecer.
Storage all-flash com SSD/NVMe tem recuperação?
Pode existir viabilidade. Além da camada RAID/pool, cada SSD possui firmware, FTL e NAND. Falhas de controller, media errors, power loss, namespace ou firmware precisam ser separadas de falhas do pool. Nem todo SSD enterprise é suportado pelas mesmas ferramentas de recuperação.
Deduplicação e compressão dificultam a recuperação?
Podem aumentar a complexidade porque o dado lógico pode depender de metadata de eficiência, referências compartilhadas e blocos comprimidos. O comportamento é específico da plataforma. Não se deve presumir que basta reconstruir o RAID e ler arquivos de forma linear.
Criptografia de storage muda o processo?
Sim. FDE, SED, KMIP, encryption at rest e chaves de plataforma podem ser necessários para interpretar os blocos. Se a chave ou configuração de segurança é perdida, recuperar os discos fisicamente pode não ser suficiente. Preserve credenciais, key managers e configuration backups relacionados.
Preciso enviar o storage inteiro?
Na maioria dos casos, não. Discos ou SSDs, ordem das baias, modelo do storage, controladoras, screenshots e logs podem ser suficientes para iniciar. Porém, controller cache, encryption, proprietary enclosures, dual-controller state, expanders ou backplane podem tornar o equipamento completo ou componentes adicionais importantes.
A ordem dos discos importa?
Sim, especialmente em RAID tradicional, JBOD, disk groups e reconstruções de baixo nível. Mesmo em plataformas que guardam metadata suficiente para identificar membros, preservar slot, enclosure e serial reduz ambiguidade e acelera a análise.
Quanto custa recuperar dados de storage?
O custo depende da quantidade e capacidade das mídias, tipo de proteção, pools, controladoras, falhas físicas, virtualização, deduplicação, compressão, criptografia e histórico de tentativas. Um storage de 12 discos e um array de 90 drives possuem escopos muito diferentes.
Quanto tempo leva?
O prazo depende principalmente da saúde e capacidade das mídias e da quantidade de camadas. A clonagem de muitos discos ou SSDs pode levar mais tempo que a reconstrução lógica. LUNs VMware, bancos, all-flash e storages com muitos pools adicionam etapas.
A SECURITY atende storages de todo o Brasil?
Sim. A SECURITY atende empresas de diferentes regiões do Brasil e orienta a logística conforme o cenário. Em muitos casos não é necessário enviar o equipamento completo, apenas as mídias e as informações técnicas necessárias.
Em muitos casos, não é necessário levar o storage completo
Para iniciar a análise, normalmente podem ser suficientes as mídias, a ordem das baias, modelo do storage, controladoras, screenshots, logs e configuração dos hosts. Isso reduz logística em enclosures pesados e arrays de muitas baias.
Recuperação de storage em Alphaville, São Paulo, Campinas e todo o Brasil
A SECURITY atende empresas de diferentes regiões do Brasil e orienta o envio das mídias, controladoras ou equipamento 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 e, quando o caso exige investigação abaixo do filesystem, trabalha com RAID Low Level, reconstrução virtual e análise hexadecimal com WinHex, além de tecnologias como PC-3000 e Data Extractor.
Storage corporativo por dentro: pools, LUNs, RAID distribuído, VMFS e metadata
Esta seção aprofunda as entidades mais importantes para mecanismos de busca, administradores e sistemas de IA sem reduzir storage a um "RAID grande".
1. Storage não é apenas um servidor sem aplicações
Appliances de storage possuem controladoras, CPU, memória, cache, firmware e sistemas operacionais internos. O diferencial é que sua função principal é fornecer e proteger armazenamento, não hospedar aplicações de usuário final como um servidor de propósito geral.
2. Block storage
SAN e muitos DAS apresentam blocos. O storage não precisa conhecer VMFS, NTFS ou ReFS para servir a LUN; o host organiza o filesystem acima da camada de bloco.
3. File storage
NAS apresenta SMB/NFS e mantém o filesystem dentro do appliance. Em recuperação, o filesystem interno faz parte da reconstrução.
4. Object storage
Alguns sistemas corporativos também apresentam objetos. A organização, metadata e erasure coding podem ser diferentes de LUNs e RAID tradicionais.
5. Disk group
Dell ME5 e HPE MSA usam disk groups como agregações de discos protegidas por RAID ou tecnologias distribuídas, adicionadas a pools.
6. Storage pool
Pool agrega capacidade e funciona como origem para volumes. Em virtual storage, páginas/extents lógicos podem ser distribuídos pelos disk groups.
7. Volume e LUN
Volume é a capacidade lógica definida no storage. Quando mapeado a host por SAN, recebe um LUN ID ou equivalente. O filesystem do host pode estar acima desse volume.
8. Thin provisioning
Thin volumes não precisam consumir fisicamente toda a capacidade lógica no momento da criação. A metadata de alocação define quais pages/extents possuem dados reais.
9. Snapshots
Snapshots podem compartilhar blocos com o volume base. A implementação varia entre plataformas e não deve ser tratada como cópia física completa em todos os sistemas.
10. Dell ME5 virtual pages
Dell documenta virtual storage como mapping de páginas lógicas para páginas físicas no pool, sem relação direta obrigatória entre páginas lógicas adjacentes e localização física adjacente.
11. Dell ADAPT
ADAPT é proteção distribuída no PowerVault ME. Grupos virtuais podem ter de 12 a 128 disks e expansão própria. Isso exige interpretação diferente de um RAID 6 fixo.
12. HPE MSA virtual storage
MSA 1060/2060 documenta disk groups adicionados a pools, volumes virtuais, snapshots, replication, tiering e overcommit. Esses recursos aumentam a quantidade de metadata entre disco e LUN.
13. MSA-DP+
MSA-DP+ é uma proteção distribuída HPE em gerações atuais. Não deve ser reconstruída automaticamente como um RAID 6 clássico sem identificar a implementação.
14. NetApp aggregate/local tier
NetApp define aggregate/local tier como estrutura que contém um ou mais RAID groups. Volumes vivem dentro dessa capacidade e WAFL mantém metadata de volumes.
15. NetApp plex
ONTAP expõe plexes, RAID groups, disks e estados de reconstruction. Em ambientes espelhados, múltiplos plexes podem representar cópias da camada WAFL do aggregate.
16. RAID-DP
NetApp documenta dupla paridade para tolerar até duas falhas simultâneas de disco dentro das condições suportadas.
17. RAID-TEC
NetApp RAID-TEC oferece tripla paridade e pode tolerar até três falhas simultâneas de disco, dependendo da configuração suportada.
18. IBM DRAID
IBM distributed RAID espalha dados, paridade e rebuild areas pelo conjunto. DRAID5 tolera uma falha e DRAID6 duas falhas em condições normais.
19. IBM Storage Virtualize
FlashSystem e SVC virtualizam arrays internos e storage externo em MDisks/pools e volumes. A relação entre uma LUN e um disco físico não precisa ser direta.
20. Lenovo DE Pool
Lenovo documenta pools separados de volume groups. Pools usam proteção distribuída baseada em RAID 6, enquanto volume groups permitem RAID selecionado.
21. Lenovo shelf loss protection
A distribuição de membros entre shelves/drawers pode ser parte do desenho de resiliência. Um incidente em enclosure pode remover vários membros simultaneamente sem múltiplas falhas independentes.
22. Hitachi parity group
Hitachi VSP constrói parity groups a partir de drives. LDEVs e pool volumes podem ser criados sobre essa camada para alimentar pools de Dynamic Provisioning.
23. Hitachi LDEV
LDEV é a unidade lógica do ecossistema VSP e pode estar associada a parity groups e pools. O host recebe LUNs construídas sobre essas abstrações.
24. Controladora dual
Dual controllers melhoram disponibilidade, mas não significam duas cópias independentes de todos os dados. Pool e discos podem ser compartilhados. Falha lógica ou múltipla pode atingir a camada comum.
25. Controller failure
Falha da controladora pode retirar acesso sem apagar os blocos. Metadata pode existir em discos e estruturas distribuídas. Em alguns casos, cache ou estado da controladora ainda é importante para operações pendentes.
26. Reboot
Não existe regra universal de que reboot sempre sobrescreve metadata. Porém, storages podem executar replay, verify, failover, reconstruction ou outras rotinas. Reduzir tentativas e preservar logs é prudente quando o estado é desconhecido.
27. Rebuild
Rebuild é parte normal da manutenção de RAID. Distributed RAID pode usar rebuild areas ou reconstrução distribuída. Em mídias instáveis, o risco físico precisa ser avaliado antes.
28. Media errors
Setores ilegíveis em membros sobreviventes podem causar falha localizada ou ampla conforme a stripe e a proteção existente. Um único erro não deve ser automaticamente chamado de perda total.
29. Disk order
Em RAID clássico e algumas reconstruções, ordem dos membros é essencial. Mesmo quando metadata identifica drives, registrar slot/enclosure/serial acelera o diagnóstico e reduz dependência de automação.
30. Stripe size
O tamanho do elemento distribuído entre membros faz parte da geometria do RAID. Em distributed RAID, outras camadas de virtualização podem existir acima.
31. Start offset
Metadata e alinhamentos podem deslocar o início útil do array. Offset incorreto faz o fluxo de blocos parecer inconsistente.
32. Parity rotation
RAID 5/6 e implementações relacionadas distribuem paridade conforme algoritmos da plataforma. A reconstrução deve usar a implementação real, não um preset genérico pela marca.
33. VMware VMFS
Uma LUN reconstruída pode conter VMFS. Broadcom recomenda não escrever novos dados nem criar filesystem quando a recuperação do conteúdo perdido é necessária.
34. ReFS e CSV
Hyper-V pode usar ReFS/NTFS e CSV. Uma LUN mapeada incorretamente a outro host pode receber uma nova assinatura e sobrescrever a estrutura anterior.
35. Multipath
Host sem acesso à LUN pode estar com problema de zoning, FC, iSCSI, MPIO ou target mapping. Antes de desmontar um storage, confirme se o problema não é caminho.
36. All-flash
SSD/NVMe adiciona FTL, firmware e NAND à investigação. Falha física da mídia e falha lógica de pool precisam ser separadas.
37. Deduplicação
Dedup cria relações entre blocos e objetos. Recuperação exige metadata da plataforma para interpretar referências. Não existe um algoritmo universal para todas as marcas.
38. Compressão
Dados físicos comprimidos precisam do formato e metadata da plataforma para se transformar no conteúdo lógico original.
39. Criptografia
SED, FDE, KMIP e encryption-at-rest podem tornar chave/configuração tão importante quanto os discos. Preserve key manager, passphrases e configuration backups.
40. WinHex
WinHex pode ajudar na inspeção e validação de baixo nível em clones. Ele é especialmente útil em RAID tradicional e análise de headers, mas não substitui decodificação específica de pools proprietários.
41. PC-3000
PC-3000 pode ajudar no diagnóstico físico/firmware de mídias compatíveis. Em storage com dezenas de dispositivos, a etapa física e a reconstrução lógica são processos separados.
42. Sala limpa ISO-5
HDDs com falhas mecânicas podem exigir procedimentos físicos controlados antes da clonagem. Nem todo storage precisa desse tipo de intervenção.
43. Sem necessidade do enclosure completo
Em muitos casos, mídias, ordem, logs e configuração bastam para iniciar. Controladoras, cache, encryption e backplane podem exigir componentes adicionais em casos específicos.
44. Ransomware e storage
RAID e storage redundante não são backup. Ransomware, exclusão e corrupção lógica podem ser replicados ou gravados em todo o volume. Snapshots imutáveis e backups independentes são controles diferentes.
45. Matriz técnica de decisão
| Sintoma | Camada provável | Prioridade | Evitar |
|---|---|---|---|
| LUN invisível | Path / mapping / storage | Logs host + controllers | Recriar volume sem diagnóstico |
| Pool Degraded | Disk group / DRAID / metadata | Estado dos membros e proteção | Rebuild cego |
| Pool Offline | Múltiplos grupos / metadata | Preservar discos e logs | Re-create pool |
| Controller A/B failure | Hardware ou camada compartilhada | Separar failover de corrupção lógica | Controller swap por tentativa |
| VMFS inaccessible | LUN + filesystem | Preservar LUN e VMFS | New Datastore |
| All-flash drive offline | SSD/FTL ou pool | Diagnóstico individual | Assumir só falha lógica |
| Encrypted pool | Crypto / key management | Preservar keys e config | Reset security |
| Vários drives Missing | Shelf/expander/power/mídia | Mapeamento físico e logs | Declarar todos mortos |
46. Conclusão técnica
Recuperação de storage corporativo é a reconstrução do caminho entre mídia física e informação lógica. O melhor resultado vem de preservar o estado, identificar a plataforma e trabalhar por camadas. RAID Low Level é importante, mas pools, LUNs, thin provisioning, VMFS, snapshots e metadata de fabricante podem ser igualmente decisivos.
Referências utilizadas para validar este guia
- Dell PowerVault ME5: disk groups, pools e volumes
- Dell PowerVault ME5: virtual storage e page mapping
- Dell PowerVault ME5/ME52: RAID, ADAPT e pools
- HPE MSA 1060/2060/2062: disk groups, pools, virtual storage e MSA-DP+
- NetApp ONTAP: aggregates, plexes e storage resources
- NetApp ONTAP: RAID-DP e RAID-TEC
- IBM Storage Virtualize / FlashSystem: Distributed RAID e rebuild areas
- IBM FlashSystem/SVC 9.1.3: limites atuais de Distributed RAID
- Lenovo DE Series: pools x volume groups
- Lenovo DE: shelf/drawer loss protection
- Hitachi VSP: drives, parity groups, LDEVs e pools
- Broadcom VMware: VMFS inaccessible, preservar LUN quando recuperação é necessária
- Broadcom VMware: VMFS sobrescrito por ReFS
- X-Ways: WinHex low-level data processing and RAID interpretation
