Os dados em discos rígidos podem degradar sem um aviso sobre o dano?

Todos nos preocupamos em manter nossos dados e arquivos seguros e intactos, mas é possível que dados sejam danificados e sejam acessados ​​por um usuário sem uma notificação ou aviso de qualquer tipo sobre o problema? O super-usuário Q & Uma publicação tem a resposta para a pergunta do leitor preocupado.

Pergunta de hoje e amp;A sessão de atendimento chega a cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento comunitário de sites Q & A.

Foto cortesia da generalização( Flickr).

A pergunta

O leitor SuperUser topo morto quer saber se os dados em discos rígidos podem se degradar e ser acessados ​​sem aviso prévio sobre o dano:

É possível que a degradação física de um disco rígido possa fazer com que os bits "flip" no conteúdo de um arquivosem o sistema operacional perceber a alteração e notificar o usuário sobre isso ao ler o arquivo? Por exemplo, poderia um "p"( binário 01110000) em um arquivo de texto ASCII mudar para um "q"( binário 01110001), então, quando um usuário abre o arquivo, eles vêem "q" sem estar ciente de que ocorreu uma falha?

Estou interessado em respostas relativas a FAT, NTFS ou ReFS( se isso faz a diferença).Quero saber se os sistemas operacionais protegem os usuários, ou se devemos verificar nossos dados quanto a variações entre cópias ao longo do tempo.

Os dados em discos rígidos podem ser degradados e acessados ​​sem aviso prévio sobre o dano?

A Resposta O contribuidor

SuperUser Guntram Blohm tem a resposta para nós:

Sim, há uma coisa chamada podridão de bit. Mas não, isso não afetará um usuário despercebido.

Quando um disco rígido escreve um setor para os pratos, não apenas escreve os bits da mesma maneira que eles são armazenados na RAM, ele usa uma codificação para garantir que não existam seqüências do mesmo bit que sejam muito longas. Ele também adiciona códigos ECC que permitem reparar erros que afetam alguns bits e detectam erros que afetam mais de alguns bits.

Quando o disco rígido lê o setor, ele verifica esses códigos ECC e repara os dados, se necessário( e, se possível).O que acontece depois depende das circunstâncias e do firmware do disco rígido, que é influenciado pela designação da unidade.

• Se um setor pode ser lido e não tiver problemas de código ECC, ele será passado para o sistema operacional.
• Se um setor pode ser facilmente reparado, a versão reparada pode ser gravada em disco, lida e verificada para determinar se o erro foi aleatório( ou seja, raios cósmicos, etc.) ou se houver um erro sistemático com a mídia.
• Se o disco rígido determinar que há um erro com a mídia, ele reafecta o setor.
• Se um setor não pode ser lido nem corrigido após algumas tentativas de leitura( em um disco rígido designado como disco rígido RAID), o disco rígido desistirá, reatribuirá o setor e informará ao controlador que havia umproblema. Depende do controlador RAID para reconstruir o setor dos outros membros do RAID e gravá-lo novamente no disco rígido com falha, o que o armazena no setor reatribuído( que, com sorte, não tem problema).
• Se um setor não pode ser lido ou corrigido no disco rígido de uma área de trabalho, o disco rígido irá envolver mais tentativas para lê-lo. Dependendo da qualidade do disco rígido, isso pode envolver o reposicionamento da cabeça, verificando se há alguns bits que flip quando ler repetidamente, verificando quais bits são os mais fracos e algumas outras coisas. Se alguma dessas tentativas for bem sucedida, o disco rígido reatribuirá o setor e anotará os dados reparados.

Esta é uma das principais diferenças entre os discos rígidos vendidos como discos rígidos "desktop", "NAS / RAID" ou "vigilância por vídeo".Um disco rígido RAID pode simplesmente desistir rapidamente e fazer o controlador reparar o setor para evitar latência do lado do usuário. Um disco rígido da área de trabalho continuará tentando novamente e novamente porque ter o usuário esperar alguns segundos provavelmente é melhor do que dizer-lhes que os dados são perdidos. E um disco rígido de vídeo valha as taxas de dados constantes mais do que a recuperação de erros, uma vez que um quadro danificado normalmente não será notado.

De qualquer forma, o disco rígido saberá se houve podridão de bit, normalmente irá recuperar-se dele, e se ele não puder, informará o controlador que, por sua vez, dirá ao driver que informará o sistema operacional. Então, cabe ao sistema operacional apresentar o erro ao usuário e agir sobre ele.É por isso que cbernard diz:

• Eu nunca testemunhei um único erro de bit, mas eu já vi muitos discos rígidos em que setores inteiros falharam.

O disco rígido saberá se há algo de errado em um setor, mas não saberá quais bits falharam. Um único bit que falhou sempre será capturado pela ECC.

Tenha em atenção que o chkdsk e os sistemas de arquivos que se reparam automaticamente não tratam de reparar dados dentro dos arquivos. Estes são direcionados para a corrupção dentro da estrutura do próprio sistema de arquivos, como uma diferença no tamanho de um arquivo entre a entrada do diretório e o número de blocos alocados. O recurso de auto-cura do NTFS detectará danos estruturais e impedirá que ele afete seus dados ainda mais, mas não irá reparar os dados já danificados.

Existem, é claro, outros motivos pelos quais os dados podem ficar danificados. Por exemplo, uma RAM ruim em um controlador pode alterar os dados antes mesmo de ser enviada para o disco rígido. Nesse caso, nenhum mecanismo no disco rígido detectará ou reparará os dados, e esse pode ser um dos motivos por que a estrutura de um sistema de arquivos está danificada. Outros motivos incluem erros de software, apagões durante a gravação no disco rígido( embora este seja endereçado pelo registro do sistema de arquivos) ou drivers do sistema de arquivos ruim( o driver NTFS no Linux padrão para somente leitura por um longo período de tempo, já que o NTFS foi projetado de forma reversa,não documentado, e os desenvolvedores não confiaram em seu próprio código).

• Eu tive esse cenário uma vez que um aplicativo salvaria todos os seus arquivos em dois servidores diferentes em dois centros de dados diferentes, a fim de manter uma cópia de trabalho dos dados disponíveis em todas as circunstâncias. Após alguns meses, percebemos que cerca de 0,1 por cento de todos os arquivos copiados não combinavam com a soma de verificação MD5 que o aplicativo armazenava em seu banco de dados. Resultou ser um cabo de fibra defeituoso entre o servidor ea SAN.

Esses outros motivos são por que alguns sistemas de arquivos, como o ZFS, mantêm informações de soma de cheques adicionais para detectar erros. Eles são projetados para protegê-lo de muitas outras coisas que podem dar errado do que apenas uma podridão.

Tem alguma coisa a adicionar à explicação? Som desligado nos comentários. Deseja ler mais respostas de outros usuários Tech-savvy Stack Exchange? Confira o tópico de discussão completo aqui.