Um dos discos do seu RAID sumiu do console da controladora e agora você precisa saber se ainda dá para recuperar RAID com um disco faltando sem piorar o quadro. O receio é justo: cada comando errado, cada tentativa de rebuild no escuro, pode custar a paridade que restou. Este texto mostra como interpretar o estado real do array, o que trava a recuperação e em que ponto a intervenção caseira deixa de ser segura.
O que significa um disco faltando no RAID
Quando um array RAID perde um de seus discos, o sistema passa a operar em estado degradado — os dados continuam acessíveis em níveis com redundância, mas a tolerância a uma segunda falha despenca para zero. O termo “disco faltando” descreve a situação em que a controladora não consegue mais enxergar um dos membros do array, seja por expulsão lógica, desconexão física ou falha mecânica do drive. Esse é o momento de maior risco para o conjunto: qualquer operação de escrita mal planejada pode corromper a paridade e transformar uma perda recuperável em cenário de laboratório.
Diferente do que muitos administradores imaginam, o disco que sumiu não é necessariamente um disco morto. Em controladoras Dell PERC, LSI e Adaptec, um drive pode desaparecer do array por timeout de resposta, vibração excessiva, cabo backplane defeituoso ou firmware instável — sem que a mídia magnética tenha sofrido qualquer dano irreversível. Diagnosticar a causa antes de qualquer intervenção é o que separa uma recuperação limpa de um desastre autoinfligido.
Diferença entre disco ausente, disco failed e disco removido
No console da controladora, os estados possuem significados técnicos distintos e exigem condutas diferentes. Um disco ausente (missing) é aquele que a controladora esperava encontrar, mas não respondeu durante a inicialização — pode ter sido desconectado, ter falhado eletricamente ou estar em processo de falha intermitente. Um disco failed foi explicitamente marcado como defeituoso pela controladora após exceder o limite de erros de leitura ou timeout; nesse caso, o firmware já o removeu do grupo ativo. Já o disco removido (removed ou unconfigured good) é aquele que foi retirado manualmente do array por ação administrativa, intencional ou acidental.
- Missing: não respondeu no boot; pode ser cabo, backplane ou eletrônica do drive
- Failed: expulso pela controladora por erros críticos de I/O
- Removed: retirado por comando administrativo ou troca física indevida
- Unconfigured good: disco físico íntegro, mas sem associação lógica ao array
Tratar um disco missing como se fosse failed é um erro clássico: forçar a marcação do drive como defeituoso quando ele apenas não foi detectado por falha de comunicação pode iniciar um rebuild desnecessário sobre um membro que ainda contém dados válidos. Em arrays RAID 5 com um disco já degradado, essa ação pode consumir a última margem de segurança do conjunto.
O que a controladora mostra quando um membro do array desaparece
O comportamento visual depende do fabricante, mas há padrões reconhecíveis. Em controladoras LSI/Avago (Broadcom), o array aparece como Degraded com o disco problemático listado como Missing ou Failed na aba de propriedades físicas. Em Dell PERC, o Virtual Disk exibe estado Degraded e o Physical Disk correspondente surge com ícone amarelo ou vermelho, frequentemente acompanhado da mensagem Foreign configuration found se o disco reaparecer em outro slot ou após troca de controladora.
Algumas controladoras também registram eventos no log interno: PD Missing, Sense Key = Medium Error ou contadores de Media Error Count e Other Error Count elevados. Esses registros são a primeira evidência objetiva da natureza do problema e devem ser fotografados antes de qualquer comando. O log da controladora, junto com a captura de tela do estado dos discos, forma o conjunto mínimo de informações que um laboratório de recuperação precisa para estimar viabilidade sem ligar o array novamente.
Dá para recuperar os dados com um disco faltando?
Na maioria dos níveis de RAID com redundância, sim — desde que a paridade ou o espelhamento remanescente esteja íntegro e nenhuma operação destrutiva tenha sido executada. A recuperação lógica de um array degradado consiste em reconstruir os dados do disco ausente a partir dos blocos sobreviventes, seja via rebuild controlado pela própria controladora, seja por reconstrução virtual em ambiente de laboratório com imagens setor a setor de todos os discos remanescentes.
O fator decisivo não é a ausência do disco em si, mas o que aconteceu nos minutos e horas seguintes ao desaparecimento. Um array RAID 5 que perdeu um disco e permaneceu desligado tem probabilidade alta de recuperação integral. O mesmo array, se mantido em produção com escritas contínuas sobre um conjunto degradado, acumula inconsistências de paridade que podem comprometer a reconstrução de arquivos inteiros.
Quando a recuperação é viável
A viabilidade é alta quando o array foi desligado imediatamente após a detecção da falha, os discos remanescentes não apresentam erros de leitura e a configuração original (ordem dos discos, tamanho de stripe, nível de RAID) está documentada ou pode ser inferida com precisão. Nesses casos, a recuperação pode ser feita sem abertura dos drives em sala limpa, apenas com clonagem lógica e remontagem virtual do volume.
- Array desligado logo após o disco sumir
- Discos remanescentes sem SMART crítico ou erros de leitura
- Configuração de RAID conhecida ou recuperável por análise de metadados
- Nenhuma tentativa anterior de rebuild ou import de configuração
Mesmo quando o disco ausente reaparece com defeito físico, a recuperação ainda é possível se os demais membros estiverem saudáveis. O laboratório trabalha então com a clonagem do disco problemático — quando viável — ou com a reconstrução matemática a partir da paridade, sem depender do drive defeituoso.
Quando o cenário já exige laboratório
O cenário muda de patamar quando há dois ou mais discos com problemas simultâneos, quando o array foi submetido a rebuilds malsucedidos ou quando a controladora foi substituída e a configuração original se perdeu. Nesses casos, tentar recuperar com as ferramentas da própria controladora tende a piorar o quadro, pois cada tentativa de rebuild escreve sobre a paridade existente e reduz a janela de recuperação.
Também exigem intervenção especializada os arrays cujo disco ausente apresenta defeito físico — cabeça de leitura danificada, motor travado ou superfície riscada. A manipulação direta do drive fora de ambiente controlado pode destruir a mídia de forma irreversível, como ocorre em casos de HD fazendo barulho de clique, sintoma clássico de falha mecânica de cabeça.
O que muda conforme o nível de RAID
Cada nível de RAID distribui dados e redundância de maneira diferente, o que altera profundamente o impacto de um disco faltando. Um RAID 1 perde apenas a cópia espelhada; um RAID 0 perde o array inteiro. Entender essa arquitetura é o primeiro passo para avaliar a urgência e o prognóstico de cada caso.
RAID 1 e RAID 10
No RAID 1, cada bloco de dados existe em dois discos. Com um disco faltando, o espelho remanescente contém 100% dos dados — a recuperação é tecnicamente simples e pode ser feita com clonagem direta do disco sobrevivente. No RAID 10, que combina espelhamento e striping, a perda de um disco degrada apenas um dos pares espelhados; os demais pares continuam íntegros e acessíveis.
O risco nesses níveis é baixo, mas existe: se o disco remanescente do par espelhado também apresentar setores defeituosos, os dados daquele par podem se perder. Por isso, mesmo em RAID 1, a clonagem do disco sobrevivente antes de qualquer rebuild é a conduta recomendada quando há suspeita de desgaste físico.
RAID 5 e RAID 6
No RAID 5, os dados e a paridade são distribuídos entre todos os discos. Com um disco faltando, cada bloco do drive ausente pode ser recalculado a partir da paridade e dos dados dos demais membros — desde que a paridade esteja íntegra. O perigo aparece quando o array continua em produção degradada: cada escrita nova atualiza a paridade, e qualquer erro de leitura em um dos discos restantes durante o rebuild gera inconsistências que corrompem faixas inteiras de dados.
O RAID 6 mantém duas paridades independentes, tolerando a perda de até dois discos simultaneamente. Com um único disco faltando, o RAID 6 ainda possui redundância remanescente — mas isso não autoriza complacência. Se um segundo disco começar a falhar durante o rebuild do primeiro, o processo pode se arrastar por dias, expondo o array a uma janela de risco prolongada.
RAID 0 e JBOD
RAID 0 e JBOD não possuem redundância alguma: os dados são distribuídos entre os discos sem paridade nem espelhamento. Quando um disco some de um RAID 0, o volume inteiro se torna inacessível do ponto de vista lógico, pois cada arquivo tem fragmentos espalhados por todos os membros. A recuperação nesse caso depende de recuperar fisicamente o disco ausente — se possível — e então remontar o stripe original.
Em JBOD, a situação é menos uniforme: como os discos são concatenados sem striping, os dados dos discos remanescentes podem ser lidos individualmente, mas a estrutura de volume se perde. A recuperação costuma ser viável para os arquivos que residiam integralmente nos discos sobreviventes, enquanto os dados do disco ausente dependem de recuperação física do próprio drive.
O que NÃO fazer assim que um disco some do array
A reação instintiva de um administrador diante de um disco faltando é “consertar” — religar, forçar rebuild, importar configuração, trocar o drive. Cada uma dessas ações, executada sem diagnóstico prévio, pode transformar um problema simples de comunicação em perda definitiva de dados. A regra de ouro em recuperação de RAID é: preservar o estado atual antes de qualquer escrita.
Por que não inicializar nem recriar o array
Inicializar o servidor com o array degradado pode parecer inofensivo, mas a controladora executa procedimentos automáticos no boot — verificação de consistência, patrol read, import de configuração estrangeira — que escrevem nos discos. Se a causa do desaparecimento for um cabo solto, o simples ato de religar pode fazer a controladora marcar o disco como failed e iniciar um rebuild sobre um drive que estava perfeitamente íntegro.
Recriar o array do zero é ainda pior. O comando de criação de novo virtual disk sobrescreve os metadados originais de todos os discos, destruindo a informação de ordem, tamanho de stripe e nível de RAID. Depois disso, a recuperação depende exclusivamente de análise forense dos padrões de dados brutos — um processo muito mais caro, demorado e com taxa de sucesso menor.
Por que não confiar no rebuild automático
O rebuild automático é a resposta padrão da controladora quando um hot spare está configurado ou quando o disco problemático é substituído por um novo. O problema é que o rebuild reconstitui os dados lendo todos os blocos dos discos remanescentes — e qualquer setor ilegível em qualquer um deles interrompe ou corrompe o processo. Em arrays com anos de uso, a probabilidade de existirem setores marginais não detectados é significativa.
Quando o rebuild falha no meio, a controladora frequentemente marca o array como offline ou failed, bloqueando o acesso a todos os dados — inclusive aqueles que estavam íntegros antes da tentativa. A recuperação pós-rebuild malsucedido é mais complexa do que a recuperação do array degradado original, porque agora há paridade parcialmente reescrita e inconsistências distribuídas pelo volume.
Passo a passo seguro antes de qualquer intervenção
Antes de ligar qualquer equipamento ou executar qualquer comando na controladora, há um protocolo de preservação que aumenta drasticamente as chances de recuperação. Ele se resume a três etapas: documentar, diagnosticar e isolar. Nenhuma dessas etapas escreve nos discos — são ações de leitura e registro.
Registrar o estado atual da controladora
Se o servidor ainda estiver ligado, capture imediatamente as telas do console da controladora: estado do virtual disk, estado de cada physical disk, contadores de erro SMART, log de eventos e configuração de stripe. Essas informações, fotografadas ou salvas em arquivo, permitem que a reconstrução posterior use os parâmetros exatos do array — sem depender de inferência.
- Capturar tela do Virtual Disk (nível, tamanho, stripe, política de cache)
- Capturar tela de cada Physical Disk (estado, slot, número de série)
- Exportar o log de eventos da controladora
- Registrar SMART de todos os discos, inclusive o ausente, se detectado
Se o servidor já foi desligado, não o religue apenas para capturar essas telas. A decisão de religar deve ser tomada caso a caso, pesando o valor da informação contra o risco de a controladora executar procedimentos automáticos destrutivos no boot. Em muitos casos, o laboratório prefere receber os discos e fazer a leitura em hardware controlado, sem passar pela controladora original.
Identificar qual disco saiu e por quê
O slot físico do disco ausente e a causa provável do desaparecimento orientam toda a estratégia. Um disco que sumiu após manutenção no gabinete sugere cabo ou backplane; um disco com SMART mostrando Reallocated Sector Count crescente sugere degradação progressiva da mídia; um disco que sumiu durante pico de temperatura sugere falha térmica. Cada causa aponta para um caminho de recuperação diferente.
Anote também o modelo, a capacidade e o número de série de todos os discos do array, inclusive o ausente. Discos de mesma capacidade nominal podem ter tamanhos reais diferentes entre fabricantes — e a reconstrução exige que o disco substituto tenha tamanho real igual ou superior ao original. Essa informação é crítica para a reconstrução virtual em laboratório.
Preservar os discos remanescentes
Desligue o servidor de forma controlada, remova os discos remanescentes e identifique fisicamente cada um com o slot de origem. A ordem física dos discos é informação vital para a remontagem do array — uma troca de posição durante o manuseio pode inviabilizar a reconstrução automática e exigir análise forense adicional. Armazene os drives em embalagem antiestática, na posição correta, sem empilhar.
Não execute testes de superfície, não rode utilitários de verificação, não conecte os discos a outro computador para “ver se funcionam”. Cada leitura desnecessária sobre mídia possivelmente fragilizada é uma oportunidade de agravar danos físicos incipientes. A conduta correta é manter os discos intocados até a decisão de clonagem controlada.
Rebuild, foreign configuration e clear configuration: o que cada um faz
Os três comandos mais perigosos do console de uma controladora RAID são também os mais mal compreendidos. Eles não são equivalentes, e a ordem em que são executados — ou a decisão de não executá-los — define o desfecho de uma recuperação. Conhecer o efeito real de cada um evita o erro clássico de “importar para ver o que acontece”.
Foreign configuration: importar ou não
Foreign configuration é o estado em que a controladora detecta discos que pertencem a um array criado por outra controladora — ou pela mesma controladora após perda de configuração. A mensagem aparece com frequência em Dell PERC e LSI quando o disco ausente reaparece em outro slot, quando a bateria da NVRAM falhou ou quando a controladora foi trocada. Importar a configuração estrangeira pode restaurar o array corretamente — ou pode aplicar parâmetros errados e iniciar um rebuild destrutivo.
- Import: adota a configuração detectada nos discos; pode iniciar rebuild se houver disco marcado como ausente
- Clear: apaga a configuração estrangeira dos discos; destrói metadados do array original
- Ignore: mantém os discos sem associação; não escreve nada, preserva o estado
A decisão de importar só é segura quando a configuração estrangeira corresponde exatamente ao array esperado — mesmo número de discos, mesmo nível, mesmo tamanho de stripe — e quando nenhum disco está marcado como failed. Qualquer divergência indica que a importação pode aplicar uma configuração parcial e iniciar um rebuild sobre dados válidos. Em caso de dúvida, não importar é sempre a opção de menor risco.
Rebuild interrompido e punctures
Um rebuild interrompido deixa o array em estado inconsistente: parte dos blocos foi reconstruída no disco novo, parte permanece ausente, e a paridade pode ter sido parcialmente atualizada. Retomar o rebuild a partir desse ponto é possível em algumas controladoras, mas o resultado depende de não haver erros de leitura nos discos fonte durante a retomada. Se houver, o processo para novamente — ou pior, conclui com dados corrompidos silenciosamente.
Puncture é o termo usado quando a controladora detecta que um bloco de paridade não corresponde aos dados — geralmente consequência de um rebuild malsucedido ou de escritas incompletas durante queda de energia. Uma vez que um puncture é registrado, a controladora passa a retornar erro de leitura para aquele bloco, mesmo que os discos físicos estejam íntegros. Punctures acumulados são um dos motivos mais comuns de “arquivos que somem” após um rebuild bem-sucedido.
Quando o caso deixa de ser caseiro e vai para laboratório
Há um limite claro entre o que pode ser resolvido com os recursos da própria controladora e o que exige infraestrutura de recuperação profissional. Ultrapassar esse limite sem perceber é a principal causa de perda definitiva em ambientes corporativos. Os sinais abaixo indicam que o momento de parar já passou.
Sinais de falha física no disco ausente
Se o disco ausente, quando testado isoladamente, apresenta clique mecânico, não gira, gira e para, ou é detectado com identificação incorreta (modelo errado, capacidade zerada, nome de fábrica genérico), há falha física confirmada. Nesses casos, nenhuma operação lógica na controladora trará o disco de volta — e insistir em religar o drive pode danificar a superfície magnética de forma irreversível, como detalhado em tentar recuperar HD sozinho pode piorar a situação.
Falha física exige abertura do drive em ambiente controlado, substituição de componentes internos e leitura em equipamento especializado. Esse tipo de intervenção não é executável fora de um laboratório com sala limpa e ferramentas de recuperação de firmware — e qualquer tentativa artesanal reduz a probabilidade de sucesso.
Clonagem controlada e reconstrução virtual do array
O procedimento padrão em laboratório para RAID com disco faltando começa pela clonagem setor a setor de todos os discos remanescentes — e do disco ausente, se ele ainda responder. A clonagem é feita em hardware que controla o número de tentativas de leitura por setor, contorna áreas danificadas e preserva a ordem física dos dados. Trabalha-se com as imagens, nunca com os discos originais.
Em seguida, o laboratório remonta o array virtualmente, usando os parâmetros originais de stripe, ordem e nível de RAID. O disco ausente é substituído por uma imagem vazia do mesmo tamanho, e o software de reconstrução recalcula os blocos faltantes a partir da paridade. O resultado é um volume montável, do qual os dados são extraídos para uma mídia nova. Esse processo elimina o risco de rebuild destrutivo e permite validar a integridade dos arquivos antes de devolvê-los.
O que define o custo de recuperar um RAID com disco faltando
O custo de uma recuperação de RAID degradado é definido por variáveis técnicas, não por uma tabela fixa. O nível de RAID, o número de discos envolvidos, a presença de falha física no disco ausente e a complexidade da reconstrução lógica são os principais componentes. Um RAID 1 com um disco faltando e o espelho íntegro tende a ser substancialmente mais simples do que um RAID 6 com dois discos em falha progressiva e rebuilds malsucedidos no histórico.
- Nível de RAID e quantidade de discos no array
- Necessidade de recuperação física do disco ausente
- Existência de tentativas anteriores de rebuild ou clear configuration
- Disponibilidade de documentação da configuração original
- Urgência e necessidade de parada operacional controlada
Casos que exigem abertura de disco em sala limpa, doação de cabeças de leitura ou recuperação de firmware têm custo superior aos casos puramente lógicos. Da mesma forma, arrays cuja configuração original se perdeu e precisa ser inferida por análise forense demandam mais horas de engenharia. A avaliação de viabilidade — com diagnóstico do estado real dos discos — é o que permite estimar o esforço com precisão antes de qualquer compromisso financeiro.
Perguntas frequentes sobre RAID com um disco faltando
Posso ligar o servidor para testar?
Ligar o servidor para “ver o que acontece” é a ação de maior risco nesse cenário. A controladora executa procedimentos automáticos no boot que podem iniciar rebuild, importar configuração estrangeira ou marcar discos como failed com base em timeouts transitórios. Se o servidor já está desligado, mantenha-o desligado até que um diagnóstico técnico oriente o próximo passo. Se ainda está ligado, capture as telas da controladora antes de qualquer desligamento.
O hot spare resolve sozinho?
O hot spare, quando configurado, entra automaticamente no lugar do disco ausente e inicia o rebuild. Isso pode funcionar em cenários de falha isolada e discos saudáveis — mas também pode ser o gatilho de um rebuild destrutivo se houver setores ilegíveis nos discos remanescentes ou se o disco “ausente” tiver apenas se desconectado por falha de cabo. A presença de hot spare não elimina a necessidade de avaliar a causa da falha antes de permitir o rebuild.
Preciso enviar o servidor inteiro ou só os discos?
Na maioria dos casos, apenas os discos são necessários — acompanhados da documentação da configuração do array, se disponível. Enviar o servidor inteiro é recomendado apenas quando há dúvida sobre a ordem dos discos, quando a controladora contém configuração específica que precisa ser preservada ou quando o cliente não tem equipe técnica para remover os drives com segurança. Cada disco deve ser identificado com o slot de origem antes do envio.
Quanto tempo leva a recuperação?
O prazo varia conforme a complexidade: um RAID 1 com espelho íntegro pode ser recuperado em horas; um RAID 5 com falha física no disco ausente e necessidade de clonagem setor a setor pode levar dias. A clonagem de discos de grande capacidade é o fator que mais consome tempo, especialmente quando há setores defeituosos que exigem múltiplas tentativas de leitura. O diagnóstico inicial é o que permite estimar o prazo com realismo.
