Servidor RAID parado é a emergência corporativa com maior impacto operacional imediato. Quando o servidor afetado hospeda banco de dados, Active Directory ou ERP, cada hora de inatividade tem custo mensurável. Por isso, a recuperação de servidor RAID parado exige um protocolo específico que começa pela preservação forense — não pela tentativa de reparo. Por isso, cada ação errada tomada sob pressão nas primeiras horas reduz irreversivelmente o que ainda é possível recuperar. Este guia técnico documenta esse protocolo passo a passo, com FAQ técnico completo para os cenários mais complexos.

As causas técnicas de servidor RAID parado

Falha de disco durante escrita em produção

Um disco falha mecanicamente ou eletronicamente enquanto o servidor realiza operações de escrita ativas. Em seguida, o RAID controller detecta a falha e coloca o arranjo em modo degradado. No RAID 5, o servidor continua funcionando sem tolerância adicional. No RAID 0, o servidor para imediatamente porque não existe redundância.

O problema crítico não é a falha em si — é a resposta à falha. Quando a equipe de TI insere rapidamente um disco novo e inicia o rebuild sem verificar o estado dos demais discos, o rebuild pode falhar ao encontrar setores defeituosos. Cada falha de rebuild deixa o arranjo em estado mais difícil de recuperar. Por isso, a Crowdertech recomenda: faça backup dos dados críticos antes de qualquer substituição, e execute S.M.A.R.T. completo em todos os discos restantes antes de iniciar o rebuild. Para recuperação de RAID com falha durante rebuild, o diagnóstico forense começa pelo mapeamento do estado de cada disco individualmente.

Falha da controladora RAID por surto ou desgaste

A controladora RAID — PERC nos servidores Dell, SmartArray nos HPE, MegaRAID nos Lenovo — gerencia o algoritmo de RAID por hardware. Quando a controladora queima, o servidor para e nenhum disco fica acessível pelo sistema operacional.

Contudo, os dados vivem nos discos físicos — não na controladora. Portanto, a controladora é o “intérprete” que organiza como o servidor grava os dados. Os bytes em si existem nas superfícies magnéticas dos HDDs ou nas células NAND dos SSDs. Trocar a controladora por modelo idêntico frequentemente resolve o problema sem recuperação forense. Contudo, uma controladora com firmware diferente pode não reconhecer o arranjo. Por isso, antes de qualquer substituição de controladora, acione especialistas. Para recuperação de storage SAN com controladora queimada em São Paulo, o processo segue a mesma lógica.

Corrupção do sistema de arquivos por desligamento abrupto

O Windows Server usa NTFS com journal de transações. O Linux usa ext4 com journal ou XFS com journaling nativo. Em condições normais, esses mecanismos garantem consistência após qualquer desligamento. Contudo, quando a queda de energia acontece durante uma escrita no próprio journal, ele pode ficar corrompido.

Dessa forma, sem um journal válido, o sistema operacional não consegue fazer o replay das transações pendentes. No Windows Server, isso resulta em tela azul ou volume inacessível. No Linux, surgem mensagens de erro de montagem e o sistema não completa o boot. Além disso, corrupção na Master File Table (NTFS) ou na tabela de inodes (ext4) deixa arquivos individualmente inacessíveis mesmo com o volume montado. A Crowdertech reconstrói MFT e tabelas de inodes por forense quando o sistema operacional não consegue mais acessá-los. Veja como isso se aplica a bancos de dados em recuperação de SQL Server com corrupção de sistema de arquivos.

Falha de energia durante rebuild

O rebuild de RAID é a operação mais crítica em termos de vulnerabilidade. Durante o processo, o servidor opera sem a redundância habitual. Para RAID 5 com um disco falhado, o rebuild lê 100% dos dados dos discos restantes. Em arranjos grandes — 6 discos de 8 TB em RAID 5 — esse processo pode levar 24 a 40 horas.

Quando a energia cai durante esse processo, o rebuild fica em estado inconsistente. A maioria das controladoras salva o estado em memória flash para poder retomar após religar. Contudo, quando a bateria de backup da controladora (BBU) está descarregada ou ausente, esse estado se perde. Consequentemente, o rebuild recomeça do zero ao religar.

Dependendo do ponto em que o rebuild parou, parte dos dados no disco novo chegaram corretos e parte incorretos. Se o servidor tenta usar o volume nesse estado, dados em posições ainda não reconstruídas aparecem incorretos. Por isso, após qualquer queda de energia durante rebuild, o servidor não deve voltar à produção antes de diagnóstico forense completo. Para atendimento urgente: (11) 99630-0675 (WhatsApp 24h) ou (11) 4863-3636 (fixo).

Problema de firmware da controladora após atualização

Atualizações de firmware da controladora RAID corrigem bugs e melhoram desempenho. Contudo, algumas atualizações têm bugs que afetam configurações específicas de RAID. Além disso, quando a queda de energia ou timeout interrompe a atualização — a controladora fica em estado híbrido com firmware parcialmente atualizado.

Nesse sentido, esse estado resulta em comportamentos imprevisíveis: desde a controladora não inicializar até o arranjo parecer normal mas com corrupção silenciosa. Por isso, atualizações de firmware de controladora a equipe deve executar fora do horário de produção, com UPS garantindo energia contínua, e com backup completo confirmado antes da aplicação.

Colapso por desgaste simultâneo de múltiplos discos

Esse cenário é especialmente comum em servidores comprados 5 a 7 anos atrás sem substituição preventiva de discos. Quando a empresa comprou todos os discos juntos, instalou juntos e operaram as mesmas horas, eles atingem o fim de vida em períodos próximos.

No entanto, o desgaste simultâneo frequentemente não aparece no S.M.A.R.T. convencional. Os parâmetros críticos podem estar em zero mesmo com discos próximos do fim de vida. Por isso, a melhor proteção consiste na substituição preventiva baseada na idade e nas horas de operação — independentemente do estado S.M.A.R.T.

O protocolo correto quando o servidor RAID para

Fase 1 — Os primeiros 5 minutos: avaliação sem ação

Quando o servidor para, a primeira reação correta é avaliar — não agir. Acesse o painel de gerenciamento da controladora antes de qualquer reinicialização: no Dell, o iDRAC; no HPE, o iLO; em servidores com BIOS RAID, a tela de configuração durante o boot.

Por isso, anote exatamente o que aparece: quais discos estão em estado “online”, “failed”, “rebuild”, “foreign” ou “offline”. Além disso, fotografe a tela — essa informação tem valor crítico para o diagnóstico forense e ninguém consegue recuperá-la depois se o servidor reiniciar.

Fase 2 — Os primeiros 15 minutos: preservação e documentação

Com o estado documentado, verifique se o servidor tem acesso remoto via iDRAC, iLO ou SSH para exportar logs sem reinicializar. No Windows Server, os logs de eventos do sistema registram a sequência exata de erros. No Linux, os logs em /var/log/syslog e /var/log/kern.log têm as mensagens do MD-RAID.

Portanto, exporte esses logs antes de qualquer reinicialização. Além disso, se o servidor ainda está ligado e parcialmente acessível, execute S.M.A.R.T. em todos os discos via ferramentas de gerenciamento da controladora (Dell OpenManage, HPE SSA, StorCLI). Por isso, os primeiros 15 minutos servem para documentação — não para tentativas de resolver o problema.

Fase 3 — A decisão crítica: reiniciar ou não

A maioria dos administradores reinicia o servidor como primeiro passo. Contudo, reiniciar pode iniciar rebuild automático não autorizado se a equipe inseriu o disco de substituição antes da análise. Além disso, reiniciar apaga informações de estado em memória RAM — logs de buffer, estado de transações abertas em banco de dados. Por isso, antes de reiniciar o servidor com RAID parado, ligue para a Crowdertech: (11) 99630-0675.

Fase 4 — Contato com especialistas e plano de ação

Com o estado documentado e o servidor preservado, o contato com a Crowdertech define o plano de ação. Em ambientes acessíveis remotamente, o diagnóstico começa imediatamente via acesso seguro. Para hardware que precisa de análise física, a retirada em São Paulo acontece no mesmo dia para emergências. Para recuperação de servidor em São Paulo com atendimento urgente, o diagnóstico forense de cada disco começa antes de qualquer tentativa de recuperação do arranjo.

Os erros mais comuns com servidor RAID parado

Substituir a controladora sem verificar compatibilidade

Uma controladora PERC H730 com firmware versão 25.5.9.0001 e outra com 25.5.9.0002 geralmente são compatíveis para importação de configuração. Contudo, uma controladora com firmware muito diferente pode não reconhecer o arranjo. Além disso, ela pode tentar inicializar os discos como “foreign configuration” — o que, se confirmado, apaga os metadados do arranjo.

Além disso, mesmo quando a versão de firmware é compatível, a controladora nova pode ter cache em estado inconsistente. Por isso, acione especialistas antes de qualquer substituição de controladora.

Usar o modo “Fast Init” ao recriar o RAID

O Fast Init marca os blocos como inicializados sem realmente sobrescrevê-los. Os dados antigos permanecem fisicamente nos discos — acessíveis por recuperação forense. Contudo, qualquer escrita de produção sobre o novo RAID começa a sobrescrever os dados antigos. Por isso, mesmo após a recriação do RAID, se o servidor ainda não entrou em produção, a recuperação forense tem alta chance de extrair os dados originais. Acione a Crowdertech imediatamente.

Aceitar “foreign configuration” sem entender as consequências

Quando você instala uma controladora nova, ela detecta a “foreign configuration” e pergunta se você quer importar ou inicializar. “Importar” tenta reconhecer e montar o arranjo antigo. “Inicializar” apaga os metadados e cria novo RAID do zero.

Contudo, quando a importação falha, a controladora pode tentar “corrigir” o estado importado de forma destrutiva. Por isso, nunca confirme “Import” ou “Initialize” sem entender exatamente qual configuração a controladora vai importar.

Cenários específicos de servidor RAID parado em São Paulo

Servidor de Active Directory com RAID parado

Quando o Domain Controller para, nenhum usuário consegue fazer login. Impressoras somem da rede. Aplicações que usam autenticação Kerberos param. Para empresas em São Paulo com AD em servidor RAID, a falha do RAID equivale a bloquear toda a empresa simultaneamente.

Por isso, o banco de dados do AD — o arquivo NTDS.dit — fica em C:\Windows\NTDS\ junto com os logs de transação. A Crowdertech extrai o NTDS.dit por forense e usa ferramentas especializadas para ler o banco ESE sem o AD funcional. Por isso, mesmo quando o servidor de DC não inicializa por colapso do RAID, todos os objetos do domínio — usuários, computadores, políticas — ficam recuperáveis. Para recuperação de Active Directory em servidor RAID parado, o diagnóstico determina se é possível retomar o AD no mesmo hardware.

Servidor de virtualização VMware ESXi com RAID parado

Para servidores ESXi com RAID parado, o impacto pode derrubar dezenas de máquinas virtuais simultaneamente — servidores de banco de dados, ERP, Active Directory e aplicações web. O VMFS (VMware File System) tem estrutura própria diferente do NTFS e do ext4.

Portanto, a Crowdertech reconstrói o VMFS virtualmente e extrai os VMDKs, que a Crowdertech analisa individualmente para recuperar os dados de cada VM. Para recuperação de máquina virtual VMware em servidor RAID parado, a Crowdertech avalia cada VMDK separadamente.

Servidor de backup com RAID parado

Quando o servidor de backup tem RAID parado, a empresa perde não só os dados de produção mas também os backups. Por exemplo, Veeam, Acronis e Windows Server Backup armazenam backups em formatos proprietários (.vbk, .vib, .vrb para Veeam; .tib para Acronis) com compressão interna.

A Crowdertech tem metodologia para recuperar dados de servidores de backup com RAID parado — incluindo extração de backups individuais dos arquivos .vbk e .tib corrompidos. Por isso, mesmo quando o servidor de backup para, ainda é possível extrair backups de períodos específicos.

FAQ técnico avançado — servidor RAID parado

Controladoras Dell e HPE

Servidor Dell PowerEdge R750 com PERC H755 reportando “VD X is in degraded state” — qual a diferença para “failed”? “Degraded” significa que o volume funciona mas sem redundância total — normalmente um disco falhado em RAID 5 ou RAID 6. “Failed” significa que o volume parou e não serve dados. No estado “Degraded”, o servidor continua em produção mas qualquer leitura com erro em qualquer disco restante pode levar ao estado “Failed”. Portanto, “Degraded” é urgente; “Failed” exige ação imediata e é o estado mais grave.

Servidor HPE ProLiant DL380 Gen10 com SmartArray P408i-a e “Accelerator Status: Temporarily Disabled” — o que significa? O accelerator status refere-se ao cache de escrita da controladora. “Temporarily Disabled” significa que o sistema desativou o cache — geralmente porque a BBU está descarregada ou falhada. Com o cache desativado, a controladora usa Write-Through (grava diretamente nos discos sem cache). Isso reduz drasticamente a performance e expõe operações de escrita a corrupção em caso de queda de energia. Não é emergência imediata — mas substitua a BBU antes da próxima queda de energia.

Linux e Windows Server

Servidor Linux (Rocky Linux 9) com mdadm e mensagem “md: md0: data-check done” que sempre reinicia — o que está acontecendo? O MD-RAID executa verificação de consistência continuamente porque encontra inconsistências que não consegue resolver. Esse comportamento indica setores defeituosos em um ou mais discos gerando inconsistências de paridade recorrentes. Além disso, cada ciclo de verificação que “corrige” a inconsistência sobrescrevendo paridade calculada a partir do setor defeituoso pode corromper dados silenciosamente. Acione especialistas — esse cenário precisa de diagnóstico forense de todos os discos.

SQL Server em servidor Windows 2019 com RAID 5 parado reportando “database is suspect” ao tentar montar — o banco ainda existe? Sim. O status “Suspect” do SQL Server indica que o banco não concluiu o recovery após o reinício — frequentemente por corrupção de páginas de dados no MDF ou no LDF. Contudo, os arquivos MDF e LDF existem no volume RAID e contêm os dados. A Crowdertech recupera o volume RAID primeiro e depois extrai e verifica a integridade do banco. Para recuperação de SQL Server em estado Suspect, o diagnóstico identifica quais páginas estão corrompidas.

Servidor com RAID 5 de 6 discos de 8 TB — o rebuild vai levar 30+ horas. É seguro deixar rodar? Tecnicamente sim, mas com riscos. Durante 30 horas de rebuild, o servidor opera sem tolerância a falhas. Qualquer leitura com erro em qualquer disco restante para o rebuild definitivamente. Além disso, a carga de leitura do rebuild pode expor setores fracos que nunca foram lidos em uso normal. Portanto, minimize a carga de trabalho no servidor durante o rebuild e monitore os logs ativamente.

Cenários avançados

RAID por software mdadm no Linux parou com “not clean — starting recovery” que trava — o que fazer? O MD-RAID tenta resync após desligamento abrupto, mas encontra um setor ilegível que trava o processo. Se o processo ficou travado por mais de algumas horas, pode indicar múltiplos setores defeituosos. Interrompa o resync e acione especialistas antes de qualquer outra ação.

Servidor com SQL Server em RAID 5 parado — o banco de dados sobrevive à queda do RAID? Na maioria dos casos, sim. O SQL Server usa arquivos MDF (dados) e LDF (log de transações) que podem ficar em volumes dedicados. Contudo, se o RAID do SQL Server é o mesmo do sistema operacional, a recuperação precisa reconstruir o volume antes de acessar os arquivos do banco. Para recuperação de SQL Server em servidor RAID parado, a Crowdertech recupera o banco mesmo quando o volume não monta.

Qual a diferença de custo e prazo entre servidor RAID parado com discos íntegros versus com dano físico? Com discos íntegros (apenas corrupção de metadados ou sistema de arquivos): diagnóstico em horas, recuperação em 24 a 48 horas, custo menor. Com dano físico em um ou mais discos: diagnóstico em 24 horas, recuperação de 3 a 7 dias, custo maior por incluir clonagem forense especializada. O diagnóstico gratuito da Crowdertech define exatamente qual categoria é o caso antes de qualquer cobrança.

Quanto tempo a Crowdertech leva para iniciar o atendimento de servidor RAID parado em São Paulo? O diagnóstico remoto começa durante a primeira ligação — sem fila de espera para emergências. Para hardware que precisa de análise física, a retirada em São Paulo acontece no mesmo dia para chamados até as 18h. Além disso, o diagnóstico noturno é totalmente possível para ambientes acessíveis remotamente.

Conclusão

Servidor RAID parado exige protocolo correto desde o primeiro minuto. Cada erro tomado sob pressão reduz a taxa de recuperação de forma frequentemente irreversível. Em resumo, documente o estado atual, não reinicie sem orientação especializada, não aceite “perda total” sem segunda opinião e ligue imediatamente para a Crowdertech. A Crowdertech atende servidor RAID parado 24 horas com laboratório na Vila Olímpia, São Paulo — diagnóstico gratuito, cobrança apenas com resultado confirmado. (11) 99630-0675 · (11) 4863-3636.

Fontes: NIST SP 800-34r1 · CERT.br · Microsoft Learn · MD-RAID Linux Documentation.