Como posso gerar e validar somas de verificação de arquivos com eficiência?

Como posso gerar e validar somas de verificação de arquivos com eficiência?

Gostaria de poder capturar e validar somas de verificação para coleções de arquivos em grande escala, normalmente aninhadas em uma hierarquia de diretórios complexa.

Cada arquivo precisa de uma soma de verificação? Existem maneiras de aproveitar a estrutura de diretórios existente para, digamos, validar apenas um nó na árvore de arquivos e não necessariamente todos os arquivos contidos nela?

Responder1

A maneira mais eficiente de usar somas de verificação é fazer com que o computador faça tudo. Use um sistema de arquivos como o ZFS, que faz somas de verificação (na verdade, usa hashes, que são mais fortes que uma soma de verificação) de todos os dados quando são gravados e os verifica sempre que os dados são lidos. Claro, a desvantagem é que o ZFS não sabe quando excluir ou sobrescrever um arquivo é um erro e quando é uma operação normal, mas como o ZFS usa a semântica de cópia na gravação para tudo, você pode usar seu recurso de instantâneo para mitigar o risco .

O ZFS também pode restaurar automaticamente dados que falham em uma verificação de hash usando qualquer redundância que você configurou, seja paridade no estilo raid5, espelhos de unidade ou cópias duplicadas (adicione a propriedade copys=N a qualquer sistema de arquivos ZFS e ele armazenará N cópias de quaisquer dados que você escreve). Ele também armazena os hashes em uma árvore Merkle, onde o valor do hash de um arquivo depende dos hashes dos blocos, o hash de uma entrada de diretório depende dos valores de hash dos arquivos e diretórios que ele contém, o hash de um sistema de arquivos depende no hash do diretório raiz, etc.

Independentemente da solução escolhida, você invariavelmente descobrirá que o processo é limitado pela velocidade dos seus discos, não pela velocidade da sua CPU.

Além disso, não esqueça de levar em consideração o BER dos seus discos. Afinal, eles são meras placas de ferrugem giratória. Uma unidade de nível de consumidor tem uma taxa de erro de 1 bit lido incorretamente para cada 10 ^ 14 bits lidos, o que equivale a 1 bit em cada 11 terabytes lidos. Se você tiver um conjunto de dados de 11 terabytes e calcular o hash de cada arquivo nele contido, terá calculado uma dessas somas de verificação incorretamente e danificará permanentemente um bloco de um dos arquivos no conjunto de dados. O ZFS, entretanto, conhece o hash de cada bloco gravado em cada disco do seu pool e, portanto, sabe qual bloco foi perdido. Ele pode então usar a redundância (paridade, espelhos ou cópias extras) em seu pool para reescrever os dados nesse bloco com os valores corretos. Esses recursos de segurança também se aplicam quando você usa o envio ou recebimento do zfs para copiar dados do seu sistema primário para os backups.

Ben traz à tona um bom ponto nos comentários. O ZFS não expõe ao usuário nenhum dos valores de hash que calcula, portanto, os dados que entram ou saem de um sistema ZFS devem ser acompanhados de hashes. Gosto da maneira como o Internet Archive faz isso com um arquivo xml que acompanha cada item do arquivo. Verhttps://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xmlcomo um exemplo.

Responder2

Talvez este seja um bom momento para trazer à tonaSacola. Este é um formato de empacotamento de arquivo muito simples, mas poderoso, destinado ao arquivamento, preservação a longo prazo e transferência de objetos digitais. Os usuários incluem a Biblioteca do Congresso e a Biblioteca Digital da Califórnia.

Uma ferramenta BagIt (elas existem em várias linguagens de programação) coloca seus arquivos em uma determinada estrutura de diretórios e faz a soma de verificação/hashing para você. Isso é tudo.

PS: Claro, as ferramentas BagIt também podem verificar as malas em relação às somas de verificação/hashes incluídas, e você pode adicionar alguns metadados às malas. Mas isso é tão complexo quanto as malas podem ser.

Responder3

Eu geraria soma de verificação para cada arquivo. As somas de verificação são muito pequenas, e gerar a soma de verificação para todo o diretório exigiria que você processasse todos os arquivos também (pelo menos se você não estiver falando sobre a soma de verificação do diretório, feita apenas a partir de entradas de diretório - eu também as faria, para garantir que nenhum dado esta deletado).

Suponha que você tenha uma soma de verificação para todo o arquivo. Você sabe que os dados estão corrompidos, mas não sabe se se trata apenas de um arquivo e, mais importante, qual deles. Ter somas de verificação separadas oferece mais flexibilidade. Você pode detectar um único arquivo que está corrompido e substituí-lo pelo arquivo de outro backup (que pode, por sua vez, ter outro arquivo corrompido).

Dessa forma, é mais provável que seus dados sobrevivam.

Responder4

Analisei as respostas e, embora goste da ideia de confiar no ZFS para lidar com os erros da camada de dados, ainda há o problema de os arquivos serem alterados, por engano ou maliciosamente. O ZFS não protegerá você nesse caso e, como alguém mencionou, não fornecerá um "hash" visível ao usuário para armazenar em outro lugar para validação externa.

Existe um aplicativo Linux chamado TripWire que foi amplamente usado para monitorar executáveis ​​do sistema, para validar se eles não foram alterados após um ataque. Aparentemente, esse projeto está abandonado, mas há um novo chamado AIDE (Advanced Intrusion Detection Environment), recomendado no ServerFault:

https://serverfault.com/questions/62539/tripwire-and-alternatives

Quando você instala, ele é executado a cada x minutos, configurável pelo usuário, e verifica todas as pastas especificadas em busca de alterações nos arquivos. Ele precisa ser executado uma vez para calcular todos os hashes do arquivo e, depois disso, verifica todos os hashes no arquivo atual e garante que ainda sejam os mesmos. Você pode especificar qual tipo de hash ou combinação de hashes usar (eu não recomendaria nada mais fraco que SHA-256), quais atributos de arquivo usar (conteúdo, tamanho, carimbo de data/hora modificado, etc.), a frequência com que ele verifica, como/onde armazenar o banco de dados hash, etc.

Alguns podem considerar isso um exagero, mas dependendo dos requisitos do OP, isso pode lhe dar mais tranquilidade, pois os dados que ele está armazenando permanecerão os mesmos após um determinado período de tempo.

informação relacionada