Ambientes IBM System x abrangem várias gerações de ServeRAID, controladoras antigas e M-series, discos SCSI/SAS/SATA, VMware e bancos de dados. Quando o volume desaparece, a causa pode estar em mídia, backplane, controladora, metadata, RAID ou filesystem. A recuperação começa identificando exatamente a geração e preservando o estado antes de Force Online, Import, Initialize ou rebuild.
O que é um servidor IBM System x?
A intenção principal desta página é recuperação de dados em servidor IBM System x. ServeRAID e RAID aparecem como arquitetura de armazenamento específica, sem tentar substituir a página pilar geral de RAID.
Guia completo de recuperação de dados em IBM System x
Do disco ao banco de dados: System x precisa ser analisado por camadas
Um Virtual Drive Missing pode impedir boot, VMware ou bancos sem significar que os blocos desapareceram dos discos. A recuperação precisa separar mídia, controladora, logical drive, filesystem e aplicação.
A marca IBM identifica a plataforma. A recuperação precisa localizar a camada exata onde o dado deixou de ser apresentado.
Em sistemas legados, a interface pode ser SCSI ou SAS. Em M-series, ServeRAID pode usar WebBIOS e MegaRAID Storage Manager. Em todos os casos, a marca do servidor sozinha não define o layout do array.
Defunct, Missing, Critical, Offline e RAW: o que esses estados realmente dizem
Defunct
Estado de falha atribuído pelo ServeRAID. IBM documenta que ele não significa necessariamente substituição imediata da mídia.
Missing
O membro esperado não foi encontrado. Cabo, backplane, slot, controladora ou a própria mídia podem estar envolvidos.
Critical / Degraded
Logical drive redundante perdeu parte da proteção, mas pode permanecer online dentro da tolerância.
Virtual Drive Missing
O logical volume deixa de ser apresentado normalmente. Os discos ainda precisam ser avaliados individualmente.
Rebuild não inicia
IBM documenta comportamentos distintos conforme drive novo/usado, inicialização e auto failover.
Volume RAW
O sistema não reconhece o filesystem esperado. Pode haver montagem RAID incorreta, corrupção lógica ou leitura incompleta.
Por que documentos IBM System x também aparecem hoje no site da Lenovo?
Em 2014, Lenovo adquiriu o negócio de servidores x86 da IBM. A transação incluiu System x, BladeCenter, Flex System x86, NeXtScale e iDataPlex. IBM manteve Power Systems, mainframes e storage próprio.
| Família | Exemplos | Contexto para recuperação |
|---|---|---|
| System x antigo | x3200, x3250, x3400, x3500 | Gerações variadas de ServeRAID, SCSI/SAS e ferramentas legadas |
| System x M2/M3/M4 | x3550, x3650, x3500 | ServeRAID M1015/M501x/M5110 e IMM/IMM2 conforme modelo |
| System x M5 | x3650 M5 | Já sob Lenovo, com ServeRAID M1215/M5210 e IMM2.1 |
| IBM Power | Power Systems | Não é System x; AIX/IBM i e storage têm arquitetura própria |
| IBM Storage | Storwize, SVC | Não tratar como RAID local de System x sem identificar o backend |
ServeRAID não é uma controladora única: 4x, 8x, M1015, M5110 e M5210 têm comportamentos diferentes
A IBM usou a marca ServeRAID por muitas gerações. Modelos antigos tinham interfaces SCSI e estados clássicos como DDD. A família M incorporou controladoras SAS/SATA e software WebBIOS/MegaRAID Storage Manager.
| Exemplo | Plataformas associadas | RAID / recursos relevantes |
|---|---|---|
| ServeRAID 4H / 5i / 6i | xSeries / Netfinity antigos | RAID 0, 1, 1E, 5, 10, 50 conforme modelo; SCSI Ultra160/320 |
| ServeRAID 8i / 8k / 8k-l | System x de gerações anteriores | Auto Failover, Hot Spare e comportamento específico para drives usados |
| M1015 | x3200/x3250/x3400/x3500/x3550/x3650 M2/M3 | SAS/SATA e recursos conforme firmware/licenciamento |
| M5110 / M5110e | x3500/x3550/x3650 M4 | RAID 0/1/10 base; upgrades para 5/50/6/60 em plataformas compatíveis |
| M5210 | System x M4/M5 e Lenovo System x | 12 Gb SAS/SATA; RAID e recursos adicionais conforme upgrades |
Usar apenas o nome "ServeRAID" é insuficiente para decidir Import, Rebuild, Initialize ou Force Online. O modelo e a geração são obrigatórios.
ServeRAID Defunct: o primeiro passo é reconstruir a linha do tempo
IBM mantém documentação específica para recuperação de um único DDD e múltiplos DDD. Em arrays redundantes com uma única falha, replace e rebuild são procedimentos normais. Em múltiplas falhas, a própria IBM recomenda consultar o event log para identificar a sequência em que os drives foram marcados Defunct.
O documento de múltiplos DDD alerta que timestamps são uma forte indicação, mas nem sempre registram a ordem perfeita em falhas paralelas. Para recuperação profissional, logs são evidência, não verdade absoluta.
Configuração nos discos, F6 Modify e F7 Import: a arquitetura é mais flexível do que parece
Uma afirmação comum em páginas concorrentes é que ServeRAID depende de metadata exclusiva em NVRAM e que mover um disco de slot sempre invalida o array. A documentação IBM mostra um cenário mais nuançado.
Discos em nova localização
Mensagens antigas ServeRAID oferecem F6 Modify para aceitar a nova posição quando drives foram recolocados em slots diferentes.
Import da configuração
IBM documenta F7 Import para ler configuração dos drives e atualizar a controladora após troca do ServeRAID ou conjunto de discos.
M-series e Foreign
UEFI e software ServeRAID-M incluem gerenciamento de foreign configuration e MegaRAID Storage Manager.
Por que ainda preservar slots?
Porque gerações e estados variam. Manter posição original reduz ambiguidade e evita depender de comportamento automático.
Rebuild em ServeRAID é legítimo, mas drives usados podem disparar comportamentos automáticos
A IBM documenta que arrays redundantes devem ser regenerados após uma falha simples. Porém, ServeRAID-8x também possui comportamentos diferentes conforme Auto Failover, Hot Spare e se o drive substituto já contém metadata.
| Situação | Comportamento documentado | Leitura para recuperação |
|---|---|---|
| Drive novo + Auto Failover | Pode auto-inicializar e iniciar rebuild | Manutenção normal quando conjunto está saudável |
| Drive previamente usado + Auto Failover | Pode ser inicializado e perder seus dados antigos | Não reinsira mídia histórica em dados críticos por tentativa |
| Drive usado + Auto Failover desabilitado | Metadata pode ser importada e criar logical drive separado | O estado pode mudar sem ser o membro correto do array atual |
| Reboot após drive Defunct | Algumas gerações reavaliam o drive como substituto | Registre o estado antes de reinicializações repetidas |
Isso não significa que reiniciar sempre destrói o array. Significa que algumas gerações executam ações automáticas que podem alterar o estado. Em dados únicos, preservar antes é mais seguro que explorar esse comportamento no original.
Como mirror e paridade aparecem nas gerações ServeRAID
RAID 1 / 10
Mirror, sem paridade
RAID 5
Paridade P distribuída
RAID 6
P + Q em gerações compatíveis
RAID 50 / 60
Grupos + striping conforme modelo e recursos
RAID 1 / 10
Espelhamento. Não existe P/Q nos outros membros para recalcular regiões perdidas em todas as cópias.
RAID 5
Paridade simples. Foi amplamente suportado por gerações ServeRAID, com rebuild após falha simples em arrays redundantes.
RAID 6
Aparece em M-series e plataformas compatíveis mediante recursos ou upgrades, com dupla paridade.
RAID 50 / 60
Dependem da família e do licenciamento. O estado de cada grupo precisa ser analisado separadamente.
10 passos quando IBM System x perde o volume
O que pode agravar a recuperação de um IBM System x
Assumir que DDD significa disco morto
IBM orienta conferir cabos, backplane e rebuild em determinados cenários. O estado lógico não substitui diagnóstico de mídia.
Assumir que metadata existe só na NVRAM
IBM documenta Import de configuração a partir dos drives em diversas gerações.
Reinserir drive usado com Auto Failover ativo
ServeRAID-8x pode auto-inicializar a mídia e destruir dados antigos desse drive.
Force Online sem cronologia
Em múltiplos DDD, a ordem das falhas pode ser crítica. Não traga membros online aleatoriamente.
Reinstalar ou formatar volume RAW
RAW não comprova que os blocos foram perdidos. Preserve a camada RAID antes de repair ou formatação.
Usar software diretamente nos originais
Ferramentas lógicas podem ser úteis sobre imagens e com geometria conhecida. Em mídias instáveis, a prioridade é aquisição controlada.
Como a SECURITY conduz recuperação de dados de IBM System x
O objetivo é preservar os blocos disponíveis e reconstruir o storage fora do servidor original sempre que o cenário exigir.
Caio Bruno F. Garcia, RAID Low Level e WinHex em IBM de extrema complexidade
WinHex oferece inspeção hexadecimal e interpretação de RAID em cenários compatíveis. Em ambientes IBM legados, isso pode ajudar a diferenciar metadata antiga, novos headers e estruturas parcialmente alteradas após rebuild ou troca de controladora.
Metadata ServeRAID
Comparar áreas reservadas e assinaturas sem depender exclusivamente do painel da controladora.
Disk order e stripe
Validar sequência dos membros, interleave, stripe size e offsets usando estruturas do volume.
Paridade
Em RAID 5/6, coerência matemática pode ajudar a confirmar o layout e localizar stripes com lacunas.
Estados históricos
Comparar drives retirados e atuais quando existem rebuilds, auto failover ou imports anteriores.
VMware e Hyper-V em IBM System x
VMware ESXi
System x foi amplamente usado em virtualização. Depois do RAID podem existir VMFS, VMDK e snapshots que precisam de validação própria.
Hyper-V
NTFS/ReFS podem conter VHDX e checkpoints. A recuperação precisa validar a cadeia da VM e o filesystem interno.
Boot separado de dados
O sistema pode falhar no volume de boot enquanto logical drives de produção continuam recuperáveis.
RAID reconhecido não basta
Um Virtual Drive Online não comprova que VMFS, NTFS ou as VMs estão consistentes.
Storwize, SAN e armazenamento externo em ambientes IBM
Um System x pode consumir LUNs de IBM Storwize, SAN Volume Controller ou outro storage. Nesses casos, os discos internos podem conter apenas sistema operacional, enquanto os dados de produção residem fora do servidor.
IBM Storwize
V3700 e outras famílias possuem arrays internos, pools, LUNs e em versões posteriores Distributed RAID. Não devem ser tratados como ServeRAID local.
Fibre Channel / iSCSI
O host pode apenas apresentar o LUN remoto. Identificar storage e multipathing evita recuperar a camada errada.
IBM Power
Power Systems e IBM i/AIX permanecem plataformas IBM e exigem escopo próprio, não o mesmo procedimento de System x.
Lenovo System x
Modelos após a aquisição de 2014 mantiveram continuidade técnica de System x e ServeRAID, com suporte e documentação migrando para Lenovo.
SQL Server, Oracle e aplicações depois da reconstrução do ServeRAID
Recuperar o logical drive é apenas uma etapa. Bancos precisam ser validados no nível da aplicação.
SQL Server
MDF/NDF e LDF representam dados e logs. Depois da extração, a consistência precisa ser testada fora do servidor original.
Oracle
Datafiles, control files, redo e outros componentes podem depender da consistência do storage e do filesystem.
Aplicações legadas
System x ainda hospeda ERPs e softwares antigos. A recuperação deve priorizar arquivos e serviços que representam continuidade operacional.
Principais tecnologias encontradas em projetos IBM System x
O System x é o foco desta página, mas os dados podem depender de ServeRAID, storage externo, virtualização e aplicações.
Vídeos da SECURITY sobre RAID, servidores, VMs e banco de dados
O vídeo pilar mostra a metodologia por camadas usada também em IBM System x: primeiro as mídias, depois RAID/storage, depois VMs e aplicações.
Cenários técnicos de recuperação de IBM System x
x3650 M4 com M5110e e múltiplos discos Defunct
Contexto: após evento elétrico, dois membros aparecem DDD e o Virtual Drive deixa de montar.
Estratégia: preservar RAIDx.LOG, seriais, controladora e mídias; diagnosticar os discos individualmente e reconstruir o array sobre imagens.
x3500 com ServeRAID substituída e configuração importada
Contexto: a controladora original falha e uma substituta importa metadata dos discos.
Estratégia: comparar o estado antes e depois da troca, preservar a ServeRAID antiga e validar logical drives sem assumir que a nova configuração reproduz toda a topologia anterior.
ServeRAID-8k com drive usado reinserido
Contexto: um disco previamente utilizado é colocado no array e o comportamento de Auto Failover altera seu estado.
Estratégia: não usar o original para novas tentativas; analisar metadata e clones e separar drive histórico do membro atualmente aceito pela controladora.
IBM System x com VMware e VMFS inacessível
Contexto: logical drive reaparece, mas VMs permanecem Inaccessible.
Estratégia: validar o RAID primeiro, depois VMFS, VMDK e snapshots, sem criar novo datastore sobre o volume original.
FAQ sobre recuperação de dados em IBM System x
O que é um servidor IBM System x?
IBM System x foi a família de servidores x86 da IBM, incluindo modelos como x3200, x3250, x3400, x3500, x3550, x3650 e plataformas maiores. Em 2014, a Lenovo adquiriu o negócio x86 da IBM, incluindo System x e BladeCenter, enquanto a IBM manteve Power Systems, mainframes e outras linhas. Por isso, documentação de System x pode aparecer hoje em sites IBM e Lenovo.
O que é recuperação de dados em servidor IBM System x?
É o processo de preservar as mídias e reconstruir o armazenamento quando falhas em discos, ServeRAID, backplane, RAID, filesystem, virtualização ou banco de dados tornam os dados inacessíveis. O objetivo é recuperar os dados e aplicações úteis, não apenas fazer o servidor voltar a inicializar.
IBM System x e IBM Power são a mesma plataforma?
Não. System x é a linha x86 que passou para a Lenovo em 2014. IBM Power Systems, AIX e IBM i permaneceram com a IBM e usam arquiteturas diferentes. Antes de qualquer recuperação, confirme se o equipamento é System x, Power ou storage IBM.
O que significa DDD ou Defunct no ServeRAID?
DDD ou Defunct é um estado atribuído pela controladora a uma unidade considerada falha ou indisponível. A própria IBM documenta que um disco em estado DDD não significa necessariamente que precisa ser substituído imediatamente: cabos, backplane, encaixe e capacidade de rebuild também devem ser avaliados.
O que significa Virtual Drive Missing ou Offline?
Significa que a controladora não está apresentando o volume lógico normalmente. A causa pode envolver membros ausentes, metadata, controladora, firmware, backplane ou exceder a tolerância do RAID. O desaparecimento do Virtual Drive não prova que os dados dos discos foram apagados.
Posso mover discos de slot em um ServeRAID?
Algumas gerações antigas de ServeRAID documentam mensagens de discos encontrados em nova localização e opções para aceitar a nova posição. Portanto, mover slots não é universalmente destrutivo. Em recuperação de dados, porém, preserve a ordem original porque diferentes gerações e estados podem reagir de forma diferente.
Posso importar a configuração a partir dos discos?
Algumas gerações ServeRAID documentam uma função Import que lê configuração dos discos e atualiza a controladora. Em M-series, WebBIOS e MegaRAID Storage Manager também possuem conceitos de foreign configuration. Isso mostra que não é correto afirmar que toda configuração existe somente na NVRAM. A operação, porém, deve ser avaliada no contexto do caso.
A configuração RAID fica somente na NVRAM da controladora?
Não como regra universal. Documentação IBM de várias gerações mostra configuração e metadata nos discos, além de informações na controladora. Modelos antigos e M-series possuem comportamentos diferentes. Em recuperação, preserve controladora, módulos e discos sempre que possível.
Rebuild é sempre perigoso em servidor IBM?
Não. A IBM documenta rebuild e regeneration como procedimentos normais para arrays redundantes quando um único membro falha. O risco aumenta quando existem múltiplos Defunct, mídia instável, dados únicos sem backup ou um rebuild anterior já falhou.
Por que um rebuild pode não iniciar após trocar um disco?
A IBM documenta casos em que drives novos ou previamente usados precisam ser inicializados antes do rebuild, dependendo da geração e das configurações de auto failover. Em algumas versões, um drive usado pode ter metadata importada automaticamente ou ser inicializado, o que torna importante conhecer o comportamento da controladora.
Reiniciar repetidamente o servidor pode alterar o estado do RAID?
Pode, dependendo da geração. Documentação ServeRAID-8x mostra que, após reiniciar, uma unidade antes marcada Defunct pode ser tratada como drive substituído e desencadear ações de failover ou rebuild conforme as configurações. Isso não significa que todo reboot seja destrutivo, mas reforça a importância de registrar o estado antes de novas tentativas.
ServeRAID M5110 e M5210 são controladoras IBM?
Foram comercializadas para IBM System x e posteriormente para Lenovo System x. A documentação IBM/Lenovo mostra M5110/M5210 em modelos x3500, x3550 e x3650 e o software da família ServeRAID-M inclui WebBIOS e MegaRAID Storage Manager.
Quais níveis RAID o ServeRAID suporta?
Depende muito da geração. Controladoras antigas suportam combinações de RAID 0, 1, 1E, 5, 10 e 50. Modelos M-series podem suportar RAID 0, 1, 10 e, com recursos ou upgrades, RAID 5, 50, 6 e 60. O modelo exato precisa ser identificado.
Servidor IBM com RAID degradado ainda pode funcionar?
Sim. Em níveis redundantes, um logical drive pode continuar em estado Critical ou Degraded após uma falha dentro da tolerância. A IBM recomenda backup e rebuild em cenários suportados. Em dados críticos, media errors ou múltiplos Defunct mudam o risco.
Dois discos Defunct significam perda total?
Não existe uma resposta única. O impacto depende do nível RAID, ordem das falhas e estado real das mídias. A IBM alerta que múltiplos DDD podem exceder a redundância e usa event logs para identificar a sequência das falhas. Em recuperação especializada, discos marcados Defunct ainda podem fornecer dados parciais.
Servidor IBM com volume RAW pode ser recuperado?
Pode existir viabilidade. RAW significa que o sistema operacional não reconhece o filesystem esperado. A causa pode ser corrupção lógica, montagem incorreta do RAID, setores ilegíveis ou intervenção anterior. Não formate para tentar recuperar.
É possível recuperar VMware ou Hyper-V de IBM System x?
Pode. Primeiro o storage e o RAID precisam apresentar um fluxo lógico coerente. Depois são analisados VMFS, VMDK, NTFS/ReFS, VHDX, snapshots e o filesystem das máquinas virtuais.
É possível recuperar SQL Server ou Oracle do servidor IBM?
Pode existir viabilidade depois que a camada de storage é reconstruída. Bancos de dados exigem validação própria de arquivos, páginas e logs. Arquivos presentes no volume não comprovam consistência da aplicação.
O que é RAID Low Level em IBM System x?
É a análise abaixo do filesystem, incluindo ordem dos discos, stripe size, offsets, metadata, spans e paridade. É útil quando ServeRAID não apresenta mais o logical drive ou quando houve várias intervenções no array.
Como WinHex pode ajudar em um caso IBM complexo?
WinHex oferece inspeção hexadecimal e recursos de interpretação de RAID. Em casos de extrema complexidade pode auxiliar a comparar metadata, encontrar assinaturas e validar ordem, stripe e offsets. Ele não substitui clonagem profissional, diagnóstico físico ou conhecimento da arquitetura.
Preciso enviar o servidor inteiro?
Nem sempre. Em muitos casos, discos, ordem das baias, modelo ServeRAID, screenshots e logs são suficientes. Em falhas que envolvem backplane, cache, controladora ou componentes específicos, o servidor completo pode agregar contexto.
Quanto custa recuperar dados de IBM System x?
O custo depende de quantidade e capacidade das mídias, nível RAID, ServeRAID, falhas físicas, VMs, bancos e intervenções anteriores. Um diagnóstico do conjunto é necessário para dimensionar o serviço.
Quanto tempo leva?
O prazo depende principalmente da saúde e capacidade das mídias. Clonar vários discos SAS pode levar mais tempo do que remontar logicamente o RAID. VMs, bancos e múltiplas falhas adicionam etapas de validação.
A SECURITY atende IBM System x em todo o Brasil?
Sim. A SECURITY atende empresas de diferentes regiões do Brasil e orienta logística segura conforme o cenário. Em Barueri, este artigo prioriza Alphaville, além de São Paulo e Campinas.
Recuperação de IBM System x em Alphaville, São Paulo, Campinas e todo o Brasil
A SECURITY atende empresas de diferentes regiões do Brasil e orienta o envio de discos, servidor ou storage conforme o caso. 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.
IBM System x por dentro: ServeRAID, DDD, metadata, rebuild, VMware e RAID Low Level
Esta seção aprofunda detalhes que ajudam a evitar generalizações incorretas sobre ServeRAID e tornam o conteúdo citável por mecanismos de busca e sistemas de IA.
1. System x é x86
System x era a linha x86 da IBM. Isso a diferencia de Power Systems, AIX e IBM i, que permaneceram com a IBM após a venda do negócio x86 para a Lenovo.
2. A aquisição de 2014 importa para documentação
Lenovo concluiu a aquisição inicial em 1 de outubro de 2014. Por isso, suporte de System x M4/M5 e ServeRAID aparece distribuído entre IBM e Lenovo.
3. ServeRAID cobre muitas gerações
ServeRAID 4H/5i/6i, 8x, M1015, M501x, M5110 e M5210 não compartilham necessariamente o mesmo firmware, interface, cache e comportamento automático.
4. M-series e MegaRAID Storage Manager
A documentação ServeRAID-M inclui WebBIOS e MegaRAID Storage Manager. Isso reforça que M-series compartilham conceitos e tecnologia com a família MegaRAID, sem tornar todas as implementações idênticas.
5. M5110
IBM publicou documentação M5110 para x3500 M4, x3550 M4 e x3650 M4. O modelo e seus upgrades determinam cache e níveis RAID disponíveis.
6. M5210
M5210 aparece em documentação IBM/Lenovo para System x M4 e M5. Em x3650 M5, Lenovo documenta RAID 0/1/10 base e upgrades para 5/50/6/60 conforme recursos.
7. Defunct é estado lógico
A documentação IBM de startup errors afirma que um drive DDD não significa necessariamente necessidade de substituição. Cabos, backplane, tray e rebuild devem ser considerados conforme o cenário.
8. Single DDD
Em RAID redundante, IBM documenta replace e regeneration/rebuild como fluxo normal após falha simples, desde que exista backup e o restante do conjunto esteja saudável.
9. Multiple DDD
IBM alerta que não existe garantia de recuperação íntegra quando múltiplos drives ficam Defunct. O event log ajuda a localizar a ordem provável das falhas e orientar o troubleshooting.
10. Event logs não são infalíveis
O próprio documento de múltiplos DDD observa que falhas paralelas em canais diferentes podem comprometer a exatidão da ordem temporal no log. Por isso, timestamps são evidência, não prova única.
11. Drive em nova localização
ServeRAID antigo documenta mensagens para drives encontrados em nova posição e função Modify para aceitar a nova localização. Isso corrige a ideia de que qualquer mudança de slot destrói automaticamente o array.
12. Import da configuração
Algumas gerações documentam F7 Import para ler configuração dos drives e atualizar a controladora. M-series também possuem gerenciamento de foreign config. Portanto, metadata não deve ser tratada como exclusiva da NVRAM.
13. NVRAM continua relevante
A controladora possui estado, firmware e cache. Preservar o controller original pode ajudar a interpretar o ambiente, mas não significa que toda a estrutura exista apenas nele.
14. Auto Failover
ServeRAID-8x documenta Auto Failover capaz de inicializar drive substituto e iniciar rebuild. Drives usados podem perder seus dados antigos quando tratados como replacements.
15. Drive usado com Auto Failover desabilitado
IBM documenta que metadata pode ser importada de um drive usado e criar logical drive separado, dependendo do estado. Isso mostra por que reinserir mídia histórica pode mudar o ambiente.
16. Reboot e reavaliação
Em ServeRAID-8x, um drive antes Defunct pode ser tratado como replacement após restart se voltar a responder. Esse comportamento não torna todo reboot destrutivo, mas justifica registrar o estado antes de repetir ciclos.
17. RAID 0
IBM documenta que RAID 0 não possui redundância. Em manutenção oficial, falha de membro implica restaurar a partir de backup. Em recuperação especializada, ainda se avalia se a mídia problemática pode ser lida parcialmente.
18. RAID 1 e RAID 10
Mirrors dependem de pelo menos uma cópia válida de cada segmento. Não existe paridade nos outros membros para recalcular um mirror totalmente perdido.
19. RAID 5
ServeRAID suportou RAID 5 em muitas gerações. O array redundante pode continuar Critical com uma falha e ser regenerado após substituição do membro.
20. RAID 6
RAID 6 aparece em M-series e plataformas compatíveis com os recursos necessários. IBM Power e Storwize também documentam RAID 6, mas essas arquiteturas não devem ser confundidas com System x local.
21. RAID 50 / 60
M-series podem oferecer RAID 50 e 60 conforme upgrades e controlador. A reconstrução precisa separar grupos de paridade e a camada de striping.
22. Backplane
IBM possui casos em que drives Missing ou DDD estavam relacionados a backplane, IDs ou controladora. Múltiplos discos sumindo simultaneamente não provam múltiplas falhas físicas.
23. Firmware
Documentação de x3650 M4 mostra casos em que ServeRAID M5110e podia desaparecer do UEFI por firmware/PSOC. Isso reforça que ausência da controladora não implica automaticamente perda dos discos.
24. Disk order
A ordem dos membros continua relevante para reconstrução virtual, mesmo quando a controladora possui mecanismos de aceitar novos slots. Preserve posições originais para reduzir hipóteses.
25. Stripe size
Stripe/interleave define a distribuição dos blocos. O valor pode ser inferido de metadata, software da controladora e coerência do filesystem.
26. Start offset
Metadata e alinhamentos podem deslocar o início útil em cada membro. Offset incorreto faz o volume parecer corrompido mesmo quando as mídias estão boas.
27. Parity rotation
RAID 5 e 6 distribuem paridade. Validar o padrão ajuda a confirmar disk order e geometria em reconstruções fora da controladora.
28. WinHex
WinHex pode auxiliar inspeção de setores, metadata e interpretação de RAID. Seu uso é mais seguro sobre clones quando o estado físico é incerto.
29. PC-3000 e DeepSpar
Ferramentas de aquisição ajudam a obter os blocos possíveis de membros instáveis antes de reconstruir o logical drive. Nenhuma delas substitui a análise da topologia.
30. Sala limpa ISO-5
HDDs com falhas mecânicas podem exigir procedimentos físicos controlados antes da clonagem. Essa é a camada de mídia, anterior à reconstrução do ServeRAID.
31. VMFS
Depois do RAID, VMware pode apresentar datastores VMFS. O fato de o logical drive voltar a Online não prova que VMFS e VMDKs estão íntegros.
32. Hyper-V
VHDX e checkpoints podem depender de NTFS/ReFS. O arquivo virtual precisa ser validado internamente.
33. Storwize
IBM Storwize possui arquitetura de storage própria, inclusive RAID e Distributed RAID em versões posteriores. Não deve ser reconstruído como se fosse ServeRAID local de System x.
34. IBM Power
Power Systems, AIX e IBM i exigem identificação própria. Esta página não transforma toda plataforma IBM em System x.
35. Segunda opinião
Force Online, Initialize, Import, rebuild e controller swap anteriores precisam ser relatados. Uma nova avaliação não garante sucesso, mas ajuda a interpretar o estado atual sem repetir intervenções.
36. Matriz técnica de decisão
| Sintoma | Camada provável | Prioridade | Evitar |
|---|---|---|---|
| DDD / Defunct | Mídia, cabo, backplane ou estado RAID | Logs e diagnóstico individual | Declarar disco morto sem teste |
| Multiple DDD | Redundância excedida ou falha compartilhada | Sequência de eventos e aquisição | Force Online aleatório |
| Virtual Drive Missing | Controladora / metadata / membros | Preservar configuração e discos | Criar novo VD |
| Rebuild não inicia | Drive state / auto failover / mídia | Identificar geração e comportamento | Reinserir drive usado por tentativa |
| Volume RAW | RAID ou filesystem | Validar topologia antes de repair | Formatar |
| VMFS inaccessible | RAID + filesystem | Preservar logical drive e VMFS | Novo datastore |
| Storwize LUN ausente | Storage externo | Investigar array/pool/LUN | Focar apenas nos discos locais |
| Banco inconsistente | Aplicação | Extrair e validar em separado | Attach destrutivo no original |
37. Conclusão técnica
IBM System x atravessa décadas de hardware e várias gerações ServeRAID. A recuperação segura não parte de frases absolutas sobre NVRAM, slots ou Import, mas do modelo real, dos logs, das mídias e da linha do tempo. Preservar essas fontes permite reconstruir o logical drive e então avançar para VMs, bancos e arquivos.
Referências utilizadas para validar este guia
- IBM: ServeRAID M5110 documentation
- IBM: ServeRAID M5210 documentation
- IBM: ServeRAID-M, WebBIOS e MegaRAID Storage Manager
- IBM: ServeRAID startup messages e DDD
- IBM: Modify location e Import configuration
- IBM: recuperação de single DDD
- IBM: múltiplos DDD e event log
- IBM: ServeRAID 8k, Auto Failover e drives usados
- Lenovo: IBM System x3650 M4 e ServeRAID M5110e
- Lenovo: System x3650 M5 e ServeRAID M1215/M5210
- Lenovo/IBM: aquisição do negócio x86 em 2014
- X-Ways: WinHex low-level data processing and RAID interpretation
