O alerta de erro de leitura em um membro do array RAID costuma chegar em um momento ruim: o sistema está no ar, os arquivos estão em uso e a pressa para “resolver logo” parece o caminho natural. Só que cada comando executado nesse intervalo pode fechar definitivamente a janela de recuperação. Este texto mostra como reconhecer o que o controlador está sinalizando, o que evitar nos primeiros minutos e por que a clonagem controlada em laboratório costuma vir antes de qualquer rebuild.
O que é um erro de leitura em RAID e por que ele é mais grave do que parece
Um erro de leitura em RAID é a incapacidade do controlador de ler um ou mais setores de um disco membro do conjunto. O sistema operacional pode nem perceber o evento no primeiro momento — a camada RAID tenta contornar usando paridade ou espelhamento. O problema é que esse erro quase nunca é isolado: ele costuma ser o primeiro sintoma visível de degradação física progressiva na superfície magnética ou nas células NAND.
Em um disco isolado, um setor ilegível gera uma falha pontual. Em um array, o mesmo setor ilegível dispara uma cadeia de decisões automáticas do controlador que pode reescrever paridade, marcar o disco como defeituoso ou iniciar rebuild sem intervenção humana. É exatamente essa automatização que transforma um defeito localizado em perda ampla de dados.
Erro de leitura, erro de escrita e falha física: o que cada um significa
Erro de leitura ocorre quando o disco não consegue devolver o conteúdo de um setor solicitado, geralmente reportado como UNC error (uncorrectable error) ou medium error nos logs SCSI/SAS. Erro de escrita é o inverso: o comando de gravação não é confirmado, e o setor pode ficar com conteúdo inconsistente. Falha física é o nível mais profundo — cabeçote danificado, motor travado, placa lógica queimada ou trilha de servo comprometida.
Um mesmo sintoma pode ter origens diferentes. Cabeçote com desgaste gera erros de leitura intermitentes que somem após reinício. Degradação de mídia gera erros persistentes que se espalham a cada tentativa. Setor reescrito com sucesso após erro de leitura não significa disco saudável — significa que o firmware realocou o setor para a área reservada, e a contagem de setores realocados subiu nos atributos SMART.
Erro de leitura recuperável, pendente e não corrigível
O firmware do disco classifica o erro em três categorias práticas. O erro recuperável é corrigido internamente pelo ECC do próprio disco, sem exposição ao controlador RAID — o dado chega íntegro, mas o evento fica registrado nos atributos SMART como sinal de alerta precoce.
O setor pendente (current pending sector) é aquele que o disco ainda não conseguiu ler, mas mantém na fila para nova tentativa. Se uma gravação posterior nesse mesmo setor for bem-sucedida, ele sai da lista de pendentes; se a leitura continuar falhando, migra para a categoria de não corrigível. O erro não corrigível é o que chega ao controlador RAID e dispara a reconstrução por paridade ou a leitura do espelho.
- Recuperável: corrigido pelo ECC interno, invisível ao RAID, mas registrado no SMART.
- Pendente: aguardando nova tentativa; pode virar não corrigível a qualquer momento.
- Não corrigível: reportado ao controlador; exige paridade, espelho ou intervenção externa.
Como o controlador reage a um erro de leitura em cada nível de RAID
Em RAID 0, não há redundância: o erro de leitura em um membro corrompe o stripe inteiro, e o arquivo afetado fica ilegível ou parcialmente ilegível. Em RAID 1 e RAID 10, o controlador lê o setor correspondente no espelho e, se conseguir, reescreve o setor defeituoso no disco original — processo chamado de rewrite on read error.
Em RAID 5, o controlador usa a paridade para recalcular o dado do setor ilegível. Em RAID 6, usa a primeira paridade; se ela também falhar, tenta a segunda. O detalhe crítico é que esse recálculo exige a leitura de todos os outros discos do stripe — se qualquer um deles apresentar erro de leitura simultâneo, a reconstrução do setor falha e o stripe inteiro fica comprometido.
Os primeiros minutos após o alerta: o que fazer e o que nunca fazer
O alerta de erro de leitura chega de formas diferentes: e-mail do NAS, LED âmbar no servidor, mensagem no console do controlador ou lentidão extrema sem explicação. O instinto mais comum é entrar no gerenciador do RAID e executar alguma ação corretiva imediata. É justamente essa pressa que destrói a janela de recuperação segura.
Antes de qualquer comando, é preciso registrar o estado completo do array: qual disco reportou o erro, quantos setores, qual o status de cada membro e se o conjunto está degradado ou ótimo. Capturar logs e telas do gerenciador custa minutos e preserva informação que será decisiva no diagnóstico posterior. A segunda providência é interromper novas gravações no volume — parar backups, suspender aplicações e impedir que usuários continuem salvando arquivos.
Comandos e ações que agravam o quadro
Forçar o disco defeituoso de volta ao array (force online) é uma das ações mais destrutivas. O controlador passa a considerar o membro íntegro e usa seus dados para reconstruir os demais — se o disco está com setores ilegíveis, a corrupção se propaga para o conjunto inteiro. O mesmo vale para apagar a configuração do array e recriá-lo com os mesmos discos na tentativa de “fazer voltar”.
- Force online: reintroduz disco com erro como se estivesse saudável; propaga corrupção.
- Recriar array do zero: apaga metadados de ordem, offset e tamanho de stripe; dificulta ou inviabiliza a remontagem.
- Inicialização ou verificação com correção automática: reescreve paridade a partir de dados potencialmente ilegíveis.
- Formatação ou chkdsk / fsck com reparo: altera o sistema de arquivos antes de clonar os membros.
- Trocar disco e iniciar rebuild imediato: força leitura total dos membros restantes, incluindo setores frágeis.
Por que um rebuild iniciado no momento errado pode custar os dados
O rebuild lê integralmente todos os discos sobreviventes para recalcular o conteúdo do membro substituído. Em um array que já apresenta erro de leitura em um disco, os demais frequentemente estão no limite da degradação — discos do mesmo lote, mesma idade e mesma carga operacional. A leitura intensiva do rebuild é o gatilho que transforma setores pendentes em falhas definitivas.
Se um segundo disco falhar durante o rebuild de um RAID 5, o array entra em colapso total. Em RAID 6, a falha de um segundo disco durante o rebuild deixa o conjunto sem margem: qualquer erro de leitura nos membros restantes, que não pode mais ser corrigido por paridade, interrompe o processo. Por isso a ordem correta é clonar os membros com erro antes de autorizar qualquer rebuild.
Quando desligar o equipamento e quando mantê-lo ligado
Se o erro de leitura veio acompanhado de ruído mecânico — clique, rangido, batida ritmada — o equipamento deve ser desligado imediatamente. Cabeçote danificado raspando a superfície destrói setores a cada rotação, e manter o disco girando é perda garantida. O mesmo vale para aquecimento anormal ou cheiro de queimado.
Se o array está estável, sem ruído e apenas com o alerta de erro de leitura, o ideal é mantê-lo ligado, suspender todas as gravações e acionar um laboratório antes de qualquer ação. Desligar e religar um conjunto com discos em fim de vida pode impedir que um ou mais membros voltem a subir, por causa do stress de spin-up. A decisão correta depende do sintoma físico, não do alerta lógico.
Erro de leitura em RAID 5, RAID 6 e RAID 10: o risco muda de nível
Cada nível de RAID reage de forma diferente ao erro de leitura porque a redundância disponível muda. O que é contornável em RAID 10 pode ser fatal em RAID 5 degradado. Entender essa diferença evita a falsa sensação de segurança que leva administradores a subestimar o alerta.
Um detalhe que muitos ignoram: a tolerância nominal de cada nível vale para falha total de disco, não para erros de leitura simultâneos. Um RAID 6 que tolera a perda de dois discos inteiros pode colapsar com um único disco ausente e um setor ilegível em outro membro durante o rebuild.
RAID 5 degradado: a janela em que um segundo erro é fatal
Com um disco já fora do array, o RAID 5 perdeu toda a redundância. Cada erro de leitura em qualquer um dos discos restantes não pode mais ser corrigido por paridade — o setor simplesmente não é lido, e o rebuild trava ou entrega dado corrompido. É a chamada janela de vulnerabilidade, que permanece aberta até o rebuild concluir 100%.
O agravante é que o rebuild exige leitura completa dos discos sobreviventes, justamente quando eles estão mais exigidos. Discos empresariais modernos têm taxa de erro não recuperável especificada em 1 setor a cada 10^15 bits lidos — em um array de vários terabytes, a leitura completa do rebuild estatisticamente cruza essa marca. É por isso que RAID 5 com discos de alta capacidade é considerado arriscado para rebuild desde que os fabricantes passaram a recomendar RAID 6 ou RAID 10 para volumes grandes.
RAID 6 com dupla paridade: o que a tolerância extra realmente cobre
A dupla paridade do RAID 6 protege contra a falha total de dois discos simultaneamente — e, durante o rebuild com um disco ausente, ainda permite corrigir erros de leitura pontuais nos membros restantes usando a segunda paridade. É uma proteção real, mas não absoluta.
O limite aparece quando os erros de leitura se acumulam: cada setor ilegível exige leitura adicional dos demais discos e cálculo de paridade, o que aumenta o tempo de rebuild e a carga sobre mídias já frágeis. Se dois discos falham e um terceiro apresenta erro de leitura não corrigível, o RAID 6 também colapsa. A dupla paridade amplia a margem, não elimina o risco.
RAID 10 e espelhamento: o erro que passa despercebido
RAID 10 combina espelhamento e striping: cada bloco existe em pelo menos duas cópias físicas. Um erro de leitura em um dos espelhos é corrigido silenciosamente pelo controlador, que lê a cópia boa e reescreve o setor defeituoso. O usuário nunca vê o alerta — e é exatamente esse o perigo.
Como o erro não gera notificação em muitos controladores, o disco com setores pendentes continua no array indefinidamente. Quando o espelho saudável falhar, o array inteiro cai de uma vez, porque o “backup” silencioso já estava comprometido há semanas ou meses. Monitorar SMART individualmente por disco é a única forma de detectar essa degradação invisível em RAID 10.
Erro de leitura em NAS, storage corporativo e servidor: as camadas que ninguém vê
Em ambientes corporativos, o RAID raramente é a camada final. Acima dele existem volumes lógicos, pools de armazenamento, sistemas de arquivos com journaling e, em muitos casos, virtualização. O erro de leitura que o controlador reporta é apenas a ponta visível de uma pilha complexa — e cada camada reage ao evento de forma diferente.
Um NAS doméstico com ext4 ou Btrfs sobre MDADM, um storage com ZFS e um servidor Windows com Storage Spaces tratam erro de leitura com políticas próprias. O mesmo setor ilegível pode ser corrigido por checksum no ZFS, ignorado pelo ext4 ou transformado em tela azul no Windows, dependendo de onde a falha acontece na pilha.
Sistemas de arquivos, volumes e pools acima do RAID
O ZFS e o Btrfs mantêm checksum de cada bloco e conseguem detectar corrupção silenciosa que o RAID tradicional não vê — mas dependem de redundância para corrigir. Se o pool está sem espelho ou paridade suficiente, o checksum apenas confirma que o dado está corrompido, sem conseguir reconstruí-lo.
Já sistemas de arquivos sem checksum, como ext4 e NTFS, confiam cegamente no que o controlador RAID entrega. Se o RAID devolve dado corrompido sem alertar, o sistema de arquivos grava a corrupção como se fosse conteúdo legítimo. Em cenários de erro de leitura parcial, o arquivo pode abrir com trechos ilegíveis, sem nenhum aviso de integridade.
Cache de leitura, cache de escrita e write hole
Controladores RAID com cache de escrita protegido por bateria ou flash melhoram performance, mas introduzem o problema do write hole: se houver queda de energia entre a gravação do dado e a gravação da paridade correspondente, o stripe fica com paridade inconsistente. Quando um disco falhar depois, o rebuild recalcula dados errados a partir dessa paridade corrompida.
O write hole é uma falha silenciosa clássica: o array reporta estado ótimo, os discos passam nos testes, mas a paridade está dessincronizada do dado. Só aparece quando um disco falha e o rebuild entrega arquivos corrompidos. RAID 6 reduz a probabilidade por ter duas paridades, mas não elimina o problema sem journaling dedicado ou copy-on-write no nível do sistema de arquivos.
Quando o RAID está acessível, mas os dados não abrem
O cenário mais desorientador é o array subir normalmente, com todos os discos online, e ainda assim os arquivos não abrirem ou abrirem corrompidos. Isso indica que a corrupção já aconteceu no nível lógico: paridade inconsistente gravada, rebuild anterior mal sucedido ou sistema de arquivos com metadados danificados.
Nesse caso, a prioridade não é consertar o RAID — é preservar o estado atual e extrair os dados por clonagem. Qualquer tentativa de “reparar” o sistema de arquivos com fsck ou chkdsk pode reescrever estruturas e destruir a última chance de montagem consistente. O mesmo vale para ferramentas de recuperação caseira executadas diretamente sobre o array montado.
Diagnóstico antes da recuperação: como separar falha de mídia de falha lógica
Antes de qualquer tentativa de remontagem, é preciso saber se o problema está na mídia física, na configuração do array ou no sistema de arquivos. Os três exigem abordagens diferentes — e tratar falha física como se fosse lógica é o erro que mais agrava casos de RAID com erro de leitura.
O diagnóstico começa pela leitura dos atributos SMART de cada disco individualmente, fora do array. Setores realocados, setores pendentes, erros de leitura crua e horas de operação dão o primeiro mapa de saúde. Em seguida, cada membro é clonado setor a setor para mídia íntegra, isolando a degradação física antes de qualquer operação lógica.
Leitura setor a setor e clonagem controlada dos membros
A clonagem setor a setor é diferente de copiar arquivos: ela lê cada setor físico na ordem do disco, incluindo áreas não alocadas, metadados do RAID e setores defeituosos. Equipamentos de clonagem forense controlam voltagem, temperatura e número de tentativas de leitura por setor, maximizando a extração de mídias com degradação.
Em discos com cabeçote danificado ou mídia raspada, a clonagem pode exigir intervenção em sala limpa — substituição de cabeçote, doação de placa ou estabilização de firmware. Tentar clonar um disco nessas condições com software comum multiplica os setores ilegíveis e pode inviabilizar a recuperação. A regra é clonar primeiro, montar depois.
Ordem dos discos, offset e parâmetros do conjunto
Para remontar um array a partir dos clones, é preciso reconstruir exatamente os parâmetros originais: ordem dos discos, tamanho do stripe, offset inicial, rotação de paridade e nível de RAID. Um único parâmetro errado produz um volume ilegível, mesmo com todos os clones íntegros.
Esses metadados ficam gravados no início de cada disco em controladores por hardware, mas podem estar ausentes ou corrompidos em RAID por software. A análise manual do padrão de dados nos clones — identificando onde a paridade se repete e onde o stripe começa — é o que permite reconstruir a geometria quando os metadados se perderam.
O que um rebuild concluído não garante
Um rebuild que chega a 100% não valida a integridade dos dados. Ele apenas recalculou o conteúdo do disco substituído a partir da paridade e dos demais membros. Se a paridade estava inconsistente ou se algum setor ilegível foi pulado, o rebuild entrega um disco “novo” com dados corrompidos — e o controlador reporta sucesso.
Por isso, após qualquer rebuild concluído, é necessário validar o sistema de arquivos e testar a abertura de arquivos representativos. Se o rebuild foi feito sobre um array com histórico de erro de leitura, a validação precisa incluir comparação de checksums quando disponíveis. Rebuild concluído não é sinônimo de dados recuperados.
O que define o custo de uma recuperação de RAID com erro de leitura
O custo de uma recuperação de RAID com erro de leitura não é tabelado porque depende de variáveis que só o diagnóstico revela. A quantidade de discos com falha física, a necessidade de sala limpa, o nível de RAID, a complexidade da geometria e a urgência do prazo são os fatores que mais pesam.
- Número de discos com falha física: cada mídia que exige troca de cabeçote ou doação de placa adiciona complexidade.
- Necessidade de sala limpa: abertura de disco exige ambiente controlado, com custo de insumos e peças doadoras.
- Nível de RAID e geometria: RAID 6 e RAID 60 com paridade rotativa exigem mais tempo de análise que RAID 1.
- Urgência: atendimento prioritário com parada operacional tem custo diferente do prazo padrão.
- Estado do sistema de arquivos: corrupção lógica sobreposta à falha física aumenta as etapas de reconstrução.
O ponto central é que o custo tende a subir quando o equipamento foi manipulado antes do diagnóstico — rebuilds forçados, comandos de force online e tentativas caseiras gravam sobre setores que poderiam ser lidos. Quanto mais cedo o array é encaminhado sem intervenção, menor a complexidade e, em geral, menor o custo final.
Backup, monitoramento e verificações que evitam o próximo erro de leitura
Erro de leitura é, na maioria dos casos, consequência de degradação que poderia ter sido detectada antes. O monitoramento contínuo dos atributos SMART e a verificação periódica de paridade são as duas ferramentas que transformam um colapso súbito em manutenção programada.
Ambientes corporativos que operam storages e servidores críticos precisam ir além do alerta padrão do controlador. Notificação por e-mail ou integração com sistema de monitoramento quando setores pendentes aparecem, quando a temperatura sobe ou quando a taxa de erros de leitura aumenta é o que permite agir antes do segundo disco falhar.
Verificação de paridade e varredura de superfície: com que frequência
A verificação de paridade lê todos os stripes e confirma se o dado e a paridade batem. Em arrays empresariais, a recomendação prática é executá-la mensalmente ou trimestralmente, dependendo do tamanho do volume e da janela de manutenção. Em NAS domésticos, a varredura mensal é um bom ponto de partida para volumes usados diariamente.
A varredura de superfície vai além: ela força a leitura de cada setor de cada disco e força a realocação de setores pendentes antes que virem erros não corrigíveis. Deve ser executada com a mesma periodicidade da verificação de paridade, de preferência em horário de baixa carga. O custo é tempo de leitura intensiva — o benefício é encontrar o disco frágil antes do rebuild.
Por que RAID não é backup e o que muda com um erro de leitura
RAID protege contra falha de disco, não contra perda de dados. Erro de leitura, corrupção de paridade, exclusão acidental, ransomware e falha de controlador são eventos que o RAID não cobre — e alguns deles, como o write hole, são criados pelo próprio RAID. A regra é redundância para disponibilidade, backup para recuperação.
Com histórico de erro de leitura, a regra fica ainda mais crítica: o array que já apresentou setores ilegíveis não pode ser considerado fonte confiável para o backup. A cópia de segurança precisa ser validada, e o array, substituído ou recomposto com discos novos antes que o próximo erro de leitura aconteça durante um rebuild. A sequência correta é clonar, diagnosticar, recuperar — e só então reconstruir o ambiente.
