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

Todos nós nos preocupamos em manter nossos dados e arquivos seguros e intactos, mas é possível que os dados sejam danificados e acessados ​​por um usuário sem uma notificação ou aviso de qualquer tipo sobre o problema? O post de perguntas e respostas do SuperUser de hoje tem a resposta para a pergunta de um preocupado leitor.

A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade..

Foto cortesia de generalização (Flickr).

A questão

SuperUser reader topo matar quer saber se os dados em discos rígidos podem degradar e ser acessado sem um aviso sobre o dano:

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

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

Os dados dos discos rígidos podem se degradar e ser acessados ​​sem um aviso sobre os danos?

A resposta

O colaborador do SuperUser Guntram Blohm tem a resposta para nós:

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

Quando um disco rígido grava um setor nos pratos, ele não apenas grava os bits da mesma maneira que eles são armazenados na RAM, ele usa uma codificação para garantir que não haja sequências do mesmo bit que sejam muito longas. Também adiciona códigos ECC que permitem reparar erros que afetam alguns bits e detectam erros que afetam mais do que 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 a seguir 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 tem problemas de código ECC, ele é passado para o sistema operacional.
• Se um setor pode ser reparado facilmente, a versão reparada pode ser gravada no disco, lida de volta, então verificada para determinar se o erro foi aleatório (isto é, raios cósmicos, etc.) ou se há um erro sistemático com a mídia.
• Se o disco rígido determinar que há um erro na mídia, ele realoca o setor.
• Se um setor não puder 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á, realocará o setor e informará ao controlador que houve um problema . Ele depende do controlador RAID para reconstruir o setor dos outros membros do RAID e gravá-lo no disco rígido com falha, que o armazena no setor realocado (que, espera-se, não tenha um problema).
• Se um setor não puder ser lido ou corrigido no disco rígido de um desktop, o disco rígido se envolverá em mais tentativas de lê-lo. Dependendo da qualidade do disco rígido, isso pode envolver o reposicionamento da cabeça, verificando se há alguns bits que são invertidos quando lidos repetidamente, verificando quais bits são os mais fracos e algumas outras coisas. Se qualquer uma dessas tentativas tiver êxito, o disco rígido realocará o setor e gravará os dados reparados..

Esta é uma das principais diferenças entre os discos rígidos vendidos como discos rígidos “desktop”, “NAS / RAID” ou “video surveillance”. Um disco rígido RAID pode simplesmente desistir rapidamente e fazer com que o controlador repare o setor para evitar a latência do lado do usuário. Um disco rígido de desktop continuará tentando de novo e de novo porque ter o usuário aguardando alguns segundos provavelmente é melhor do que dizer que os dados foram perdidos. E um disco rígido de vídeo valoriza taxas de dados constantes mais do que a recuperação de erros, já que um quadro danificado normalmente nem será notado.

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

• Eu nunca presenciei um único erro de bit, mas tenho visto muitos discos rígidos onde setores inteiros falharam.

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

Observe que o chkdsk e os sistemas de arquivos que se reparam automaticamente não resolvem os dados de reparo nos arquivos. Eles são direcionados à 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 autocorreção do NTFS detectará danos estruturais e evitará que ele afete ainda mais seus dados, mas não reparará nenhum dado que já esteja danificado.

Existem, é claro, outras razões pelas quais os dados podem ser danificados. Por exemplo, uma RAM ruim em um controlador pode alterar os dados antes mesmo de serem enviados para o disco rígido. Nesse caso, nenhum mecanismo no disco rígido detectará ou reparará os dados, e isso pode ser um dos motivos pelos quais a estrutura de um sistema de arquivos está danificada. Outros motivos incluem bugs de software, blecautes durante a gravação no disco rígido (embora isso seja resolvido pelo registro no diário do sistema de arquivos) ou drivers de sistema de arquivos inválidos (o driver NTFS no Linux padrão foi de somente leitura por um longo tempo desde que o NTFS foi projetado não documentado e os desenvolvedores não confiaram em seu próprio código).

• Eu tive este cenário uma vez onde um aplicativo salvaria todos os seus arquivos em dois servidores diferentes em dois datacenters diferentes para manter uma cópia de trabalho dos dados disponível sob todas as circunstâncias. Após alguns meses, notamos que cerca de 0,1% de todos os arquivos copiados não correspondiam à soma de verificação MD5 que o aplicativo armazenava em seu banco de dados. Acabou sendo um cabo de fibra defeituoso entre o servidor e a SAN.

Essas outras razões são por que alguns sistemas de arquivos, como o ZFS, mantêm informações adicionais de soma de verificação para detectar erros. Eles são projetados para protegê-lo de muito mais coisas que podem dar errado do que apenas um pouco de podridão.

Tem algo a acrescentar à explicação? Som desligado nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.