Raid 5 do Software do Windows Server 2008 - Problemas de integridade de dados

Question

Eu tenho um servidor executando o Windows Server 2008 R2, com uma matriz RAID-5 de software (nativo do Windows). O array consiste em 7 unidades 1TB Western Digital RE3 e RE4. Eu tenho backups offline dessa matriz.

O problema é este: eu notei há alguns dias depois de copiar um arquivo grande para o disco que havia um problema de integridade com esse arquivo - era um arquivo ~ 12GB que eu tinha baixado via uTorrent. Depois de movê-lo para o array de ataque, usei o uTorrent para realocar o local de download e realizei uma nova verificação para que eu pudesse propagá-lo desse local. O novo exame descobriu que apenas 6308/6310 partes do arquivo copiado estavam intactas.

Meu próximo passo foi escrever um script rápido de powershell que copiaria arquivos para o array, enquanto executaria um hash SHA1 dos arquivos originais e resultantes e os compararia. Arquivos menores (100-1000MB) copiados muito bem. Quando comecei a copiar dados maiores (~ 15GB), descobri que a verificação de hash falhava em cerca de 2 / 3rds do tempo. Os arquivos corrompidos tinham inconsistências muito, muito pequenas - menos de 0,01% (EDIT - experimentos posteriores mostraram que os fragmentos de dados corrompidos têm sempre 60 bytes de comprimento, com um a três geralmente se manifestando por arquivo copiado de 15GB. , sem padrão consistente de bits invertidos). Eu eliminei ainda mais a possibilidade de problemas de rede ou de cliente colocando esse arquivo grande no C: \ do servidor e copiando-o repetidamente de lá para o array, obtendo resultados semelhantes.

Copiar os dados via Explorer, PowerShell ou o prompt de comando padrão do Windows produz os mesmos resultados. Nenhuma das cópias falha ou relata problemas. O próprio array raid é listado como saudável no gerenciamento de disco.

Depois de algumas experiências, encerrei o servidor e executei o memtest durante a noite. Nenhum erro foi detectado. Uma execução básica do chkdsk não encontrou problemas, mas eu não usei o sinalizador / R, pois não tinha certeza de como isso afetaria um volume RAID-5 do software.

Em seguida, executei o Crystal Disk Info para verificar os dados inteligentes nas unidades, mas descobri que o CDI detectou apenas 5 de 7 discos na matriz. Eu não tenho ideia do porquê. No entanto, o CDI mostra os seguintes sinalizadores de "cuidado" em uma única unidade:

05 199 199 140 000000000001 Reallocated Sectors Count
C5 200 200 __0 000000000001 Current Pending Sector Count

O que é um pouco alarmante, mas eu realmente não sei o que fazer com a informação. Eu quase não sinto que um setor realocado possa estar causando isso.

Neste ponto, estou procurando algumas orientações sobre o que fazer a seguir. Preciso determinar a causa desse problema, mas hesito em executar o chkdsk / R ou qualquer verificador de integridade de disco inicializável porque tenho medo de que eles possam quebrar a matriz. Eu considerei disparar uma nova sincronização da matriz, mas não tenho certeza de como fazer isso sem fazer algo bobo, como soltar um disco manualmente e depois restaurá-lo.

Qualquer conselho que possa me ajudar a descobrir a causa precisa desse problema seria muito apreciado.

    

Answer 1

Como nenhuma das operações que você está executando está falhando, executar chkdsk /R provavelmente não produziria nenhum resultado - o chkdsk não poderia recuperar nada que não fosse detectado como corrompido.

Corrupções de dados como as que você está vendo teriam algumas fontes possíveis:

1. bit flips na execução do algoritmo RAID de software antes de gravar dados
O
2. bit inverte a implementação de hardware ao gravar dados
3. bit flips em mídia magnética
O
4. bit inverte a implementação de hardware ao ler dados

Você deve escolher uma abordagem metódica para excluir os que você pode excluir:

• O número 4 - bit flips ao ler - deve ser facilmente reconhecível pelo fato de que os flips ocorreriam para diferentes áreas de dados, portanto os hashes md5 ou sha1 seriam diferentes de tempos em tempos você está tentando calculá-los em um arquivo grande

• Número 3 - vira mídia magnética - é improvável que não seja detectado, pois todos os discos rígidos incluem algoritmos de correção de erro, bem como checksums de detecção de erros e você definitivamente veria erros irrecuperáveis de leitura de setor por uma série de magnitudes com mais freqüência do que os bits passando - verificando os erros de leitura SMART irrecuperáveis deve ser suficiente para excluir esse

• Número 2 - este pode ser bem difícil de detectar. Embora o protocolo SATA proteja os dados transmitidos por algoritmos de correção de erros onde a lógica do 3. case se aplicaria e retardaria qualquer transmissão para um crawl antes de permitir um setor de bits invertidos, a corrupção poderia acontecer em outro lugar e não ser detectada - em buffers para exemplo.

• Número 1 - Eu consideraria isso o caso mais provável. Ou um bug na implementação ou (mais provavelmente como um bug dessa significância provavelmente seria notado e documentado por algum outro lugar 4 anos após o lançamento do SO) uma falha de hardware como RAM defeituosa poderia causar esse tipo de falha. Faça alguns memtest passar para excluir a RAM, especialmente se você não estiver usando a memória ECC. Volte a executar os seus testes num ambiente semelhante com a mesma configuração de software (de preferência, uma imagem do seu sistema) para excluir uma causa baseada em software.

Você também pode estender seus testes para copiar 15 GB de arquivos menores apenas para ver se a corrupção também afetaria um deles após uma certa quantidade de dados gravados. Se este for o caso (que parece provável dada a sua descrição), você deve assumir que semelhante corrupção ocorreu com dados já colocados em seus discos - tente comparar com dados originais ou hashes criptográficos em bom estado com arquivos maiores para estimar o grau de corrupção .

Além disso, a capacidade de executar um novo cálculo das somas de verificação XOR e compará-las aos dados de paridade armazenados nos discos teria sido boa e a maioria dos sistemas RAID 5 oferece essa funcionalidade, que normalmente é chamada de "scrubbing". Com o Windows, parece não haver maneira de fazer isso de imediato. Eu só consegui encontrar serviços de recuperação de dados para você.

Boa caçada.

    

Answer 2

chkdsk (sem o / R) será a primeira coisa que você executa. Se houver um problema, execute chkdsk / R. Você pode estar tendo um problema com o controlador de disco e não com os discos. Se o chkdsk relatar que blocos diferentes são ruins toda vez que você executá-lo (sem o / R), então é um problema do controlador e não do disco.