RAID Degraded — O Que Significa e O Que Fazer Agora
O alerta de RAID degraded é o aviso que todo administrador de TI teme receber — especialmente fora do horário comercial. O LED vermelho acende no servidor, a controladora dispara o e-mail de notificação, o painel do NAS exibe “volume degraded” e a primeira pergunta é sempre a mesma: o que isso significa na prática, o servidor ainda está funcionando, e o que devo fazer agora?
Este guia responde exatamente essas perguntas — com a precisão técnica que o momento exige e sem o excesso de calma que situações urgentes não comportam.
O Que Significa RAID Degraded — A Definição Precisa
RAID degraded significa que o array perdeu um ou mais discos membros mas ainda não ultrapassou o limite de tolerância a falhas do nível configurado. O volume continua montado, os dados continuam acessíveis e o servidor continua operando — mas a redundância que protegia os dados foi parcial ou totalmente consumida pela falha.
A distinção entre os estados possíveis do array é fundamental para entender a urgência:
Degraded indica que o array perdeu discos dentro do limite de tolerância. Um RAID 5 com um disco falhado está degradado mas operacional. Um RAID 6 com um disco falhado está degradado mas ainda tem uma camada de proteção restante. O volume monta, os dados são acessíveis, mas qualquer nova falha pode colapsar tudo.
Offline ou Failed indica que o array ultrapassou o limite de tolerância — dois discos em RAID 5, três em RAID 6. O volume não monta mais e os dados estão inacessíveis. Esse estado exige intervenção laboratorial, não administrativa.
Foreign Configuration indica que a controladora perdeu os metadados do array — geralmente após troca de controladora ou reinicialização após corrupção de firmware. Os discos estão presentes mas a controladora não os reconhece como array válido.
Quando o painel exibe “degraded”, você está no primeiro cenário — o menos crítico dos três, mas que exige ação imediata porque a janela de segurança é finita e imprevisível.
RAID Degraded Ainda Funciona — Por Quanto Tempo é Seguro Usar?
Sim, um array em estado degraded continua funcionando. Os dados são lidos e escritos normalmente pelo sistema operacional e pelas aplicações. Para os usuários finais que acessam os arquivos compartilhados ou o banco de dados hospedado no servidor, nada mudou visivelmente. Essa continuidade operacional é exatamente o propósito do RAID — absorver a falha de um disco sem interromper o serviço.
O problema é que essa continuidade cria uma falsa sensação de segurança. O array está funcionando, mas está funcionando sem rede de proteção. Se um segundo disco falhar — por qualquer motivo — enquanto o array está degraded, o volume vai offline instantaneamente e os dados ficam inacessíveis. Não há aviso adicional, não há tempo de reação. A falha do segundo disco é o colapso definitivo.
Quanto tempo você tem? Não existe resposta precisa — e essa incerteza é o ponto central. Um disco pode falhar amanhã ou em seis meses. O que determina a urgência não é o tempo absoluto, mas três fatores concretos:
O primeiro é a idade dos discos sobreviventes. Discos comprados juntos, do mesmo fabricante e lote, envelhecem juntos. Se o disco que falhou tinha cinco anos de uso intensivo, os demais têm a mesma idade e o mesmo desgaste acumulado. A falha de um disco do lote aumenta estatisticamente a probabilidade de falha dos demais nas semanas seguintes — porque todos chegaram ao mesmo ponto de desgaste aproximadamente ao mesmo tempo.
O segundo é a carga sobre os discos sobreviventes durante o período degraded. Com um disco a menos, a controladora distribui toda a carga de leitura e escrita entre os discos restantes — aumentando o estresse mecânico sobre hardware que já mostrou sinais de desgaste ao perder um membro do array. Ambientes de alto I/O — servidores de banco de dados, hosts VMware com múltiplas VMs ativas, servidores de arquivos com acesso intenso — aceleram esse desgaste.
O terceiro é o estado SMART dos discos sobreviventes. Se qualquer disco sobrevivente exibe setores realocados em crescimento, temperatura acima do normal ou erros de leitura registrados, a probabilidade de falha iminente é alta. Consultar o SMART imediatamente após identificar o estado degraded é a primeira ação técnica recomendada.
A resposta prática para “por quanto tempo é seguro?” é: o suficiente para fazer backup completo dos dados críticos antes de qualquer outra decisão. Não dias — horas.
RAID Degraded por Nível — A Urgência é Diferente
O estado degraded tem implicações distintas dependendo do nível de RAID configurado, porque cada arquitetura tem uma margem de tolerância diferente.
RAID 5 degraded com um disco falhado é o cenário de maior urgência. O RAID 5 tolera exatamente um disco com falha — não dois. Com um disco perdido, o array opera em modo de reconstrução matemática em tempo real: cada leitura exige que a controladora recalcule os dados do disco ausente a partir da paridade e dos demais discos. Esse recálculo em tempo real aumenta a latência de leitura e a carga sobre os discos sobreviventes. O RAID 5 degraded não tem nenhuma margem adicional — a próxima falha, de qualquer magnitude, colapsa o volume.
RAID 6 degraded com um disco falhado tem uma margem adicional — o RAID 6 tolera dois discos com falha simultânea graças à paridade dupla com algoritmo Reed-Solomon. Com um disco perdido, o array ainda tem uma camada de proteção restante. A urgência é real mas ligeiramente menor do que no RAID 5 degraded. Com dois discos falhados, o RAID 6 entra em estado crítico equivalente ao RAID 5 com um disco — qualquer falha adicional derruba tudo.
RAID 10 degraded com um disco falhado depende de qual disco falhou. O RAID 10 é estruturado em pares espelhados — se o disco que falhou pertence a um par cujo espelho ainda está íntegro, o array continua com proteção parcial. Se o disco cujo par também está em degradação falhar, o volume vai offline. A urgência é alta e depende do estado do par espelhado do disco falhado.
RAID 1 degraded é o estado de menor margem absoluta — com dois discos, a falha de um significa que há exatamente uma cópia dos dados sem nenhuma redundância. O disco sobrevivente é ao mesmo tempo a única cópia dos dados e o único ponto de falha. Qualquer falha desse disco resulta em perda total.
O LED Vermelho Acendeu Às 3h da Manhã — O Que Fazer Agora
O cenário mais comum de recebimento desse alerta é fora do horário comercial — o sistema de monitoramento dispara a notificação, o administrador de plantão recebe no celular, e a pergunta é o que fazer antes do expediente.
A primeira ação é confirmar qual disco está marcado como falhado e em qual baia física ele está. A controladora — Dell PERC, HPE Smart Array, LSI MegaRAID — ou o painel do NAS — Synology DSM, QNAP QTS — identifica o disco pelo número de slot ou baia. Não trocar nada ainda.
A segunda ação é verificar o SMART dos discos sobreviventes via interface da controladora ou via ferramenta de monitoramento. Qualquer disco com “Predictive Failure”, setores realocados em número crescente ou temperatura acima de 55°C deve ser tratado como candidato a falha iminente. Essa informação determina se o array pode esperar até o expediente comercial ou se a situação exige ação imediata.
A terceira ação — e a mais importante — é não iniciar o rebuild. O rebuild automático parece a resposta óbvia e correta, mas é exatamente a ação que transforma um cenário controlável em catástrofe. O rebuild força todos os discos sobreviventes a lerem 100% de sua capacidade de forma sequencial e contínua por horas ou dias para recalcular os dados do disco perdido. Se qualquer disco sobrevivente tem bad blocks silenciosos — setores com degradação que o SMART ainda não registrou como realocados — o processo de rebuild vai encontrá-los sob carga máxima, em temperatura elevada, com as cabeças de leitura sob estresse contínuo. O resultado frequente é um segundo disco falhando durante o rebuild, colapsando o array com dados parcialmente sobrescritos pelo processo de reconstrução.
A regra é clara: não inicie o rebuild antes de ter backup completo validado dos dados críticos.
A quarta ação é fazer backup imediato dos arquivos mais críticos para mídia externa — enquanto o array ainda está degraded e os dados ainda estão acessíveis. Priorizar os dados que não podem ser reproduzidos: bancos de dados, projetos em andamento, arquivos de configuração de sistemas. Se o array colapsar antes do backup estar completo, esses são os dados que determinam se a operação para ou continua.
O Rebuild Já Iniciou — Devo Parar ou Deixar Terminar?
Esse é um dos cenários mais delicados — e a resposta depende de onde o rebuild está e do que está acontecendo com os discos durante o processo.
Se o rebuild iniciou há pouco tempo e os discos sobreviventes mostram SMART saudável sem setores realocados, sem temperatura elevada e sem erros de leitura, e o processo está avançando de forma constante sem travar — deixar terminar é razoável, monitorando ativamente a cada hora.
Se o rebuild travou em alguma porcentagem e não avança há mais de 30 minutos, isso indica que a controladora encontrou um setor ilegível em um dos discos sobreviventes e está em loop de releituras tentando resolver. Nesse estado, cada minuto adicional de rebuild está causando dano mecânico progressivo sobre o disco que travou. A ação correta é interromper o rebuild imediatamente, desligar o servidor de forma controlada e encaminhar para diagnóstico especializado. Um rebuild interrompido é recuperável em laboratório — um disco que entrou em Head Crash durante um rebuild travado frequentemente não é.
Se durante o rebuild apareceu alerta de segundo disco em falha ou degradação, interromper imediatamente e desligar o servidor. Cada segundo adicional de rebuild com dois discos comprometidos aumenta o risco de sobrescrita dos blocos de paridade que ainda permitiriam a recuperação forense.
Se o rebuild completou com sucesso — o painel exibe “optimal” ou “healthy” —, verificar imediatamente a integridade dos dados críticos antes de assumir que tudo está correto. Um rebuild completado com erros silenciosos pode ter produzido um array aparentemente saudável com dados corrompidos em regiões específicas.
O Que Não Fazer Quando o RAID Está Degraded
Existem quatro ações que transformam um estado degraded — controlável — em colapso definitivo, e todas elas parecem intuitivamente razoáveis para quem não conhece a arquitetura interna do RAID.
Não force discos offline de volta ao online sem diagnóstico. Um disco que a controladora marcou como falhado foi removido do array por algum motivo — bad blocks, timeout de leitura, erro de firmware ou falha mecânica. Forçar o disco de volta ao estado online sem entender a causa pode fazer a controladora tentar reintegrar um disco instável ao array, potencialmente sobrescrevendo blocos de paridade com dados corrompidos.
Não troque o disco falhado por um novo e inicie o rebuild sem backup validado. A reposição do disco e o rebuild subsequente é a sequência correta — mas apenas após backup confirmado dos dados críticos. O rebuild é uma operação de alto risco em discos com desgaste acumulado, e iniciar sem backup elimina a última rede de segurança disponível.
Não conecte os discos do array em outra controladora diferente da original para tentar acessar os dados. Controladoras de diferentes fabricantes, gerações ou configurações gravam metadados proprietários nos primeiros setores de cada disco. Uma controladora nova pode interpretar esses metadados como configuração foreign e sobrescrever as informações do array original ao tentar importar — destruindo permanentemente o mapa que permitiria a recuperação.
Não reinicie o servidor repetidamente na esperança de que o array volte ao estado normal. Cada reinicialização força a controladora a tentar remontar o array com base nos metadados disponíveis — e em um estado degraded com firmware instável ou metadados parcialmente corrompidos, cada tentativa de remontagem pode modificar esses metadados de forma que reduz as opções de recuperação disponíveis.
RAID Degraded em NAS Synology, QNAP e NAS Corporativo — Diferenças Práticas
O estado degraded em NAS de consumo e corporativo tem algumas particularidades em relação aos servidores com controladoras de hardware dedicadas.
No Synology DSM, o alerta de “volume degraded” ou “volume crashed” aparece no painel Storage Manager. O sistema SHR — Synology Hybrid RAID — tem comportamento específico que difere do RAID padrão: por ser construído sobre o gerenciador de volumes Linux LVM com sub-RAIDs ocultos, a mensagem de degraded no DSM nem sempre corresponde diretamente à falha de um único disco físico identificável. Um volume SHR degraded pode indicar desde a falha simples de um disco até inconsistência nos metadados LVM — e a diferença entre os dois determina completamente a abordagem correta.
No QNAP QTS, o alerta “RAID degraded” ou “disk missing” aparece no Storage & Snapshots. Os NAS QNAP da linha enterprise com QuTS Hero usam ZFS — e um zpool ZFS em estado DEGRADED tem comportamento distinto do RAID convencional: o ZFS mantém checksums de todos os dados e pode detectar e corrigir corrupção silenciosa usando as cópias de paridade disponíveis, mesmo em estado degraded. Isso torna o ZFS degraded ligeiramente mais resiliente, mas a urgência de substituição do disco falhado e backup preventivo continua sendo alta.
Em ambos os casos, a regra mais importante é não executar os comandos de reparo sugeridos pelo próprio sistema — “Repair volume”, “Rebuild now”, “Fix degraded array” — sem antes confirmar que todos os dados críticos estão em backup validado fora do NAS. Os botões de reparo automático nos painéis de NAS iniciam o rebuild com um clique e sem confirmação adicional do estado dos discos sobreviventes.
Quando o RAID Degraded Já Colapsou — O Array Foi Offline
Se ao ler este guia o array já passou do estado degraded para offline — dois discos falhados em RAID 5, volume não monta mais, dados inacessíveis —, as regras mudam completamente.
Nesse estado, não existe ação administrativa que resolva o problema. Não existe rebuild possível, não existe software que monte o volume, não existe configuração de controladora que devolva o acesso. O array está matematicamente inacessível porque os blocos de paridade necessários para reconstruir os dados dos discos perdidos não estão mais disponíveis em número suficiente.
A única intervenção viável é a recuperação de RAID forense em laboratório especializado — clonagem forense de cada disco individualmente, engenharia reversa dos parâmetros do array e remontagem virtual do volume sem nenhuma escrita nos discos originais. Essa é a abordagem que a E-Recovery aplica nesses casos: o array é reconstruído matematicamente em ambiente de laboratório, sem depender da controladora original e sem nenhum risco adicional às mídias.
As ações que preservam as chances de recuperação nesse estado são simples: desligar o servidor imediatamente, não tentar nenhuma intervenção adicional, fotografar o estado da controladora e a ordem dos discos nas baias, e encaminhar para diagnóstico forense com o histórico completo de o que aconteceu e o que foi tentado antes.
Seu RAID Está Degraded ou Offline? Fale Agora com um Especialista.
Um array em estado degraded tem janela de ação — mas ela é finita. A E-Recovery atende casos de RAID degraded, rebuild travado e array offline com diagnóstico gratuito em até 48 horas e atendimento emergencial 24×7. PC-3000, DeepSpar e mais de 20 anos de casos com Dell PERC, HPE Smart Array, Synology, QNAP e LSI MegaRAID.
→ Solicitar diagnóstico emergencial para RAID degraded ou offline
Endereço:
Av Professor Noé de Avevedo 208 cj 65 - Vila Mariana - São Paulo/SP - CEP 04117-000
Telefone / WhatsApp
Voz: (11) 3422-0066
WhatsApp: (11) 93075-5919
contato@e-recovery.com.br
