RAID parou de funcionar: o que fazer nas primeiras horas?

O servidor não inicializa, o NAS desapareceu da rede ou a controladora passou a exibir discos como “foreign” ou “failed”: quando o RAID parou de funcionar, a pressa costuma ser o pior conselheiro. Este texto reúne um checklist das ações imediatas para preservar os dados nas primeiras horas, mostra o que nunca fazer antes de um diagnóstico e ajuda a decidir quando vale tentar sozinho e quando é hora de acionar um especialista.

RAID parou de funcionar: o que fazer nas primeiras horas

Quando um array RAID para de responder, a diferença entre recuperar os dados e perdê-los de forma definitiva costuma ser decidida nas primeiras horas — e quase sempre pelas ações que não são tomadas. O cenário típico envolve um servidor que não inicializa, um NAS que sumiu da rede ou uma controladora que passou a exibir discos como “foreign”, “failed” ou “offline”. O impulso imediato de reiniciar, reconstruir o array ou aceitar a sugestão de inicialização do utilitário da controladora é exatamente o que transforma uma falha contornável em perda irrecuperável.

Em RAID 5, por exemplo, um único disco com falha mantém os dados íntegros por paridade; a degradação é tolerável e o array continua acessível. Já em RAID 0, não há redundância: a falha de um único disco compromete o volume inteiro. O primeiro passo, portanto, não é “consertar”, e sim estabilizar o ambiente: desligar gravações automáticas, suspender backups que possam sobrescrever o volume, impedir que o sistema operacional monte o array em modo leitura/gravação e documentar tudo antes de qualquer intervenção. Cada minuto de operação com um array em estado inconsistente é uma chance de corrupção adicional nos metadados.

Também vale registrar o comportamento exato da falha: o servidor liga e trava no POST? A BIOS enxerga os discos? O painel da controladora acusa disco ausente ou preditivo de falha? O volume aparece no sistema, mas some ao acessar determinada pasta? Esses sintomas direcionam o diagnóstico e evitam que o técnico — interno ou externo — precise reproduzir o problema, o que por si só já é arriscado. A regra prática é tratar o array como cena de um incidente: preservar antes de investigar.

Antes de qualquer coisa: pare de escrever nos discos

Um array RAID degradado ainda processa leituras e gravações, e é justamente a gravação contínua que corrompe a estrutura lógica de forma progressiva. Quando um disco é marcado como falho e o array continua ativo, a controladora recalcula paridade e reescreve setores nos discos restantes. Se a falha original não era física, mas sim de dessincronização ou de firmware, essas gravações sobrescrevem dados que ainda poderiam ser recuperados. Por isso, a primeira instrução técnica é interromper toda e qualquer escrita no volume afetado.

Isso inclui desativar tarefas agendadas, serviços de indexação, snapshots automáticos, replicação e qualquer rotina de backup que tenha o array como origem ou destino. Em sistemas Linux com mdadm, o ideal é remontar o array como somente leitura ou, melhor ainda, não montá-lo e trabalhar apenas com imagens dos discos. Em controladoras de hardware, o comando de “import foreign configuration” deve ser evitado até que a ordem dos discos e o estado de cada membro estejam documentados.

Por que cada tentativa de rebuild pode destruir a chance de recuperação

O rebuild é o processo de reconstruir os dados de um disco substituto a partir da paridade ou do espelhamento dos demais. Ele é seguro quando o array está íntegro e apenas um disco físico apresentou falha confirmada. É armadilha quando a causa da queda não foi isolada: se dois discos saíram do array em sequência, se a controladora perdeu a configuração ou se há setores ilegíveis nos discos restantes, o rebuild força a leitura intensiva de toda a superfície — justamente o cenário que acelera a falha de um segundo disco e transforma um RAID 5 degradado em um RAID 5 com dois discos inoperantes, estado em que a paridade não consegue mais reconstruir nada.

Além disso, o rebuild grava dados novos no disco substituto e recalcula metadados do array. Se a ordem dos discos estiver errada ou se um disco foi marcado como falho por timeout transitório e não por defeito real, o processo inteiro parte de uma premissa falsa e sobrescreve informações originais. Em RAID 6, que tolera duas falhas, um rebuild iniciado sem diagnóstico pode consumir a segunda margem de tolerância em horas. O custo de interromper e chamar um especialista é quase sempre menor que o custo de um rebuild mal iniciado.

O que NÃO fazer: recriar o array, inicializar, formatar ou forçar montagem

As ações que mais inviabilizam recuperação de RAID são, nesta ordem de gravidade, as que reescrevem metadados ou o cabeçalho dos discos. Recriar o array no utilitário da controladora ou no mdadm com a opção “create” em vez de “assemble” apaga a definição original e grava um novo superbloco por cima. Inicializar discos no gerenciador de volumes do Windows ou no storage do NAS tem efeito semelhante: zera a tabela de partição e os identificadores do array. Formatar, ainda que “rápido”, destrói a estrutura de arquivos e inviabiliza a reconstrução lógica em muitos casos.

Não aceite “Initialize”, “Clear configuration” ou “Make online” sem diagnóstico.
Não recrie o array com mdadm –create; use –assemble somente com metadados documentados.
Não force montagem com fsck automático nem com opções de reparo em modo gravação.
Não inicialize discos marcados como “foreign” antes de fotografar a configuração original.
Não rode utilitários de “reparo de partição” diretamente sobre os membros do array.

Essas proibições valem mesmo quando o sistema operacional oferece “reparar agora”. O reparo automático assume que o sistema de arquivos é a única camada danificada; em RAID, a corrupção costuma estar antes, na camada de blocos e paridade. Corrigir a camada errada grava por cima da evidência que permitiria reconstruir a camada correta. Por isso, a orientação técnica consolidada é congelar o estado atual e só então decidir o próximo passo.

Diagnóstico rápido: o RAID caiu, está degradado ou não monta?

Antes de qualquer comando de recuperação, é preciso classificar a falha. Existem três estados clínicos principais: degradado (o array funciona, mas perdeu redundância), inativo (o array não monta, mas os discos e a configuração estão acessíveis) e falha de controladora (o hardware que gerencia o array perdeu a configuração ou não reconhece os discos). Cada estado exige uma conduta diferente, e confundi-los é a origem da maioria dos desastres em RAID corporativo.

Um array degradado em RAID 1 ou RAID 10 ainda entrega os dados normalmente; a urgência é substituir o disco com falha, mas sem pressa que comprometa a cópia. Um array inativo pode estar com metadados corrompidos, ordem de discos alterada ou superbloco danificado — e aí a montagem forçada é o erro clássico. Já a falha de controladora frequentemente preserva os discos intactos, mas exige reconstruir os parâmetros do array (ordem, tamanho de stripe, nível, offset) a partir de análise forense, não de tentativa e erro.

Sinais no console, no log do kernel e no painel da controladora

O log do kernel em Linux registra eventos de I/O que revelam a origem da falha antes que ela se torne irreversível. Mensagens como “I/O error, dev sdb, sector 0”, “md/raid:md0: Disk failure on sdb” ou “Buffer I/O error on device md0” indicam perda de acesso a um membro do array. A sequência dessas mensagens importa: um erro isolado seguido de recuperação sugere timeout; erros em rajada em múltiplos discos sugerem problema de backplane, cabo ou controladora, não de disco individual.

mdadm –detail /dev/mdX: mostra estado (clean, degraded, active), discos ativos e falhos.
dmesg | grep -i -E “raid|md|I/O error”: revela a ordem cronológica das falhas.
Painel da controladora (PERC, Smart Array, MegaRAID): estado “Offline”, “Foreign”, “Failed” ou “Predictive Failure”.
Log do NAS (Synology, QNAP, TrueNAS): alertas de SMART, queda de volume e eventos de sincronização.
SMART individual dos discos: atributos 5, 196, 197 e 198 apontam setores realocados e pendentes.

O diagnóstico por software tem limite: ele mostra o sintoma, não a causa física. Um disco com setores defeituosos pode aparecer como “failed” por timeout, enquanto o defeito real está no backplane. A análise dos logs serve para evitar ações erradas, não para substituir o exame físico em laboratório quando a falha envolve múltiplos componentes.

RAID degradado x RAID inativo x RAID com falha de controladora

RAID degradado é o estado em que o volume continua acessível e os dados legíveis, mas um ou mais discos saíram do conjunto. Em RAID 1, um espelho pode cair e o sistema seguir operando com o disco restante. Em RAID 5, um disco a menos mantém a leitura por paridade. A ação correta é substituir o disco com falha por um de capacidade igual ou superior e iniciar o rebuild — desde que os demais discos estejam com SMART limpo e sem histórico de erros recentes.

RAID inativo é diferente: o volume não aparece, o sistema não monta o dispositivo e o utilitário da controladora lista o array como “offline” ou “inactive”. Os discos podem estar fisicamente íntegros, mas a configuração lógica está corrompida. Aqui, qualquer tentativa de “reativar” sem antes mapear a ordem original dos discos e o layout de stripes é um tiro no escuro. A recuperação exige reconstruir o array em ambiente controlado, geralmente a partir de imagens setor a setor.

Falha de controladora é o terceiro cenário: a placa RAID perde a configuração armazenada em NVRAM, não reconhece os discos ou apresenta erro de firmware. Os discos continuam com os dados, mas sem a controladora que sabe como eles se organizam. Substituir por uma controladora idêntica pode importar a configuração estrangeira e trazer o array de volta; mas se a versão de firmware for diferente ou se a ordem dos discos tiver sido alterada, a importação grava metadados incorretos e corrompe o volume. O caminho seguro é extrair os parâmetros por análise, não por tentativa de importação.

Como identificar se o problema é disco, controladora, firmware ou sistema de arquivos

A origem da falha muda completamente a conduta. Um disco físico com defeito pede substituição e rebuild; uma controladora com problema pede troca por modelo idêntico; firmware corrompido pede atualização ou downgrade controlado; sistema de arquivos danificado pede reparo lógico sobre imagem, nunca sobre o volume original. Testar a hipótese errada grava dados e destrói a evidência da hipótese certa.

Um método de triagem: se todos os discos somem ao mesmo tempo, suspeite de controladora, backplane, cabo ou fonte. Se um disco some e volta, suspeite de disco, conector ou timeout de firmware. Se o array aparece mas o sistema de arquivos não monta, suspeite de corrupção lógica no volume — e o próximo passo é imagem, não fsck. Se o array não aparece e a controladora lista os discos como “unconfigured good”, a configuração do array foi perdida e precisa ser reconstruída por análise forense.

Checklist de preservação: o que registrar e guardar agora

A preservação de evidências em RAID segue o mesmo princípio da perícia digital: documentar antes de tocar. Quanto mais informações forem registradas nas primeiras horas, maior a chance de reconstruir o array sem depender de tentativa e erro. Isso vale tanto para quem vai acionar um laboratório quanto para quem tem equipe interna de TI — a documentação reduz o tempo de diagnóstico e evita que a intervenção parta de suposições erradas.

O checklist mínimo envolve três frentes: a ordem física dos discos, a identificação de hardware e a captura de logs. Nenhuma dessas ações grava nos discos; todas podem ser feitas com o sistema desligado ou em modo de manutenção. O erro mais comum é pular essa etapa e partir direto para comandos de recuperação, descobrindo depois que a ordem dos discos foi alterada durante a troca de cabos ou a limpeza do servidor.

Anote a ordem física dos discos e o nível RAID original

Em RAID por software (mdadm) e em muitas controladoras de hardware, a posição física do disco no backplane ou nas baias define o membro do array. Se os discos forem removidos e recolocados fora de ordem, o array perde a referência de qual disco era o primeiro, o segundo e assim por diante. Em RAID 5 e 6, a ordem errada inviabiliza o cálculo de paridade e faz o volume parecer ilegível mesmo com todos os discos íntegros.

Etiquete cada disco com a posição original: baia 0, baia 1, canal A, porta SATA 3.
Registre o nível RAID (0, 1, 5, 6, 10, 50, 60) e o tamanho do stripe, se conhecido.
Anote qual disco era o hot spare e se ele chegou a entrar no array.
Marque o número de série de cada disco junto com a posição — não confie só na etiqueta da baia.
Se possível, fotografe a tela da controladora mostrando a ordem dos membros antes de desligar.

Essa anotação é barata e leva minutos, mas é a informação mais valiosa para a reconstrução. Sem ela, o laboratório precisa testar combinações de ordem — o que multiplica o tempo de análise e, em alguns casos, inviabiliza a recuperação por excesso de tentativas sobre mídia frágil.

Fotografe etiquetas, modelo da controladora e versão de firmware

O modelo exato da controladora RAID e a versão de firmware determinam como os metadados são gravados nos discos. Controladoras da mesma família, mas com firmware diferente, podem interpretar o layout de stripes de forma distinta — e uma importação de configuração feita com firmware incompatível corrompe o array. Por isso, antes de qualquer substituição ou atualização, registre:

Modelo da controladora (ex.: Dell PERC H730, HP Smart Array P440ar, LSI MegaRAID 9361).
Versão do firmware e do BIOS da controladora, visíveis no POST ou no utilitário de configuração.
Modelo e capacidade de cada disco, incluindo se é SAS ou SATA, e o número de série.
Versão do sistema do NAS ou do storage, quando aplicável.
Configuração de stripes, cache e política de leitura/gravação, se acessível.

Esses dados permitem que um laboratório reproduza o ambiente original em bancada, com controladora idêntica ou com software de reconstrução paramétrica. Sem eles, a análise parte do zero e o risco de erro aumenta. A fotografia da etiqueta do disco também registra o firmware do próprio disco — informação que influencia o comportamento de timeouts e realocação de setores.

Salve logs, saídas de mdadm, storcli, megacli ou do painel do NAS

Os logs são a memória do incidente. Eles registram qual disco falhou primeiro, em que momento, com qual código de erro e o que a controladora tentou fazer em seguida. Essa sequência é essencial para distinguir falha única de falha em cascata, e para saber se o rebuild automático já começou — e até onde foi. Salvar esses registros antes de reiniciar é crítico, porque o reboot apaga parte do histórico volátil.

mdadm –detail –scan e cat /proc/mdstat: estado atual do array em Linux.
storcli /c0 show all ou megacli -AdpAllInfo -aALL: configuração e eventos da controladora.
Logs do kernel (dmesg, /var/log/messages, journalctl): erros de I/O e eventos de disco.
Exportação do log do NAS (Synology, QNAP) ou do storage, em arquivo, antes de desligar.
Captura de tela do painel de gerenciamento mostrando o estado de cada disco e do volume.

Esses arquivos podem ser enviados junto com os discos para o laboratório, acelerando o diagnóstico. Eles também protegem contra a perda de informação se o servidor não voltar a ligar. A regra é simples: se está na tela, vire arquivo.

O que dá para tentar com segurança (e o que só piora)

Existe uma faixa estreita de ações seguras que podem ser executadas por equipe interna sem comprometer a recuperação. Elas se resumem a três princípios: não gravar nos discos originais, trabalhar sobre imagens e só reconstruir quando a causa for inequívoca. Fora dessa faixa, cada comando adicional aumenta o risco de perda definitiva — e o custo de reverter o dano costuma superar o de acionar um especialista desde o início.

O limite prático é a confiança no diagnóstico. Se há certeza de que um único disco falhou fisicamente e os demais estão saudáveis, o rebuild é uma operação rotineira. Se há qualquer dúvida sobre a ordem dos discos, o estado dos metadados ou a saúde dos membros restantes, a única ação segura é criar imagens setor a setor de cada disco e trabalhar sobre as cópias. É essa distinção que separa a manutenção preventiva da roleta-russa.

Quando um rebuild é seguro e quando ele é armadilha

O rebuild é seguro quando três condições são atendidas simultaneamente: o array está degradado (não inativo), apenas um disco saiu do conjunto por falha física confirmada, e os demais discos não apresentam erros de leitura nem atributos SMART críticos. Nesse cenário, substituir o disco com defeito por um de capacidade igual ou superior e deixar a controladora reconstruir é a conduta padrão — e a que qualquer manual de storage recomenda.

O rebuild vira armadilha quando a falha original não foi isolada. Se dois discos saíram em sequência, se o array caiu após queda de energia ou se a controladora perdeu a configuração, reconstruir sobre um estado inconsistente grava paridade errada e pode corromper todo o volume. Em RAID 5, a falha de um segundo disco durante o rebuild transforma um problema contornável em perda total. Por isso, a decisão de rebuild deve ser precedida de verificação de SMART em todos os discos, não apenas no que falhou.

Substituir a controladora por um modelo idêntico: quando ajuda e quando não

Controladoras RAID de hardware armazenam a configuração do array em NVRAM própria e também gravam metadados nos discos. Quando a placa queima ou corrompe o firmware, trocá-la por um modelo idêntico — mesma família, mesma revisão, mesmo firmware — permite, em muitos casos, importar a configuração estrangeira e reativar o array sem perda. Essa é a primeira tentativa razoável em falha de controladora, desde que a ordem dos discos não tenha sido alterada.

A substituição não ajuda quando o problema não é a controladora, mas sim os discos ou o sistema de arquivos — trocar a placa nesse cenário apenas adiciona variáveis. Também não ajuda quando a controladora substituta tem firmware diferente: a importação pode gravar metadados incompatíveis e corromper o array de forma irreversível. E não ajuda quando a configuração original foi perdida também nos discos; nesse caso, só a reconstrução paramétrica em laboratório recupera o volume.

Montagem somente leitura e imagem dos discos antes de qualquer teste

A prática mais segura em qualquer cenário de RAID com falha é nunca testar sobre os discos originais. O procedimento correto é criar uma imagem setor a setor de cada membro do array — incluindo setores defeituosos, com leitura tolerante a erros — e realizar todas as tentativas de reconstrução sobre as imagens. Isso permite testar ordens de disco, parâmetros de stripe e reparos de sistema de arquivos sem nenhum risco para a evidência original.

Use ferramentas de imagem com leitura reversa e tolerância a setores ilegíveis.
Gere hash de cada imagem para garantir integridade antes dos testes.
Monte o array sobre as imagens em modo somente leitura, nunca em gravação.
Teste hipóteses de ordem de discos e offset de stripe sobre as cópias, não sobre os originais.
Se a mídia original apresentar ruído ou clique, interrompa e envie para ambiente controlado.

Essa abordagem é a diferença entre um erro reversível e um dano permanente. Um fsck mal executado sobre o volume original pode destruir a tabela de arquivos; o mesmo fsck sobre uma imagem pode ser refeito quantas vezes forem necessárias. O custo de armazenamento das imagens é irrisório diante do valor dos dados — e diante do custo de uma recuperação que se tornou inviável por excesso de tentativas.

Quando parar de tentar sozinho e chamar um especialista

Existe um ponto em que a tentativa caseira deixa de ser economia e passa a ser risco. Esse ponto é reconhecível por sinais objetivos: dois ou mais discos fora do array, ruído mecânico em qualquer membro, controladora que não reconhece os discos, importação de configuração que falhou, ou array que já passou por rebuild malsucedido. Nesses cenários, cada nova tentativa grava sobre a evidência e reduz a janela de recuperação.

A decisão de parar não é derrota técnica; é gestão de risco. A árvore de decisão para falha de HD aplica-se igualmente a RAID: se o próximo passo envolve gravação nos discos originais ou incerteza sobre a causa, a conduta correta é congelar o ambiente e buscar análise especializada. O tempo gasto em tentativas frustradas costuma ser maior que o de um diagnóstico profissional.

Casos em que a tentativa caseira costuma inviabilizar a recuperação

Alguns cenários são especialmente sensíveis a intervenção amadora. O primeiro é o RAID 5 ou 6 com dois discos fora do array: a tentativa de forçar a montagem ou recriar o array grava metadados novos e destrói a paridade original. O segundo é o RAID com discos apresentando ruído de clique ou raspagem — sintoma de falha mecânica que exige ambiente limpo para abertura; qualquer tentativa de leitura prolongada agrava o dano físico, como detalhado no artigo sobre HD fazendo barulho de clique.

RAID 0 com qualquer disco falho: sem redundância, cada tentativa de leitura arrisca setores críticos.
RAID 5/6 com dois ou mais discos ausentes ou marcados como falhos.
Array que passou por “initialize” ou “clear configuration” por engano.
Discos com ruído mecânico, aquecimento anormal ou cheiro de queimado.
Controladora que perdeu a configuração e não há registro da ordem dos discos.
Volume com criptografia ou deduplicação ativa, em que metadados corrompidos exigem análise forense.

Nesses casos, a tentativa caseira não é apenas ineficaz — ela consome a chance de recuperação. O artigo sobre tentar recuperar HD sozinho explora o mesmo princípio em mídia única: a intervenção sem diagnóstico transforma falha recuperável em perda definitiva.

O que um laboratório faz que não dá para fazer em casa

Um laboratório de recuperação de RAID opera em três frentes que não existem em ambiente doméstico ou corporativo comum. A primeira é a sala limpa: discos com falha mecânica precisam ser abertos em ambiente com controle de partículas, onde a substituição de cabeças de leitura ou a remoção de contaminação é feita sem danificar os pratos. A segunda é o hardware especializado: leitores de firmware, equipamentos de imagem com controle de tensão e temperatura, e bancadas com controladoras de referência para reproduzir o ambiente original.

A terceira é a reconstrução paramétrica: a partir das imagens dos discos, o laboratório testa combinações de ordem, tamanho de stripe, offset e nível RAID em software forense, sem gravar nada nos originais. Essa análise permite recuperar arrays cuja configuração foi perdida, inclusive RAID 50 e 60 com múltiplos sub-arrays. É um trabalho de engenharia reversa que não se improvisa com utilitários de prateleira — e que exige justamente os registros que o checklist de preservação orientou a guardar.

O que define o custo e o prazo de uma recuperação de RAID

O custo de uma recuperação de RAID não é tabelado porque depende de variáveis que só o diagnóstico revela. A complexidade do array, o tipo de falha, a necessidade de sala limpa, a urgência do prazo e a quantidade de discos envolvidos são os principais fatores. Um RAID 1 com um disco íntegro e outro com falha lógica tende a ser rápido e simples; um RAID 60 com múltiplos discos danificados fisicamente e configuração perdida pode demandar dias de análise e peças doadoras.

O prazo segue a mesma lógica: casos lógicos sem dano físico podem ser resolvidos em horas ou poucos dias; casos com falha mecânica em múltiplos discos exigem importação de componentes, leitura em bancada e reconstrução paramétrica, o que alonga o processo. A transparência sobre esses fatores é um critério de avaliação mais confiável do que qualquer promessa de preço fechado antes do diagnóstico.

Fatores que pesam no orçamento sem números fechados

O orçamento de recuperação de RAID é composto por camadas de complexidade, não por uma tabela única. O primeiro fator é o nível e a geometria do array: RAID 0 e 1 são mais simples; RAID 5, 6, 50 e 60 exigem reconstrução de paridade e múltiplos sub-arrays, o que aumenta o tempo de análise. O segundo é a natureza da falha: dano lógico (metadados, sistema de arquivos) custa menos que dano físico (cabeças, motor, placa lógica), que exige sala limpa e peças doadoras.

Número de discos e capacidade total do array.
Necessidade de sala limpa e troca de componentes mecânicos.
Perda de configuração da controladora e ausência de documentação.
Presença de criptografia, deduplicação ou sistemas de arquivos proprietários.
Urgência do prazo e prioridade de atendimento.
Custo de peças doadoras para discos fora de linha.

Esses fatores explicam por que dois casos aparentemente iguais podem ter orçamentos diferentes. A avaliação honesta de um prestador é aquela que condiciona o valor ao diagnóstico técnico — e que não promete resultado antes de examinar os discos.

Como avaliar um orçamento sem cair em promessa vazia

A primeira regra para avaliar um orçamento de recuperação de RAID é desconfiar de quem garante sucesso antes de ver os discos. Nenhum profissional sério promete recuperação de 100% dos casos, porque há cenários — como RAID 0 com disco fisicamente destruído ou sobrescrita de metadados — em que a recuperação é parcial ou inviável. A promessa de “recuperação garantida” é sinal de amadorismo ou má-fé, não de competência.

O segundo critério é a clareza do escopo: o orçamento deve especificar o que está incluído (diagnóstico, imagem, reconstrução, mídia de devolução), o que é cobrado à parte (peças doadoras, urgência) e o que acontece se a recuperação não for possível. O terceiro é a política de não gravação: um prestador confiável trabalha sobre imagens e devolve os discos originais intactos, sem alterar o estado em que chegaram. Quem não explica o método provavelmente não tem método.

Depois da recuperação: como não passar por isso de novo

A recuperação bem-sucedida encerra o incidente, mas não elimina a causa. Sem uma mudança de processo, o mesmo array pode falhar de novo — e a segunda falha costuma encontrar um ambiente menos preparado, porque a urgência da primeira já passou. A prevenção pós-recuperação tem dois pilares: backup com redundância geográfica e monitoramento que antecipa a falha. Ambos custam fração do que custou a recuperação.

O erro mais comum é tratar o RAID como backup. RAID protege contra falha de disco, não contra corrupção lógica, ransomware, erro humano ou falha de controladora. Um array RAID 1 espelha um arquivo corrompido com a mesma fidelidade com que espelha um arquivo íntegro. A recuperação de dados para indústria mostra que a parada operacional por falha de storage é evitável quando existe camada de backup independente do array.

Backup 3-2-1 para ambientes RAID e NAS

A regra 3-2-1 estabelece três cópias dos dados, em dois tipos de mídia diferentes, com uma cópia fora do local. Para ambientes RAID e NAS, isso significa que o array em si é apenas a cópia de produção — ela não conta como backup. As outras duas cópias devem existir em mídia distinta (outro storage, fita, nuvem) e uma delas precisa estar geograficamente separada, protegida contra incêndio, roubo ou falha elétrica que atinja o site principal.

Três cópias no total: produção + backup local + backup externo.
Dois tipos de mídia: storage em disco e fita ou nuvem, por exemplo.
Uma cópia fora do local físico, em outro prédio ou provedor de nuvem.
Backup versionado: retenção que permita voltar a versões anteriores, não só à última.
Teste de restore periódico: backup que nunca foi restaurado é promessa, não backup.

Para NAS domésticos e de pequenas empresas, o mesmo princípio se aplica em escala reduzida: um segundo NAS em outro cômodo ou um serviço de nuvem com versionamento já cobre o cenário de falha total do equipamento principal. A diferença entre quem perde dados e quem não perde raramente está no hardware — está na existência de uma segunda cópia testada.

Monitoramento de SMART, alertas de degradação e testes de restore

O monitoramento contínuo é o que transforma falha catastrófica em manutenção programada. Atributos SMART como setores realocados (5), setores pendentes (197) e erros de leitura (198) indicam degradação física semanas ou meses antes da falha total. Configurar alertas para esses atributos — e, principalmente, agir quando eles disparam — é a medida preventiva de maior retorno em ambientes RAID e NAS.

Ative alertas de SMART em todos os discos do array, não apenas no que já falhou.
Monitore o estado do array (degraded, rebuilding, verifying) com notificação imediata.
Teste o restore de backup em periodicidade definida, com registro do resultado.
Mantenha um disco de prontidão (hot spare) para substituição imediata em RAID com redundância.
Revise logs de eventos da controladora e do NAS semanalmente, não apenas quando algo quebra.

O teste de restore merece destaque: é a única forma de saber se o backup funciona. Um backup que nunca foi restaurado pode estar corrompido, incompleto ou com permissões erradas — e a descoberta só acontece no pior momento. A disciplina de testar a restauração transforma o backup de esperança em ativo real de continuidade.

Perguntas frequentes sobre RAID que parou de funcionar

O RAID degradado ainda pode ser usado normalmente?

Sim, em RAID com redundância (1, 5, 6, 10, 50, 60) o array degradado continua acessível para leitura e gravação. Mas a janela de risco está aberta: uma segunda falha antes do rebuild concluído pode derrubar o volume. O recomendado é substituir o disco com falha e reconstruir o array o quanto antes, sem interromper a operação se ela for crítica.

Perdi a configuração da controladora. Os dados ainda existem?

Em geral, sim. Os dados permanecem nos discos; o que se perdeu foi a definição de como eles se organizam. A recuperação exige reconstruir os parâmetros do array — ordem dos discos, nível, tamanho de stripe, offset — por análise forense ou a partir da documentação que foi preservada. Sem essa documentação, o trabalho é mais longo, mas não necessariamente inviável.

Posso trocar a controladora por outra de marca diferente?

Não é recomendado. Controladoras diferentes gravam metadados em formatos diferentes e podem interpretar o layout de stripes de forma incompatível. A troca segura é por modelo idêntico, mesma revisão e mesmo firmware. Se isso não for possível, a alternativa é a reconstrução paramétrica em laboratório, que independe da controladora original.

O rebuild apagou meus dados. Ainda dá para recuperar?

Depende do estágio em que o rebuild foi interrompido e de quantos discos foram sobrescritos. Se o processo foi parado logo no início e os discos originais não foram formatados, parte dos dados pode ser recuperável por análise de paridade e de remanescentes de sistema de arquivos. Quanto mais o rebuild avançou, menor a chance — por isso a interrupção imediata é crítica.

RAID 0 com um disco falho tem recuperação possível?

RAID 0 não tem redundância: a falha de um disco compromete o volume inteiro. A recuperação depende da natureza da falha — se for lógica ou de firmware, o disco pode ser lido em bancada e o array reconstruído. Se for física com dano aos pratos, a chance é reduzida. Cada caso exige diagnóstico individual, sem promessa de resultado.

Quanto tempo leva uma recuperação de RAID?

Casos lógicos sem dano físico podem ser concluídos em horas ou poucos dias. Casos com falha mecânica em múltiplos discos, perda de configuração ou necessidade de peças doadoras podem levar uma semana ou mais. O prazo só é estimável com precisão após o diagnóstico inicial dos discos e da controladora.

Enviar os discos pelo correio é seguro?

Sim, desde que embalados individualmente em proteção antiestática e com amortecimento adequado, preferencialmente em caixa rígida. O transporte deve ser feito com os discos desligados e identificados com a posição original no array. O envio seguro é prática comum em recuperação de dados e não compromete a integridade se a embalagem for correta.