Um servidor HP ProLiant que não sobe, um volume que desaparece do sistema operacional ou um erro 1783 no POST colocam o administrador diante de uma decisão urgente — e cada escolha feita no console da controladora pode definir se os dados voltam ou se somem de vez. Este texto mostra como recuperar RAID HP Smart Array sem destruir as chances de êxito: quais sintomas exigem parada imediata, o que nunca executar na controladora e quando o rebuild interno deixa de ser uma opção segura.
O que aconteceu com seu servidor HP ProLiant: sintomas e o que eles realmente indicam
Servidores HP ProLiant com controladora Smart Array sinalizam falhas de forma padronizada, mas a interpretação correta de cada sintoma exige separar o que é alarme de disco do que é corrupção de metadados do array. Um volume que desaparece do sistema operacional, por exemplo, pode ter origem em um único disco com setores ilegíveis, em dois discos expulsos simultaneamente ou em uma controladora que perdeu a configuração armazenada em NVRAM. Cada cenário demanda uma conduta diferente — e a conduta errada nas primeiras horas é a principal causa de perda definitiva em RAID HP.
A Smart Array grava os metadados do array em cada disco membro e também na controladora. Quando o servidor liga, a controladora lê esses metadados, compara com a configuração salva e decide se o volume lógico pode ser apresentado ao sistema. Qualquer divergência entre o que está nos discos e o que está na NVRAM da controladora gera os sintomas que o administrador vê no POST, no iLO ou no Array Configuration Utility (ACU/SSA). Entender essa mecânica é o primeiro passo para agir sem destruir as chances de recuperação.
Array degradado, volume offline, RAW ou foreign configuration
Um array degradado significa que a controladora ainda entrega o volume lógico ao sistema operacional, mas um disco membro saiu do conjunto — seja por falha física, timeout de leitura ou expulsão preventiva. O servidor continua funcionando, porém sem redundância: se um segundo disco falhar antes do rebuild concluir, o volume inteiro colapsa. Em RAID 5, esse é o momento de maior risco estatístico, porque a leitura intensiva do rebuild sobrecarrega justamente os discos remanescentes, que já acumulam anos de uso.
Volume offline é o estágio seguinte: a controladora encerrou o acesso ao volume lógico. O sistema operacional pode exibi-lo como RAW, não inicializado ou simplesmente não listá-lo. Foreign configuration aparece quando os discos carregam metadados de uma controladora diferente da atual — comum após troca de placa-mãe, migração de discos para outro servidor ou substituição da Smart Array por outro modelo sem o procedimento de importação correta. Nesses três casos, o dado físico ainda pode estar íntegro nos pratos ou chips; o que se perdeu foi apenas a estrutura lógica que o apresenta ao sistema.
Erro 1783, cache FBWC/BBWC e alertas no iLO
O erro 1783 no POST do ProLiant indica falha na bateria ou no módulo de cache da controladora. Em controladoras mais antigas, o BBWC (battery-backed write cache) usa uma bateria física para preservar dados em cache durante queda de energia; nas gerações mais novas, o FBWC (flash-backed write cache) combina capacitor e memória flash para o mesmo fim. Quando a bateria ou o capacitor degrada, a controladora desativa o write cache e passa a operar em write-through, o que derruba drasticamente o desempenho — mas, mais grave, se houver queda de energia com cache sujo e sem proteção, transações gravadas no cache nunca chegam aos discos.
Esse cenário gera corrupção silenciosa de sistema de arquivos: o servidor liga, o volume aparece, mas diretórios somem, arquivos abrem com erro ou o filesystem entra em modo somente leitura. Os alertas no iLO (Integrated Lights-Out) registram esses eventos no Integrated Management Log (IML) com códigos como “cache module failure”, “battery failed” ou “logical drive status changed”. Levantar o IML completo antes de qualquer intervenção é essencial, porque ele documenta a sequência exata de eventos — informação que um laboratório usa para reconstruir a linha do tempo da falha.
Rebuild travado, disco em falha e bipes da controladora
Rebuild travado em 0%, 20% ou qualquer percentual intermediário indica que um dos discos-fonte não consegue mais entregar leituras estáveis. A controladora tenta reler o setor, aplica correção de erro e, se o tempo de resposta exceder o limite, expulsa o disco do array ou interrompe o rebuild. Forçar a reinicialização do rebuild nesse estado raramente resolve; o mais comum é agravar a degradação física do disco que já estava no limite.
Bipes da controladora durante o POST são raros em Smart Array, mas quando ocorrem sinalizam falha de hardware crítico — controladora não inicializada, cache com erro fatal ou ausência de todos os discos. Um disco com LED âmbar piscando é o sinal visual padrão de falha preditiva ou expulsão. Se dois ou mais discos acenderem âmbar no mesmo intervalo de horas, a hipótese de falha em lote (mesma data de fabricação, mesmo lote de firmware, backplane com problema) precisa ser considerada antes de qualquer tentativa de rebuild.
As primeiras horas após a falha: o que fazer e o que nunca fazer
As primeiras horas definem o desfecho da maioria dos casos de RAID HP. A urgência operacional pressiona o administrador a “tentar alguma coisa”, mas em recuperação de dados a ação errada converte um cenário recuperável em perda definitiva. A regra técnica é simples: se o volume lógico contém dados sem backup e a estrutura do array está comprometida, nenhuma operação de escrita deve ser executada sobre os discos originais.
O procedimento correto começa por desligar o servidor de forma controlada, documentar a configuração (nível de RAID, ordem dos discos, modelo da controladora, versão de firmware, logs do IML) e remover os discos identificando fisicamente a posição de cada um no backplane. A ordem física importa porque a reconstrução do array depende de saber qual disco ocupava qual slot — informação que se perde quando os discos são removidos sem etiquetagem.
Por que o rebuild e os softwares automáticos destroem as chances de recuperação
O rebuild de um array degradado escreve dados de paridade em todos os discos restantes. Se um dos discos “saudáveis” já contém setores ilegíveis não detectados, o rebuild força a leitura desses setores e pode expulsar o disco do conjunto — transformando um RAID 5 degradado em um RAID 5 com dois discos fora, estado em que a controladora não consegue mais apresentar o volume. É o mecanismo clássico de falha em cascata durante rebuild.
Ferramentas automáticas de “reparo” de RAID — que escaneiam os discos, tentam detectar a geometria do array e reescrever metadados — operam às cegas quando não conhecem a ordem exata dos discos nem o offset de dados daquela controladora específica. Uma gravação no lugar errado sobrescreve tabelas de alocação, superblocos ou o próprio mapa de paridade. O resultado é um array que nem a controladora original reconhece mais. A tentativa caseira é, nesses casos, a principal causa de perda definitiva.
Comandos e ações que alteram metadados da Smart Array
No console da Smart Array (SSA, ACU, hpssacli ou ssacli), alguns comandos são irreversíveis do ponto de vista dos metadados. A lista abaixo reúne as operações que jamais devem ser executadas sobre discos com dados a recuperar:
- Create logical drive — sobrescreve metadados e pode zerar o mapa do array
- Delete logical drive — remove a definição do volume sem apagar os dados, mas destrói a referência lógica
- Re-enable failed logical drive — força a controladora a reativar um volume com estrutura inconsistente
- Transform ou migrate RAID level — reescreve paridade e redistribui blocos entre os discos
- Clear configuration — apaga a configuração da NVRAM da controladora
- Format ou initialize logical drive — grava zeros ou estrutura nova sobre o volume
Também entra na lista negra a atualização de firmware da controladora ou dos discos com o array em estado de falha. Um update de firmware que falha no meio pode deixar a controladora inoperante e, em modelos com cache sujo, descartar dados que ainda não foram gravados nos discos. A atualização de firmware deve ser feita apenas com o array íntegro, com backup validado e, idealmente, com os discos originais clonados.
Como o Smart Array organiza os dados: RAID, unidade lógica e sistema de arquivos
A Smart Array insere uma camada de abstração entre os discos físicos e o sistema operacional. Os discos formam um array (ou vários), e sobre cada array são criadas uma ou mais unidades lógicas (logical drives). O sistema operacional enxerga apenas as unidades lógicas como discos; não tem acesso direto aos discos físicos. Essa camada é o que permite RAID 5, RAID 6, RAID 10, RAID 50 e RAID 60 — e é também o que complica a recuperação quando a própria camada quebra.
Cada controladora grava os metadados do array em um formato proprietário, com variações entre gerações. A P410, por exemplo, organiza os metadados de forma diferente da P840ar ou da P408i. O offset onde começam os dados, o tamanho do stripe, a ordem de distribuição da paridade e o formato do superbloco mudam entre famílias. Por isso, recuperar RAID HP exige conhecer a fundo a geração específica da controladora — não basta saber que “era RAID 5”.
Geração do ProLiant, família da controladora e arquitetura do array
Servidores ProLiant das gerações G6, G7, Gen8, Gen9 e Gen10 utilizam controladoras de famílias distintas, com implicações diretas na recuperação. A P410/P410i equipa G6 e G7; a P420i vem no Gen8; a P440ar no Gen9; e a série P408i/P816i/P840ar no Gen10. Cada família tem firmware próprio, formato de metadados próprio e suporte a recursos diferentes — a P408i, por exemplo, introduz o Smart Array SR (SmartRAID) com cache híbrido e gerenciamento diferente do legado.
Levantar a geração exata do servidor, o modelo da controladora, a versão de firmware e o nível de RAID antes de qualquer intervenção é um passo crítico. Essas quatro informações, somadas à ordem física dos discos, formam o conjunto mínimo que um laboratório precisa para iniciar a reconstrução virtual. Sem elas, o diagnóstico parte do zero e consome horas de análise que poderiam ser evitadas.
Onde os arquivos realmente residem e por que o RAID não é backup
Em um RAID 5 com quatro discos, um arquivo de 1 MB não reside inteiro em um único disco: ele é dividido em blocos de stripe distribuídos entre três discos, com o quarto bloco armazenando a paridade dos três anteriores. Para reconstruir o arquivo, é preciso ler blocos de todos os discos na ordem correta. Se um disco falha, a paridade permite recalcular o bloco ausente — é assim que o RAID sobrevive a uma falha simples.
Mas essa matemática tem limite: com dois discos fora em RAID 5, não há paridade suficiente para recalcular todos os blocos ausentes. E mesmo com um disco fora, se outro disco contém setores ilegíveis justamente nos blocos necessários para o recálculo, o rebuild falha. O RAID protege contra falha de hardware, não contra corrupção lógica, exclusão acidental, ransomware ou falha da própria controladora. Backup continua sendo a única proteção real contra perda de dados.
Cenários de falha e o que cada um exige
Cada cenário de falha em Smart Array tem um protocolo de recuperação distinto. O que funciona para um RAID 5 com dois discos físicos falhados não se aplica a uma controladora queimada com discos íntegros, e vice-versa. A primeira etapa de qualquer recuperação séria é classificar corretamente o cenário — e essa classificação depende de diagnóstico, não de suposição.
RAID 5 ou RAID 6 com dois discos falhados
Em RAID 5, dois discos fisicamente falhados ultrapassam a tolerância matemática do array: a controladora não consegue mais apresentar o volume, e nenhum software de “reparo” consegue reconstruir os dados apenas com os discos restantes. A recuperação ainda é possível se um dos discos “falhados” tiver falha parcial — por exemplo, cabeçotes instáveis que leem alguns setores e falham em outros. Nesse caso, o disco é estabilizado em laboratório e lido bloco a bloco, e a paridade dos demais discos completa as lacunas.
Em RAID 6, a tolerância é de dois discos: com dois fora, o array ainda funciona em modo degradado. A recuperação se torna crítica quando um terceiro disco começa a falhar ou quando o rebuild dos dois primeiros é interrompido por erro de leitura em um disco remanescente. RAID 6 com três discos fora exige o mesmo tratamento de estabilização e leitura parcial que o RAID 5 com dois fora.
Falha física da controladora Smart Array (P410, P420i, P408i, P816i, P840ar)
Quando a controladora queima — por surto elétrico, falha de componente ou superaquecimento —, os discos geralmente permanecem íntegros, mas o acesso ao array se perde porque a camada de abstração desapareceu. Substituir a controladora por outro modelo, mesmo que da mesma família, nem sempre resolve: diferenças de firmware ou de revisão de hardware podem fazer a nova controladora interpretar os metadados de forma ligeiramente diferente, e a importação da configuração estrangeira pode falhar ou corromper o array.
O caminho seguro é a reconstrução virtual: os discos são lidos em laboratório e o array é remontado em software especializado que emula o comportamento da controladora original. A queima da controladora não significa perda dos dados — desde que nenhuma tentativa de recriação do array tenha sido executada sobre os discos originais.
Corrupção lógica com discos fisicamente íntegros
Quando todos os discos passam nos testes SMART e a controladora reconhece o array, mas o volume aparece RAW, com filesystem corrompido ou com diretórios vazios, o problema está na camada lógica — sistema de arquivos, tabela de partição ou metadados do filesystem. As causas incluem queda de energia com cache sujo, desligamento abrupto durante gravação intensa, bug de firmware ou corrupção progressiva por setores defeituosos realocados tardiamente.
Esse é o cenário em que a tentativa de “reparar” com ferramentas automáticas é mais tentadora e mais perigosa. Um chkdsk ou fsck executado sobre um volume com estrutura corrompida pode “consertar” a estrutura apagando referências a arquivos inteiros — transformando corrupção parcial em perda completa. A recuperação correta monta o filesystem em modo somente leitura, a partir de uma imagem dos discos, e extrai os dados sem nunca gravar sobre o original.
VMs offline em VMware ESXi ou Hyper-V após colapso do datastore
Servidores ProLiant frequentemente hospedam VMware ESXi ou Hyper-V com datastores sobre volumes Smart Array. Quando o array colapsa, as VMs somem junto com o datastore — e a perda envolve não apenas arquivos, mas máquinas inteiras com sistemas operacionais, bancos de dados e aplicações. A recuperação nesse cenário precisa ir além do array: é necessário reconstruir o datastore VMFS ou o volume NTFS/ReFS e, em seguida, validar a integridade dos discos virtuais (VMDK ou VHDX).
Um VMDK corrompido dentro de um datastore recuperado pode impedir a inicialização da VM mesmo com o array reconstruído. Por isso, a validação precisa incluir a montagem dos discos virtuais e a checagem da estrutura interna de cada VM — tarefa que exige conhecimento tanto de RAID quanto de virtualização. A parada de produção nesses casos é o custo mais pesado, e a pressa em religar o servidor sem validação costuma agravar o prejuízo.
Como funciona a recuperação em laboratório: da imagem dos discos à validação dos dados
A recuperação profissional de RAID HP segue um protocolo em três fases: imagem, reconstrução e validação. O princípio que rege todo o processo é a não alteração dos discos originais — nenhuma operação de escrita é executada sobre a mídia de origem em nenhum momento. Todo o trabalho acontece sobre cópias setor a setor, preservando os originais como evidência e como fonte de novas leituras se algo falhar.
Identificação das fontes e leitura bloco a bloco sem alterar o original
Cada disco é identificado, etiquetado e submetido a leitura bloco a bloco em equipamento que controla o acesso à mídia sem depender da controladora original. Discos com setores ilegíveis passam por leitura assistida por hardware, que ajusta parâmetros de leitura, temperatura e recuperação de erro para extrair o máximo de dados possível. Os setores que não respondem são mapeados e registrados para tratamento posterior via paridade.
A leitura bloco a bloco gera uma imagem forense de cada disco — um arquivo que reproduz fielmente o conteúdo original, incluindo setores defeituosos marcados. É sobre essas imagens que a reconstrução acontece, nunca sobre os discos físicos. Esse procedimento também permite reler setores problemáticos múltiplas vezes sem desgastar ainda mais a mídia original.
Reconstrução virtual do array e interpretação do armazenamento
Com as imagens prontas, o laboratório reconstrói o array em ambiente virtual, emulando a controladora original: mesmo nível de RAID, mesmo tamanho de stripe, mesmo offset de dados e mesma ordem de distribuição de paridade. A reconstrução virtual permite testar diferentes hipóteses de configuração sem risco — se uma combinação de parâmetros não produz um filesystem coerente, outra é testada, até que a estrutura lógica apareça.
Uma vez reconstruído o volume, o laboratório interpreta o armazenamento: tabela de partição, sistema de arquivos, diretórios, permissões e arquivos. Em casos de corrupção de filesystem, a extração é feita por parsing da estrutura — lendo as tabelas de alocação e localizando os arquivos diretamente, sem depender da montagem normal do filesystem. Em casos de RAID 5 com disco parcialmente ilegível, a paridade dos demais discos completa os blocos ausentes durante a reconstrução.
Validação dos dados antes da entrega
Antes de devolver os dados, o laboratório valida a integridade do que foi recuperado: abre amostras de arquivos de cada tipo relevante, verifica a estrutura de diretórios, checa bancos de dados e monta VMs para confirmar que inicializam. A validação é o que separa “recuperamos 200 GB de dados” de “recuperamos 200 GB de dados utilizáveis” — volume recuperado sem validação pode conter arquivos corrompidos que só serão descobertos quando o cliente tentar abri-los.
O cliente recebe um relatório com a lista do que foi recuperado e, quando solicitado, pode validar amostras antes da entrega final. Em ambientes corporativos, essa etapa pode incluir a montagem do volume recuperado em um servidor de teste para que a equipe de TI confirme a integridade antes de religar o ambiente em produção.
O que define o custo de uma recuperação de servidor HP ProLiant
O custo de uma recuperação de RAID HP não é tabelado por gigabyte; ele é definido por um conjunto de variáveis técnicas que só o diagnóstico revela. Quanto mais cedo o caso chega ao laboratório — antes de tentativas de rebuild, antes de softwares automáticos, antes de regravações —, menor tende a ser a complexidade e, portanto, o custo. Cada intervenção mal sucedida sobre os discos originais adiciona camadas de dano que precisam ser revertidas.
Os fatores que pesam no custo incluem:
- Número de discos — mais discos significam mais leitura, mais imagens e mais tempo de reconstrução
- Estado físico dos discos — discos com falha de cabeçote exigem troca de componentes em sala limpa
- Nível de RAID — RAID 50 e 60 são mais complexos que RAID 5 simples
- Geração da controladora — famílias mais antigas ou menos documentadas exigem mais engenharia reversa
- Corrupção lógica adicional — filesystem danificado, VMs corrompidas ou criptografia aumentam o escopo
- Urgência — prazos reduzidos podem demandar priorização de recursos de laboratório
O diagnóstico costuma ser a etapa que define o orçamento final, porque só ele revela o estado real de cada disco e a complexidade da reconstrução. Um orçamento fechado sem diagnóstico — ou um valor genérico dado por telefone — é sinal de que o prestador não sabe o que vai enfrentar.
Como escolher o laboratório e o que perguntar antes de contratar
A escolha do laboratório define o desfecho do caso tanto quanto a condição dos discos. Um laboratório sem experiência em controladoras HP Smart Array pode destruir um array que um especialista recuperaria em horas. Antes de enviar os discos, o cliente deve fazer perguntas objetivas e avaliar as respostas com critério técnico.
Diagnóstico, NDA, SLA e política de cobrança por resultado
O laboratório deve oferecer diagnóstico técnico antes de qualquer intervenção, com prazo definido e relatório do que foi encontrado. O NDA (acordo de confidencialidade) deve ser padrão — não um diferencial — e cobrir tanto os dados quanto as informações sobre a infraestrutura do cliente. O SLA precisa especificar prazos de diagnóstico, de recuperação e de entrega, com cláusulas claras para casos urgentes.
A política de cobrança por resultado é o ponto mais sensível. O modelo mais transparente é aquele em que o cliente paga apenas se os dados forem recuperados — ou paga um valor de diagnóstico e um valor de recuperação apenas sobre o que for efetivamente entregue. Desconfie de propostas que cobram o valor integral antecipadamente sem diagnóstico, ou que prometem recuperação garantida: nenhum laboratório sério garante 100% de sucesso antes de ver os discos.
Sinais de alerta em propostas de recuperação de RAID
Alguns sinais indicam que a proposta não vem de um especialista em RAID HP. A lista abaixo reúne os alertas mais comuns:
- Orçamento sem diagnóstico — valor fechado sem ver os discos ou sem perguntar o modelo da controladora
- Promessa de sucesso garantido — nenhum caso é recuperável até que a leitura dos discos confirme
- Uso de softwares genéricos — ferramentas automáticas de “reparo” de RAID como solução declarada
- Sem NDA ou sem sala limpa — abertura de disco fora de ambiente controlado condena mídias com falha física
- Pressão para fechar rápido — urgência artificial para impedir que o cliente compare propostas
- Sem relatório de validação — entrega de dados sem lista do que foi recuperado ou sem amostras validadas
Um laboratório que faz as perguntas certas — geração do ProLiant, modelo da controladora, versão de firmware, nível de RAID, ordem dos discos, logs do iLO — demonstra que entende a arquitetura Smart Array antes mesmo de receber a mídia. A ausência dessas perguntas é o primeiro sinal de que o prestador trata RAID HP como se fosse um HD comum.
Perguntas frequentes sobre recuperação de RAID HP Smart Array
As dúvidas mais comuns de administradores e gestores de TI diante de um servidor ProLiant com array falhado envolvem prazos, possibilidades técnicas e riscos de cada decisão. As respostas abaixo resumem o que a prática de recuperação em laboratório mostra para cada cenário.
É possível recuperar RAID 5 com dois discos falhados?
Depende do estado real de cada disco. Se os dois discos “falhados” estiverem fisicamente mortos — sem leitura possível —, o RAID 5 não tem paridade suficiente para reconstruir os dados, e a recuperação é inviável. Mas se um dos discos tiver falha parcial, com leitura possível em laboratório, a paridade dos discos remanescentes pode completar os blocos ilegíveis. O diagnóstico é o único caminho para saber em qual caso o cliente está.
A Smart Array queimou: os dados estão perdidos?
Não necessariamente. A queima da controladora não apaga os dados dos discos; ela apenas remove a camada que os apresentava ao sistema. Com os discos íntegros, a reconstrução virtual em laboratório emula a controladora original e remonta o array. O risco está na substituição da controladora por outro modelo seguida de tentativa de importação de configuração — operação que pode sobrescrever metadados e comprometer a recuperação.
Posso substituir a controladora por outro modelo sem diagnóstico?
Não é recomendado. Controladoras de famílias diferentes — ou mesmo da mesma família com firmware distinto — interpretam os metadados de forma ligeiramente diferente. A importação de configuração estrangeira pode falhar, e a tentativa de “forçar” o reconhecimento pode executar operações de escrita sobre os discos. O caminho seguro é clonar os discos antes de qualquer substituição de hardware, preservando a possibilidade de reconstrução virtual.
É possível recuperar remotamente, sem enviar os discos?
Para casos puramente lógicos — array reconhecido, filesystem corrompido, discos íntegros —, alguns laboratórios oferecem acesso remoto controlado para diagnóstico e extração. Mas quando há falha física de disco, falha de controladora ou necessidade de leitura bloco a bloco com hardware especializado, o envio físico é inevitável. O envio seguro, com embalagem antiestática e transporte adequado, é procedimento padrão em recuperação profissional.
Quanto tempo demora a recuperação de um servidor ProLiant?
O prazo varia conforme o cenário. Casos lógicos simples podem ser resolvidos em poucos dias; casos com falha física de múltiplos discos, necessidade de troca de cabeçotes em sala limpa e reconstrução complexa podem levar semanas. O diagnóstico inicial — que costuma levar de um a três dias úteis — é o marco que define o prazo realista de recuperação e deve ser solicitado antes de qualquer compromisso de entrega.
