Aprenda a reconhecer os sinais de falha de storage antes que eles virem catástrofe — e o que fazer quando o RAID não salva o que você pensava que salvaria.
Era uma sexta-feira. O servidor de arquivos do departamento jurídico estava devagar. “Deve ser o Wi-Fi”, disse o gestor. “Deve ser o sistema”, disse outro. O chamado abriu às 14h com prioridade baixa: “acesso lento à pasta compartilhada”.
O técnico que atendeu verificou a rede — normal. Verificou o servidor — normal. Reiniciou o serviço. O chamado foi fechado às 14h40: “resolvido”.
Às 16h, o chamado voltou. Agora com reclamação de arquivos corrompidos. O técnico reiniciou o servidor inteiro.
Às 18h, o servidor não subiu mais.
Na segunda-feira, a empresa descobriu que tinha perdido os contratos dos últimos quatro anos. O RAID 0 que “protegia” os dados havia simplesmente multiplicado a velocidade da perda — quando o segundo disco falhou, foi tudo de uma vez.
O sinal estava lá desde às 14h. Aquele som estranho que o técnico não ouviu porque fechou o chamado remotamente.
Este post cobre o Objetivo 5.2 do CompTIA A+ Core 1 (220-1201 V15): troubleshooting de drives e arrays RAID. O domínio 5.0 representa 28% do exame — e storage é onde as questões situacionais ficam mais pesadas.
O que o exame quer que você saiba fazer
O objetivo 5.2 não testa se você sabe o que é um HDD. Ele testa se você sabe o que fazer quando um HDD está morrendo — e se você sabe a diferença entre os cenários onde os dados podem ser recuperados e os onde não podem.
Duas categorias dominam o objetivo: sintomas de falha de storage e falhas de RAID. SMART data e IOPS aparecem como ferramentas de diagnóstico transversais. Vamos por partes.
Parte 1 — Sintomas de falha de storage
Drives não morrem de surpresa. Eles avisam. O problema é que os avisos são sutis — e quem não sabe o que procurar fecha o chamado como “resolvido” antes do desastre.
Grinding noise (barulho de trituração)
Exclusivo de HDDs mecânicos. Quando você ouve um barulho de arranhado, clique repetitivo ou chiado metálico vindo de um HD, a cabeça de leitura/gravação está tocando o prato. Isso é catastrófico e irreversível na maioria dos casos.
O que fazer: pare de usar o drive imediatamente. Cada operação de leitura ou escrita depois desse barulho aumenta o dano físico e reduz a chance de recuperação de dados. Se há dados sem backup, a próxima ligação é para um serviço de recuperação de dados especializado — não para reinstalar o SO.
SSDs não fazem esse barulho. Se o barulho vier de um SSD, investigate o cooler ou o gabinete.
“Cannot read from the source disk” (erro de leitura)
Essa mensagem — e suas variações como “Disk read error”, “No bootable device”, “Operating system not found” — indica que o sistema não consegue ler dados do drive de forma confiável.
Pode ser:
- Área específica do disco danificada (bad sectors)
- Problema intermitente de conexão (cabo SATA solto)
- Drive em falha progressiva tentando reler o mesmo setor repetidamente
A LED de atividade do disco piscando constantemente sem parar, mesmo sem operações do usuário, é o sinal visual desse comportamento. O drive está em loop tentando recuperar dados que não consegue mais ler.
Data loss e corrupção
Arquivos que somem, pastas que aparecem vazias, documentos que abrem corrompidos — esses sintomas indicam que o sistema de arquivos foi comprometido.
Causas prováveis: bad sectors em áreas críticas (MFT no NTFS, por exemplo), falha de escrita durante operação com energia cortada, ou drive em estágio avançado de falha.
CHKDSK (Windows) e fsck (Linux) são as ferramentas de reparo do sistema de arquivos — não de recuperação de dados. Eles podem corrigir inconsistências lógicas, mas não recuperam dados fisicamente perdidos.
Drive not recognized (drive não reconhecido)
O sistema simplesmente não vê o drive no BIOS/UEFI ou no gerenciador de discos.
Diagnóstico em sequência:
- Verificar conexão física (cabo SATA, alimentação, encaixe M.2)
- Testar em outra porta SATA ou slot M.2
- Testar o cabo com outro dispositivo
- Verificar se o drive aparece em outro sistema
- Se não aparecer em nenhum sistema, o problema é no próprio drive
Um drive que aparece no BIOS mas não no sistema operacional pode ter problema de particionamento ou sistema de arquivos — situação diferente de um drive que não aparece nem no BIOS.
Slow performance (desempenho lento)
Lentidão de storage tem causas variadas. As mais comuns:
- Disco próximo do limite de capacidade: HDDs mecânicos perdem desempenho progressivamente acima de 80–85% de uso. SSDs podem degradar em escrita acima de ~90%.
- Drive fragmentado: afeta apenas HDDs mecânicos — SSDs não se fragmentam de forma relevante e desfragmentar um SSD causa desgaste desnecessário.
- Bad sectors forçando releituras: cada tentativa de reler um setor danificado introduz latência adicional.
- Modo de economia de energia: drives que “dormem” frequentemente introduzem latência na primeira acesso após o sleep.
IOPS (Input/Output Operations Per Second) é a métrica que quantifica essa lentidão. Um HDD mecânico típico entrega 100–200 IOPS. Um SSD SATA entrega 50.000–100.000 IOPS. Um NVMe moderno, 500.000+ IOPS. Quando os IOPS medidos estão abaixo do esperado para aquele tipo de drive, algo está errado.
Parte 2 — SMART: o sistema que já sabe antes de você
SMART — Self-Monitoring, Analysis, and Reporting Technology — é o sistema de telemetria integrado nos drives modernos. Ele monitora dezenas de atributos internos em tempo real: horas de uso, setores realocados, taxa de erros de leitura, temperatura, tempo de spin-up, e muito mais.
O que torna o SMART valioso não é o valor atual de cada atributo — é a tendência ao longo do tempo. Um contador de setores realocados que aumenta a cada semana é um sinal muito mais importante do que seu valor absoluto.
Ferramentas que acessam SMART data:
- CrystalDiskInfo (Windows, gratuito) — interface visual clara com alerta de status
- HD Tune (Windows) — análise de saúde e teste de superfície
- smartmontools (Linux/macOS) — linha de comando, muito usado em servidores
- Painel de gerenciamento dos próprios RAID controllers — arrays empresariais enviam e-mail ou SMS quando um drive começa a degradar
Quando o SMART reporta “Warning” ou “Bad”, não é hora de esperar. É hora de fazer backup imediatamente e planejar a troca do drive. O erro SMART não se resolve sozinho.
Parte 3 — Falhas de RAID: quando a redundância não é o que parece
RAID não é backup. Essa distinção importa muito na prova — e na vida real.
Quando um drive do array falha, o RAID controller geralmente sinaliza o problema com um LED âmbar (ou vermelho, dependendo do fabricante) no bay do drive com problema. LED verde piscando intermitentemente = operação normal. LED âmbar sólido = drive em estado degradado ou falho.
O que acontece após a falha depende inteiramente do nível de RAID:
| Nível RAID | Mín. de drives | Sobrevive à falha de 1 drive? | Reconstrução automática? |
|---|---|---|---|
| RAID 0 | 2 | ❌ Não — perda total dos dados | Não aplicável |
| RAID 1 | 2 | ✅ Sim | Sim, com drive substituto |
| RAID 5 | 3 | ✅ Sim (apenas 1 drive) | Sim, com drive substituto |
| RAID 10 | 4 | ✅ Sim (1 drive por par espelhado) | Sim, com drive substituto |
RAID 0 é striping puro — os dados são distribuídos entre os drives para maximizar desempenho, sem redundância. A falha de qualquer drive destrói o array inteiro. O que a história de abertura deste post ilustrou.
RAID 1 espelha os dados em dois drives. Se um falha, o outro continua operacional — mas você está rodando degradado e precisa substituir e reconstruir o mais rápido possível.
RAID 5 distribui dados e paridade entre três ou mais drives. Um drive pode falhar e o array continua — os dados do drive perdido são reconstruídos a partir da paridade. Durante a reconstrução, o array é mais vulnerável: se um segundo drive falhar nesse período, tudo se perde.
RAID 10 combina espelhamento e striping. Você pode perder um drive de cada par espelhado e ainda continuar operando.
O processo de substituição de drive em RAID
Quando você substitui um drive falho em um array RAID 1, 5 ou 10:
- Identifique o drive correto pelo LED ou pelo software de gerenciamento do RAID controller — nunca retire um drive “na intuição”
- Substitua pelo drive correto: mesma capacidade, de preferência o mesmo modelo
- O RAID controller inicia a reconstrução automaticamente
- Durante a reconstrução, o LED do novo drive vai piscar intensamente — isso é normal, não é outro drive falhando
- O tempo de reconstrução depende do tamanho do array: terabytes de dados podem levar horas
Regra crítica: nunca retire um segundo drive durante uma reconstrução. Um array RAID 5 com um drive falhado e uma reconstrução em andamento é tão frágil quanto um RAID 0.
Parte 4 — Diagnóstico de drives externos
Drives externos têm uma camada adicional de variáveis: o enclosure (o case), o cabo USB, e a porta do computador — qualquer um dos três pode simular sintomas de falha de drive.
Protocolo de diagnóstico para drive externo não reconhecido:
- Testar com outro cabo USB
- Testar em outra porta USB (e de preferência em outra versão: USB 3.0 vs 2.0)
- Testar em outro computador
- Verificar se o drive aparece no Gerenciador de Dispositivos com erro de driver
- Se o drive aparece mas não tem letra de unidade: abrir Gerenciamento de Disco e verificar se precisa de inicialização ou letra atribuída
- Se os passos anteriores falharem, remover o drive do enclosure e conectar internamente (SATA diretamente)
Um drive que funciona como SATA interno mas falha no enclosure USB indica problema no bridge chip do enclosure — não no drive em si.
Tabela de referência rápida: sintomas → diagnóstico → ação
| Sintoma | Diagnóstico provável | Primeira ação |
|---|---|---|
| Barulho de grinding/clique | Falha mecânica (HDD) | Parar uso, salvar dados imediatamente |
| Cannot read from source disk | Bad sectors ou falha progressiva | Verificar SMART, backup urgente |
| Drive não aparece no BIOS | Problema físico (cabo, alimentação, drive) | Verificar conexões físicas |
| Drive aparece no BIOS, não no SO | Problema de partição/sistema de arquivos | Gerenciador de Discos, CHKDSK |
| Arquivos corrompidos | Sistema de arquivos danificado | CHKDSK /f /r, verificar SMART |
| Lentidão extrema | Disco cheio, bad sectors, modo sleep | Liberar espaço, verificar SMART, IOPS |
| SMART Warning/Bad | Drive em degradação | Backup imediato, planejar substituição |
| LED âmbar no servidor | Drive do RAID em falha | Identificar drive, substituir, monitorar reconstrução |
| Array RAID 0 inativo | Drive falhou | Restaurar backup — não há outra opção |
| Array RAID 1/5/10 degradado | Um drive falhou | Substituir drive, aguardar reconstrução |
Bypass consciente
Este post cobre os sintomas e o raciocínio de diagnóstico que o exame V15 cobra no objetivo 5.2. O que ficou de fora intencionalmente: os atributos específicos do SMART e seus limiares críticos (Raw Read Error Rate, Reallocated Sectors Count, Spin Retry Count), as diferenças entre RAID por hardware e RAID por software no contexto de falhas, e o comportamento de SSDs NVMe em falhas comparado aos SSDs SATA.
O documento oficial de objetivos está em comptia.org/training/certifications/a. O que o exame cobra no 5.2 está listado exatamente lá — na língua em que a prova vai ser aplicada.
No próximo post
Storage solucionado. Agora subimos para a tela.
Você já viu situações onde o display mostra artefatos visuais, linhas verticais, ou imagem completamente preta — mas você não sabe se o problema está na GPU, no cabo, no monitor, ou no driver. No Post 17, entramos no Objetivo 5.3: troubleshooting de vídeo, projetores e displays. O tipo de diagnóstico onde trocar o componente errado custa caro — e onde o método correto economiza tempo e peças.