Quando o volume de um servidor PowerEdge deixa de aparecer no sistema, o aviso no iDRAC ou no BIOS da controladora costuma vir acompanhado de uma decisão urgente: tentar importar, reconstruir ou reiniciar o arranjo. É nesse momento que muitas empresas perdem dados que ainda estavam legíveis nos discos. Este texto mostra como agir para recuperar RAID Dell PERC sem destruir evidências, quais alertas exigem parada imediata e como escolher um laboratório com cadeia de custódia e sigilo.
O que significa recuperar um RAID Dell PERC
Recuperar um RAID Dell PERC envolve reconstruir o acesso aos dados de um arranjo gerenciado por controladora PowerEdge RAID Controller quando o volume deixa de ser apresentado ao sistema operacional, entra em estado degradado ou é marcado como failed. A controladora PERC — presente em modelos como H310, H710, H730, H740 e H750 — mantém metadados próprios sobre a geometria do arranjo, a ordem dos discos e o estado de cada membro. Quando essa estrutura se corrompe, o sistema operacional não enxerga mais o disco virtual, mesmo que os discos físicos ainda contenham setores legíveis.
O trabalho de recuperação não começa pelo sistema de arquivos. Ele começa pela leitura controlada dos discos membros, pela interpretação dos metadados da controladora e pela remontagem do arranjo em ambiente isolado. Tentativas de acessar a partição diretamente, reinstalar o driver da PERC ou recriar o volume pela interface da controladora costumam sobrescrever justamente as estruturas que permitiriam a remontagem.
Disco físico, disco virtual e partição: camadas que não devem ser confundidas
Um servidor PowerEdge com PERC apresenta três camadas distintas. O disco físico é a unidade SAS ou SATA instalada na baia, identificada por um número de slot e por um serial. O disco virtual (VD, de virtual disk) é o arranjo lógico que a controladora expõe ao sistema — um RAID 5 com quatro membros, por exemplo, aparece ao Windows ou ao VMware como um único volume contínuo. A partição é a estrutura criada dentro desse disco virtual, contendo NTFS, ReFS, VMFS ou outro sistema de arquivos.
Quando o VD fica offline, a partição deixa de existir para o sistema operacional, mas os dados gravados nos discos físicos não desaparecem na mesma hora. O conteúdo permanece distribuído entre os membros, com paridade ou espelhamento conforme o nível do RAID. A recuperação exige tratar cada camada na ordem correta: primeiro estabilizar e clonar os discos físicos, depois reconstruir o disco virtual com os parâmetros originais e só então interpretar a partição e o sistema de arquivos.
Quando a recuperação é lógica e quando exige leitura dos discos fora do servidor
Há dois cenários com tratamentos opostos. A recuperação lógica pura ocorre quando a controladora ainda monta o VD, o sistema operacional enxerga o volume, mas arquivos foram apagados, o sistema de arquivos está corrompido ou a partição perdeu a tabela. Nesse caso, o arranjo está íntegro e o problema está na camada de arquivos — o trabalho pode ser feito com o volume online ou com imagem do VD.
A situação mais comum em chamados de RAID Dell PERC, porém, é outra: o VD não monta, a controladora lista discos como foreign ou o arranjo entra em failed. Aí a leitura precisa ser feita disco a disco, fora do servidor, com bloqueio de escrita e clonagem bloco a bloco. Ferramentas de recuperação executadas sobre o VD montado não alcançam esse cenário; elas dependem de um volume visível para operar. Leitura direta dos membros, interpretação de metadados e remontagem em ambiente controlado são o caminho técnico quando a própria PERC perdeu a capacidade de apresentar o arranjo.
Os alertas da PERC e do iDRAC e o que cada um realmente indica
Os servidores Dell expõem o estado do RAID por dois caminhos: o BIOS da controladora, acessível durante o POST com Ctrl+R, e o iDRAC, interface de gerenciamento remoto que registra eventos no Lifecycle Log. Os alertas mais frequentes em chamados de recuperação são volume offline, degraded, failed, foreign configuration e preserved cache. Cada um aponta para uma camada diferente do problema, e a leitura apressada desses estados leva a ações destrutivas.
Volume offline, degradado ou failed: o que o estado do VD não diz sobre os arquivos
Degraded indica que o arranjo perdeu tolerância — em um RAID 5, um disco saiu do conjunto, mas o VD continua apresentando dados, agora sem redundância. Offline significa que a controladora deixou de montar o volume, geralmente por múltiplos membros ausentes ou por metadados inconsistentes. Failed é o estado em que o VD não pode mais ser acessado como unidade lógica. Nenhum desses três estados informa se os arquivos estão íntegros; informam apenas o que a controladora consegue montar.
Um VD em failed pode ter todos os discos fisicamente saudáveis e com setores legíveis — a falha pode estar em um cabo, em um backplane, em firmware corrompido da PERC ou em inconsistência de metadados após queda de energia. Por isso, o estado exibido no iDRAC não é diagnóstico de perda de dados. É o ponto de partida para decidir parar de mexer no servidor e registrar o cenário antes de qualquer intervenção.
Foreign Configuration: o que o aviso informa e por que Import, Clear e Initialize têm efeitos diferentes
Foreign configuration aparece quando a controladora detecta metadados de RAID que não foram criados por ela — típico após troca de PERC, migração de discos entre servidores ou falha de comunicação com o backplane. A tela da controladora oferece três opções com consequências radicalmente diferentes: Import, Clear e Initialize. Import tenta adotar os metadados existentes e montar o VD; Clear apaga a configuração foreign dos discos; Initialize grava uma nova estrutura de RAID por cima dos dados.
Import pode funcionar quando a geometria do arranjo está íntegra e a controladora nova é compatível com o nível de RAID original. Clear e Initialize são destrutivos: o primeiro remove a referência ao arranjo, o segundo sobrescreve setores iniciais dos discos e inviabiliza a recuperação sem clonagem prévia. Em qualquer cenário com foreign configuration, a sequência segura é clonar os discos antes de testar o Import — se o Import corromper os metadados, os clones preservam o estado original.
Preserved Cache e dados pendentes: por que a controladora original deve ser preservada
Controladoras PERC com cache em bateria ou capacitor mantêm dados pendentes de escrita que ainda não foram gravados nos discos. Quando a PERC detecta que o arranjo não está íntegro, ela preserva esse cache e exibe o alerta preserved cache. Esses dados podem conter transações de banco de dados, metadados de sistema de arquivos ou trechos de arquivos que existem apenas na memória da controladora.
Descartar a PERC original, zerar o cache ou trocar a controladora antes de drenar esses dados pendentes elimina informação que não está em nenhum disco. Em bancos de dados e datastores VMware, a ausência desses blocos pode tornar o volume logicamente inconsistente mesmo depois de uma remontagem perfeita do RAID. A controladora original precisa ser preservada junto com os discos até que o cache pendente seja analisado e incorporado à imagem do arranjo.
Rebuild travado: por que o percentual exibido não define a causa
O rebuild é o processo de reconstrução da redundância quando um disco novo entra no arranjo. O percentual exibido pela PERC mede o progresso da cópia de paridade ou espelhamento para o novo membro — não indica a causa de uma eventual parada. Um rebuild travado em 37%, por exemplo, pode ter sido interrompido por setores ilegíveis no disco de origem, por falha no disco substituto, por timeout no backplane ou por reinício do servidor.
Reiniciar o rebuild repetidamente sem investigar a causa submete os discos originais a leituras prolongadas e aumenta o risco de degradação física. Quando o rebuild trava mais de uma vez, a recomendação técnica é interromper novas tentativas, registrar o Lifecycle Log e avaliar a saúde de cada disco fora do servidor. O percentual é uma métrica de andamento, não um diagnóstico.
O que fazer nas primeiras horas após a falha
As primeiras horas definem a recuperabilidade de um RAID Dell PERC. Cada reinicialização, tentativa de import ou rebuild forçado grava metadados novos sobre os originais e consome vida útil dos discos que podem estar com degradação física. A sequência recomendada prioriza documentação e estabilização antes de qualquer ação corretiva.
Ações que costumam destruir dados: forçar rebuild, inicializar volume e trocar a PERC sem análise
Três ações aparecem com frequência em chamados abertos após tentativas locais frustradas. A primeira é forçar rebuild com o arranjo em estado inconsistente — a controladora passa a gravar paridade calculada a partir de um conjunto que pode estar com discos fora de ordem ou com setores corrompidos, contaminando a redundância. A segunda é inicializar o volume, que grava uma nova estrutura de RAID e apaga a referência ao arranjo original. A terceira é trocar a PERC por outra de modelo diferente e aceitar a opção Clear na tela de foreign configuration.
- Rebuild forçado com membros ausentes ou fora de ordem
- Initialize ou Clear em tela de foreign configuration
- Troca de PERC sem clonagem prévia dos discos
- Atualização de firmware da controladora com o VD offline
- Recriação manual do VD com parâmetros estimados
Como registrar baias, séries, volumes e a sequência de eventos do Lifecycle Log
Antes de desligar ou mexer no servidor, registre o mapa físico do arranjo: número da baia, serial e modelo de cada disco, tamanho em setores e posição no backplane. Anote também o modelo exato da PERC, a versão de firmware, o nível de RAID, o tamanho do stripe e o estado de cada VD. Esses parâmetros são os mesmos que a remontagem em laboratório precisará confirmar nos metadados DDF.
Exporte o Lifecycle Log completo pelo iDRAC — ele contém a sequência temporal de eventos: qual disco caiu primeiro, se houve queda de energia, se a controladora reportou erro de cache, se o rebuild iniciou e parou. Essa cronologia permite distinguir falha súbita de múltiplos discos de falha progressiva com rebuild malsucedido, o que muda a estratégia de recuperação. Fotos da tela da controladora e do iDRAC complementam o registro.
O que perguntar antes de aceitar qualquer procedimento no servidor
Se a decisão envolver equipe interna ou prestador de suporte, algumas perguntas separam procedimento seguro de risco. A principal é se os discos serão clonados antes de qualquer escrita. A segunda é qual ação exata será executada na tela da controladora — import, clear, initialize ou rebuild — e qual o efeito dela sobre os metadados. A terceira é se a controladora original será preservada com o cache intacto.
- Os discos serão clonados antes de qualquer escrita?
- Qual ação será executada na controladora e qual o efeito nos metadados?
- A PERC original e o cache pendente serão preservados?
- Há registro do Lifecycle Log antes da intervenção?
- Quem assume a responsabilidade se o procedimento inviabilizar a recuperação?
Como é feita a recuperação de um RAID PERC na prática
A recuperação especializada segue uma ordem rígida: estabilização dos discos, clonagem bloco a bloco, interpretação dos metadados da controladora, remontagem do arranjo em ambiente controlado e validação do sistema de arquivos. Nenhuma etapa grava nos discos originais. Todo o trabalho de reconstrução ocorre sobre imagens, o que permite repetir tentativas sem consumir a mídia original.
Imagem bloco a bloco dos discos e reconstrução do arranjo em ambiente controlado
Cada disco membro é conectado a um equipamento de imagem com bloqueio de escrita e copiado setor a setor para mídia de trabalho. Discos com setores ilegíveis passam por leitura controlada, com registro dos blocos não lidos. A imagem resultante preserva a posição física de cada setor, condição indispensável para a remontagem, já que o RAID distribui dados e paridade em posições calculadas a partir do stripe size.
A reconstrução do arranjo é feita em software especializado que interpreta os metadados DDF presentes nos discos, identifica a ordem dos membros, o nível do RAID, o tamanho do stripe e o offset inicial dos dados. O arranjo é então montado virtualmente sobre as imagens, sem tocar nos discos originais. Só depois que o VD remontado apresenta estrutura coerente é que se avança para o sistema de arquivos.
Metadados DDF e parâmetros do RAID: por que a ordem e o tamanho de stripe importam
As controladoras PERC usam o formato de metadados DDF (Disk Data Format) para registrar a configuração do arranjo em cada disco membro. Esses metadados guardam o número de discos, a ordem deles no arranjo, o nível de RAID, o tamanho do stripe, o offset de dados e o estado de cada membro. Quando a controladora monta o VD, ela lê esses campos e calcula onde cada bloco de dado e de paridade está.
Se a ordem dos discos for invertida ou o stripe size informado for diferente do original, a remontagem produz um volume contínuo, porém com dados embaralhados — o sistema de arquivos não abre, e arquivos aparecem corrompidos. A recuperação confirma esses parâmetros por validação cruzada: testa combinações plausíveis e verifica qual delas gera estruturas reconhecíveis de NTFS, ReFS ou VMFS. A ordem correta não é um palpite; é uma conclusão derivada dos metadados e validada pelo sistema de arquivos.
Validação dos dados e entrega em mídia nova
Depois da remontagem, a etapa de validação verifica a integridade do sistema de arquivos, a consistência de diretórios e a abertura de amostras de arquivos críticos — bancos de dados, máquinas virtuais, documentos. Em datastores VMware, a validação inclui a montagem do VMFS e a verificação dos descritores das VMs. Em bancos de dados, inclui a checagem de consistência interna das tabelas e logs de transação.
A entrega é feita em mídia nova, nunca nos discos originais. O cliente recebe os dados copiados para discos ou storage de destino, com relatório do que foi recuperado e do que eventualmente ficou comprometido. A mídia original permanece preservada por um período acordado, permitindo auditoria ou nova tentativa caso o cliente identifique arquivos ausentes após a entrega.
Casos comuns em servidores PowerEdge
Os cenários de falha em RAID Dell PERC seguem padrões recorrentes, ligados a energia, substituição de hardware e virtualização. Reconhecer o padrão ajuda a evitar a ação errada nas primeiras horas.
Queda de energia com múltiplos discos offline
Quedas de energia sem nobreak adequado interrompem escritas no meio da operação e podem derrubar vários discos simultaneamente. A controladora, ao reiniciar, encontra metadados inconsistentes e membros ausentes, marcando o VD como offline ou failed. O cache pendente, se houver, fica preservado, mas o arranjo não monta.
Nesse cenário, os discos raramente falharam fisicamente ao mesmo tempo — a causa é a interrupção elétrica, não defeito mecânico simultâneo. A recuperação passa por clonar todos os membros, incorporar o cache pendente da PERC, reconciliar os metadados e remontar o arranjo. Forçar rebuild nesse estado grava paridade calculada a partir de um conjunto inconsistente e pode corromper dados que estavam íntegros.
PERC substituída e volume não reconhecido
A troca da controladora — por falha da original ou upgrade de modelo — gera o alerta de foreign configuration. Se a equipe local escolheu Clear ou Initialize, os metadados originais foram removidos e o VD não monta mais. Se escolheu Import e o arranjo não subiu, os metadados podem estar parcialmente corrompidos ou a controladora nova não é compatível com a geometria original.
A recuperação nesse caso depende dos metadados DDF remanescentes nos discos e, quando a PERC original ainda existe, do cache preservado nela. A ordem dos discos e o stripe size são reconstruídos a partir do que sobrou nos membros, com validação pelo sistema de arquivos. A controladora nova não precisa ser usada na remontagem — o trabalho ocorre em ambiente controlado, sobre as imagens.
Datastore VMware ESXi inacessível após falha do arranjo
Quando um servidor ESXi perde o acesso ao datastore hospedado em RAID PERC, todas as VMs do arranjo ficam inacessíveis de uma vez. O sintoma no vSphere é datastore desconectado ou inacessível, e as VMs aparecem como invalid ou unknown. A causa está na camada de RAID, não no VMFS — o sistema de arquivos do datastore está íntegro, mas o volume que o hospedava não monta.
A recuperação remonta o arranjo e, em seguida, monta o VMFS sobre o VD reconstruído para extrair os discos virtuais. A validação inclui abrir cada VMDK e verificar a integridade do sistema de arquivos interno de cada máquina virtual. Em casos de falha elétrica com danos em múltiplos componentes, a clonagem dos discos precisa tratar setores ilegíveis antes de qualquer tentativa de montagem.
O que define o custo e o prazo de uma recuperação de RAID Dell PERC
O custo de uma recuperação de RAID Dell PERC é definido por fatores técnicos mensuráveis, não por tabela fixa. O primeiro fator é o número de discos do arranjo e a capacidade total — arranjos com seis ou oito membros exigem mais tempo de imagem e mais capacidade de armazenamento de trabalho. O segundo é o estado físico dos discos: setores ilegíveis, degradação de cabeças ou firmware instável aumentam o tempo de leitura controlada e a complexidade do caso.
O terceiro fator é o nível do RAID e a presença de cache pendente. RAID 5 e RAID 6 exigem cálculo de paridade e validação cruzada de parâmetros; RAID 10 e RAID 1 são mais diretos na remontagem. Cache pendente preservado adiciona uma etapa de drenagem e incorporação. O quarto fator é a complexidade da camada lógica: um datastore VMware com dezenas de VMs e bancos de dados exige validação mais extensa do que um volume NTFS com arquivos de escritório.
- Número de discos e capacidade total do arranjo
- Estado físico de cada membro e volume de setores ilegíveis
- Nível do RAID e presença de cache pendente na PERC
- Complexidade do sistema de arquivos e da carga de trabalho
- Urgência e necessidade de atendimento prioritário
O prazo segue a mesma lógica. Casos com múltiplos discos degradados, cache pendente e datastores corporativos levam mais tempo, porque a leitura controlada de setores problemáticos é lenta por natureza e a validação de bancos de dados e VMs exige etapas adicionais. O diagnóstico inicial — com clonagem e análise dos metadados — é o que permite estimar prazo com base em evidência, não em suposição.
Como escolher um laboratório de recuperação de RAID Dell
A escolha do laboratório define a probabilidade de sucesso e a segurança jurídica do processo. Empresas com dados críticos devem avaliar critérios objetivos antes de enviar discos ou servidor, porque o primeiro laboratório a tocar na mídia condiciona o que os próximos conseguirão fazer.
Perguntas que separam diagnóstico real de tentativa por software
Um laboratório que trabalha com RAID Dell PERC precisa responder com precisão sobre o processo, não com promessa de resultado. Pergunte se os discos serão clonados antes de qualquer escrita, se a remontagem é feita sobre imagens e se a PERC original será analisada junto com o cache. Pergunte também qual a experiência com metadados DDF e com os níveis de RAID usados no seu arranjo — RAID 50 e RAID 60, por exemplo, exigem domínio de arranjos aninhados que nem todo software de recuperação trata bem.
- Os discos originais são clonados antes de qualquer escrita?
- A remontagem é feita sobre imagens, não sobre a mídia original?
- O laboratório interpreta metadados DDF e arranjos aninhados como RAID 50 e 60?
- Há estrutura para tratar discos com setores ilegíveis e degradação física?
- O diagnóstico inicial identifica a causa antes de propor procedimento?
Confidencialidade, cadeia de custódia e política em caso de insucesso
Dados corporativos em RAID envolvem informações de clientes, registros contábeis, prontuários ou segredos industriais. O laboratório precisa oferecer acordo de confidencialidade formal e registrar a cadeia de custódia: quem recebeu a mídia, em que estado, o que foi feito em cada etapa e como os dados foram devolvidos. Esse registro é o que permite auditoria posterior e protege a empresa em caso de incidente.
A política em caso de insucesso precisa ser clara antes do envio. Como o próprio setor trabalha com taxa de êxito em casos viáveis — e não com garantia universal —, o contrato deve prever o que acontece se o diagnóstico concluir que os dados não são recuperáveis: se há cobrança pelo diagnóstico, se a mídia é devolvida sem custo adicional e se o cliente recebe relatório técnico do que foi tentado. Transparência sobre a impossibilidade de garantir resultado é sinal de maturidade técnica, não de fraqueza. A mesma lógica vale para políticas de cobrança condicionada à entrega, que precisam ser lidas com atenção aos critérios de viabilidade.
Perguntas frequentes sobre recuperar RAID Dell PERC
Dois discos falharam no meu PowerEdge: perdi tudo?
Não necessariamente. Em RAID 5, a falha simultânea de dois discos derruba o VD, mas os dados dos demais membros e parte dos membros falhos podem estar íntegros. A perda total só se confirma após leitura controlada de todos os discos e tentativa de remontagem. Em RAID 6, dois discos falhos ainda estão dentro da tolerância do arranjo — o VD deveria continuar acessível, e se não está, há outro fator envolvido, como metadados corrompidos ou terceiro disco com setores ilegíveis. Em RAID 10, a falha de dois discos só derruba o volume se ambos pertencerem ao mesmo par espelhado.
Posso trocar o disco de baia ou substituir a controladora?
Trocar o disco de baia em um arranjo degradado é procedimento previsto, mas deve ser feito com o disco substituto íntegro e com o rebuild acompanhado. Trocar a controladora é mais arriscado: se a PERC nova não reconhecer os metadados, a tela de foreign configuration vai oferecer opções destrutivas. Antes de substituir a controladora, clone os discos e preserve a PERC original com o cache. A troca por si só não apaga dados, mas as opções escolhidas na tela seguinte podem apagar.
Preciso enviar o servidor inteiro ou apenas os discos?
Na maioria dos casos, os discos e a controladora original são suficientes. O backplane e o restante do servidor não participam da remontagem. Enviar os discos com a identificação de baia preservada — etiquetando cada um com o slot de origem — e a PERC com o cache intacto é o conjunto mínimo para a análise. Se houver dúvida sobre qual disco pertence a qual baia, o Lifecycle Log e as etiquetas ajudam a reconstruir a ordem.
É possível recuperar as máquinas virtuais hospedadas no arranjo?
Sim, desde que o arranjo seja remontado e o datastore VMFS seja montado sobre o volume reconstruído. A recuperação de VMs segue a recuperação do RAID: primeiro o arranjo, depois o VMFS, depois os discos virtuais e o sistema de arquivos interno de cada VM. A validação inclui abrir cada VMDK e verificar a integridade do que está dentro. Casos de arranjos com SSDs NVMe seguem o mesmo fluxo, com atenção ao firmware específico de cada unidade.
