Quando um rebuild do RAID travou ou retornou erro, a primeira reação é tentar novamente — mas essa é exatamente a decisão que pode transformar um caso recuperável em perda permanente de dados. Um rebuild interrompido, seja por timeout, falha de controladora ou queda de energia, deixa o array em um estado inconsistente que ferramentas caseiras e tentativas repetidas tendem a piorar, não resolver. A cada novo ciclo de rebuild forçado, o risco de sobrescrita de setores críticos aumenta exponencialmente.
Antes de qualquer nova tentativa, é essencial entender o que causou o travamento inicial — se foi um disco falhando durante o processo, um controlador sobrecarregado, ou simplesmente falta de tempo para conclusão. Essas causas raiz determinam se um rebuild seguro é viável ou se o array precisa de intervenção técnica especializada em laboratório. Forçar rebuild sem diagnóstico correto é uma das principais razões pelas quais casos que começam como recuperáveis acabam em perda total.
Neste guia, explicamos o que fazer imediatamente após um erro de rebuild, quais sinais indicam que o array não deve ser reiniciado, e quando procurar recuperação profissional antes que seja tarde.
O que significa quando o rebuild do RAID trava ou retorna erro
O rebuild é o processo pelo qual um array RAID reconstrói os dados em um disco novo (ou reinicializado) após a falha de um dos membros. Quando esse processo trava, retorna erro ou simplesmente para antes de concluir, o sistema está sinalizando que há um problema mais sério do que a simples troca de um disco defeituoso. Ignorar esse sinal e tentar forçar um novo rebuild sem diagnóstico é uma das causas mais frequentes de perda definitiva de dados em ambientes RAID.
Diferença entre rebuild travado, rebuild com erro e rebuild incompleto
Esses três estados parecem semelhantes, mas têm implicações técnicas distintas:
- Rebuild travado: o processo inicia, avança até determinado ponto percentual e simplesmente para — sem mensagem de conclusão nem de erro explícito. O sistema pode continuar respondendo normalmente, mas o progresso do rebuild congela. Geralmente indica que a controladora encontrou um setor ilegível em um dos discos membros e não sabe como proceder.
- Rebuild com erro: a controladora registra uma falha explícita — erro de leitura, timeout de I/O, CRC error ou similar — e interrompe o processo ativamente. O array pode ser marcado como “degraded” ou até “failed”, dependendo do firmware.
- Rebuild incompleto: o processo avança, chega próximo ao fim, mas não conclui 100%. Pode ocorrer por queda de energia, reinicialização forçada ou novo erro de disco no momento menos oportuno. O estado do array fica inconsistente — parte dos dados foi reconstruída, parte não.
Cada um desses cenários exige uma abordagem diferente. Tratá-los como equivalentes é um erro que compromete a viabilidade da recuperação.
Por que o rebuild pode falhar: causas mais comuns
A falha no rebuild raramente é causada por um único fator isolado. As causas mais frequentes incluem:
- Bad sectors nos discos remanescentes: durante o rebuild, a controladora precisa ler 100% dos dados de todos os discos sobreviventes. Qualquer setor ilegível interrompe ou corrompe o processo. Em arrays RAID 5 com discos antigos, é comum que o segundo disco apresente bad sectors justamente quando submetido à leitura intensiva do rebuild.
- Disco já em estado degradado antes da falha: muitos arrays operam degradados por semanas sem que o administrador perceba. Quando o segundo disco começa a falhar durante o rebuild do primeiro, o resultado é um double failure — situação de risco máximo.
- Falha de controladora RAID: firmware desatualizado, capacitor de cache danificado ou superaquecimento da controladora podem corromper a tabela de configuração do array no meio do rebuild.
- Problemas de alimentação elétrica: quedas de tensão durante o rebuild podem causar escritas parciais, tornando o array inconsistente.
- Cabos SATA/SAS com mau contato: um cabo instável que funciona em operação normal pode falhar sob a leitura sequencial e contínua de um rebuild.
Primeiros passos obrigatórios antes de tentar qualquer nova ação
Antes de clicar em “reiniciar rebuild”, “substituir disco” ou qualquer outra opção na interface da controladora, há um conjunto de ações que precisam ser executadas — ou deliberadamente ignoradas, o que transforma um problema recuperável em perda definitiva.
Pare imediatamente: por que forçar um novo rebuild sem diagnóstico pode destruir os dados
A lógica parece simples: o rebuild falhou, basta tentar de novo. Na prática, cada tentativa de rebuild mal planejada submete os discos remanescentes a uma nova leitura sequencial completa — o tipo de operação mais agressiva para um disco com bad sectors ou com a cabeça de leitura em estado instável. Se o disco que causou a falha original ainda está no array, uma nova tentativa pode piorar irreversivelmente seu estado físico. Se há um segundo disco com setores danificados que ainda não foram detectados, o rebuild vai encontrá-los — e desta vez pode não haver redundância suficiente para recuperar os dados.
Além disso, algumas controladoras RAID, ao detectar falha no rebuild, reinicializam automaticamente o processo ou marcam discos adicionais como “failed” por precaução. Esse comportamento automático, sem intervenção humana consciente, já destruiu arrays que poderiam ter sido recuperados com diagnóstico adequado.
Como verificar o estado real de cada disco do array
O primeiro passo técnico é coletar dados de saúde de cada disco membro individualmente, antes de qualquer operação no array. As ferramentas mais confiáveis para isso são:
- SMART (Self-Monitoring, Analysis and Reporting Technology): use smartctl -a /dev/sdX no Linux ou CrystalDiskInfo no Windows para verificar atributos críticos como Reallocated Sectors Count (ID 05), Current Pending Sector (ID C5) e Uncorrectable Sector Count (ID C6). Qualquer valor diferente de zero nesses três atributos é sinal de alerta.
- Logs da controladora RAID: controladoras de hardware (LSI, Adaptec, HP Smart Array, Dell PERC) mantêm logs internos de eventos. Acesse via interface de gerenciamento (MegaRAID Storage Manager, arcconf, hpacucli) e procure entradas de “media error”, “predictive failure” ou “drive timeout” nos últimos dias.
- Logs do sistema operacional: no Linux, /var/log/syslog e dmesg registram erros de I/O com timestamps precisos. No Windows Server, o Event Viewer (System e Application) contém entradas críticas da controladora e dos discos.
Essa leitura é passiva — não altera nenhum dado no array — e fornece o mapa de risco real antes de qualquer decisão.
Como identificar qual disco causou a falha no rebuild
Nem sempre o disco marcado como “failed” pela controladora é o único problemático. Para identificar a origem real da falha:
- Cruze o timestamp do erro de rebuild com os logs da controladora e do sistema operacional para identificar qual disco gerou o primeiro erro de leitura.
- Verifique o número de série de cada disco físico contra o slot registrado nos logs — em ambientes com muitos discos, a numeração lógica da controladora nem sempre corresponde à posição física no gabinete.
- Execute um teste de leitura superficial (não um teste de escrita) em cada disco individualmente, fora do contexto do array, para mapear a distribuição de bad sectors.
Registre tudo antes de mexer
Antes de qualquer intervenção, documente o estado atual do array com capturas de tela ou exportação de logs:
- Estado de cada disco (online, degraded, failed, foreign)
- Ordem dos discos no array (slot 0, slot 1, slot 2…) e número de série correspondente
- Configuração do array: nível de RAID, tamanho do stripe, política de cache
- Mensagens de erro exatas exibidas pela controladora
- Percentual em que o rebuild travou (se aplicável)
Essa documentação é indispensável tanto para uma nova tentativa segura quanto para um laboratório especializado em recuperação de dados, caso o processo precise ser escalado.
Avaliando o risco por tipo de RAID antes de tentar novamente
O nível de RAID define diretamente a margem de segurança disponível e, portanto, o risco de cada decisão. O que é aceitável em um RAID 6 pode ser fatal em um RAID 5.
RAID 0: rebuild travado significa perda total — o que fazer
RAID 0 não tem redundância. Se um dos discos falhou, não há rebuild possível — os dados estão distribuídos em stripe entre todos os discos e a ausência de qualquer um torna o conjunto ilegível. Se o processo que você chama de “rebuild” em um RAID 0 travou, provavelmente trata-se de uma tentativa de reconstrução lógica por software. Nesse caso, pare imediatamente: qualquer escrita adicional nos discos remanescentes reduz as chances de recuperação. A única via viável é a recuperação forense em laboratório, lendo os discos individualmente e reconstruindo o padrão de stripe.
RAID 1: rebuild com erro e como verificar a integridade do espelho sobrevivente
Em um RAID 1, se o rebuild falhou, o espelho sobrevivente ainda contém todos os dados — em teoria. Antes de reiniciar qualquer processo, verifique a integridade desse disco com uma leitura completa (surface scan de leitura, não escrita). Se o disco sobrevivente apresentar bad sectors, ele pode estar em processo de falha — e um rebuild forçado vai submetê-lo a estresse adicional no pior momento possível. Sinais de falha iminente de um disco são fundamentais antes de tomar qualquer decisão nesse cenário.
RAID 5: rebuild travado com um disco já degradado — risco crítico de double failure
Este é o cenário mais perigoso e mais comum em ambientes corporativos. O RAID 5 tolera a falha de apenas um disco. Se o rebuild do primeiro disco falhou — seja por bad sector em um dos discos remanescentes, seja por timeout — o array está efetivamente sem redundância durante todo o processo. Qualquer novo erro em qualquer disco restante resulta em double failure e perda total dos dados. A decisão de reiniciar o rebuild sem antes clonar todos os discos remanescentes é tecnicamente indefensável nesse cenário.
RAID 6: margem extra de segurança, mas atenção ao rebuild parcial interrompido
O RAID 6 tolera a falha simultânea de dois discos, o que oferece uma margem maior durante o rebuild. Porém, se o rebuild foi interrompido após ter iniciado a escrita no disco de substituição, o estado do array pode estar inconsistente — parte dos dados reconstruída com os blocos de paridade originais, parte não. Reiniciar o rebuild nesse estado sem verificar a consistência pode gerar corrupção silenciosa: o array aparece como saudável, mas blocos específicos de dados estão incorretos.
RAID 10: qual par foi afetado e como isolar o problema
No RAID 10, o risco depende de qual par espelhado foi afetado. Se ambos os discos de um mesmo par falharam, os dados daquele par estão perdidos — independentemente do estado dos outros pares. Se apenas um disco do par falhou e o rebuild travou, o disco espelho sobrevivente contém os dados completos daquele par. Identifique o par afetado, verifique o estado do disco sobrevivente desse par e clone-o antes de qualquer tentativa de rebuild.
RAID 50 e RAID 60: complexidade adicional e diagnóstico crítico
RAID 50 (RAID 5+0) e RAID 60 (RAID 6+0) combinam redundância com striping entre múltiplos grupos. Uma falha de rebuild em um desses arrays pode envolver discos de grupos diferentes, e a reconstrução incorreta de um grupo pode corromper dados que estão distribuídos em stripe com outros grupos. O diagnóstico precisa mapear exatamente qual grupo foi afetado, quais discos compõem esse grupo e o estado de cada um antes de qualquer ação. Nesses casos, a complexidade da análise raramente é compatível com ferramentas de gerenciamento padrão — a intervenção de especialistas é praticamente mandatória.
Checklist de segurança antes de reiniciar o rebuild
Se após o diagnóstico você decidiu que é seguro tentar novamente, este checklist precisa ser completado integralmente antes de iniciar o processo.
Faça um clone setor a setor de cada disco antes de qualquer tentativa
Esta é a etapa mais importante e a mais frequentemente ignorada. Clonar setor a setor significa criar uma cópia bit a bit de cada disco membro em um disco de capacidade igual ou superior, preservando exatamente o estado atual — incluindo bad sectors e estruturas de metadados do array. Se o rebuild falhar novamente, você ainda tem os dados originais intactos para uma nova tentativa ou para envio a um laboratório.
Como usar ddrescue para clonar discos com bad sectors
O GNU ddrescue é a ferramenta mais adequada para clonar discos com setores danificados porque utiliza um algoritmo de múltiplas passagens: lê primeiro os blocos saudáveis, depois tenta recuperar os blocos problemáticos com tentativas repetidas e timeouts configuráveis. O comando básico é:
ddrescue -d -r3 /dev/sdX /dev/sdY mapfile.log
O arquivo de mapa (mapfile.log) registra o progresso e permite retomar o processo se for interrompido. Nunca use dd puro para discos com bad sectors — ele para no primeiro erro e não tenta recuperar os blocos problemáticos. Ferramentas comerciais como o PC-3000 UDMA, usado em laboratórios especializados, oferecem controle ainda mais granular sobre esse processo.
Verifique a controladora RAID: firmware desatualizado pode causar erros de rebuild
Firmware desatualizado é uma causa silenciosa de falhas de rebuild. Fabricantes como LSI/Broadcom, Adaptec e HP lançam atualizações que corrigem bugs específicos de rebuild, especialmente em discos de maior capacidade. Antes de reiniciar o processo, verifique a versão atual do firmware da controladora no site do fabricante e aplique a atualização mais recente — mas apenas após clonar todos os discos, pois a atualização de firmware pode, em casos raros, reinicializar o estado do array.
Confirme a ordem correta dos discos no array antes de reiniciar
Em arrays com muitos discos, especialmente após manutenção física, é comum que discos sejam recolocados em slots errados. A ordem dos discos no array é parte da configuração que define como os dados foram escritos. Inserir um disco no slot errado antes do rebuild pode resultar em reconstrução com paridade incorreta — os dados aparecem como recuperados, mas estão corrompidos. Confirme a ordem usando os logs da controladora e os números de série registrados na etapa de documentação.
Ambiente físico: temperatura, alimentação elétrica e cabos como fontes de falha
Antes de reiniciar o rebuild, verifique:
- Temperatura do gabinete e dos discos (ideal abaixo de 45°C para HDs mecânicos)
- Estabilidade da alimentação elétrica — use um nobreak (UPS) durante todo o processo
- Substitua cabos SATA/SAS suspeitos por cabos novos, especialmente em servidores com mais de três anos de uso
- Verifique o backplane do servidor (se aplicável) para sinais de oxidação nos conectores
Como reiniciar o rebuild com segurança após o diagnóstico
Quando substituir o disco com falha antes de reiniciar o rebuild
Substitua o disco antes de reiniciar o rebuild quando: o disco está marcado como “failed” pela controladora, apresenta erros de leitura consistentes no SMART, ou produz ruídos físicos anormais. Barulhos de clique ou travamentos são indicadores claros de falha mecânica iminente — um disco nesse estado não deve permanecer no array. Use um disco novo do mesmo fabricante e capacidade, ou de capacidade superior.
Quando é seguro tentar o rebuild no mesmo disco
Reiniciar o rebuild no mesmo disco (sem substituição) só é seguro quando: o rebuild anterior foi interrompido por queda de energia ou reinicialização forçada — não por erro de leitura do disco —, o SMART do disco não apresenta erros de setor, e os logs da controladora confirmam que a interrupção foi externa ao disco. Mesmo nesse caso, o clone setor a setor deve ter sido feito antes.
Configurações da controladora que podem aumentar a chance de sucesso
Algumas configurações na controladora RAID podem melhorar as chances de um rebuild bem-sucedido em discos com problemas leves:
- Reduzir a taxa de rebuild (rebuild rate) para diminuir o impacto no desempenho e a pressão sobre os discos
- Habilitar “copyback” apenas após o rebuild completar, não durante
- Desativar o “patrol read” automático durante o rebuild para evitar leituras concorrentes
- Configurar timeouts de I/O mais longos para discos com resposta lenta
Monitoramento em tempo real durante o novo rebuild
Durante o rebuild, monitore continuamente:
- Temperatura de todos os discos do array
- Contadores de erro no SMART (especialmente Current Pending Sectors)
- Logs da controladora em tempo real — qualquer novo erro de leitura deve pausar o processo imediatamente
- Taxa de progresso — uma queda súbita na velocidade de rebuild indica que a controladora está encontrando setores problemáticos
Quando o rebuild não pode ser reiniciado com segurança: recuperação de dados como alternativa
Há situações em que nenhuma das etapas anteriores é suficiente para tornar o rebuild seguro. Reconhecer esse limite é tão importante quanto o diagnóstico técnico.
Softwares de recuperação de RAID: o que conseguem e o que não conseguem fazer
Ferramentas como ReclaiMe Free RAID Recovery, R-Studio e UFS Explorer conseguem reconstruir virtualmente a configuração de um array RAID a partir dos discos membros, sem precisar de uma controladora funcional. São úteis quando a controladora falhou mas os discos estão íntegros, ou quando a configuração do array foi perdida. No entanto, essas ferramentas têm limitações críticas: não conseguem recuperar dados de discos com bad sectors extensos sem que os dados já tenham sido clonados, não funcionam adequadamente em double failure de RAID 5, e podem gerar falsos positivos — apresentar uma estrutura de diretórios aparentemente correta, mas com arquivos corrompidos internamente. Recomendamos mencioná-las apenas como ponto de diagnóstico inicial, não como solução definitiva em casos complexos.
Recuperação em laboratório especializado: quando é a única opção viável
A recuperação em laboratório especializado torna-se a única opção viável quando:
- Há double failure confirmado em RAID 5 ou falha de mais de dois discos em RAID 6
- Um ou mais discos apresentam falha física (cabeça de leitura, prato danificado, eletrônica)
- A controladora RAID falhou e corrompeu os metadados do array
- Múltiplas tentativas de rebuild geraram inconsistências que softwares de mercado não conseguem resolver
- Os dados são críticos demais para aceitar o risco de qualquer nova tentativa sem ambiente controlado
Em laboratório, o processo começa com a clonagem individual de cada disco em sala limpa ISO-5 — necessária quando há falha física que exige abertura do disco. A partir das imagens clonadas, a reconstrução do array é feita de forma não destrutiva, com ferramentas profissionais capazes de lidar com configurações de stripe, paridade e offset que softwares de mercado não suportam. O resultado é validado tecnicamente antes da entrega, com relatório da causa da falha.
Se o rebuild do seu RAID travou ou retornou erro e você já tentou mais de uma vez sem diagnóstico adequado, o estado atual dos discos é o ponto de partida para qualquer análise — e cada nova tentativa não planejada reduz as chances de recuperação. A avaliação técnica inicial, feita por especialistas com as ferramentas e o ambiente corretos, é o único caminho que preserva as opções em aberto.
