Come posso generare e validare in modo efficiente i checksum dei file?


12

Mi piacerebbe essere in grado di acquisire e convalidare checksum per raccolte di file su larga scala, in genere nidificate all'interno di una gerarchia di directory complessa.

Ogni singolo file ha bisogno di un checksum? Esistono modi per sfruttare la struttura di directory esistente per, ad esempio, convalidare solo un nodo nella struttura dei file e non necessariamente tutti i file all'interno?


Come notano le risposte, è importante distinguere i tipi di minacce che si stanno mitigando e il checksum di conseguenza. Una precedente risposta di Overflow dello stack di Library and Information Science che ho contribuito potrebbe essere interessante, sebbene riguardi principalmente HDFS.
Andy Jackson,

Risposte:


13

Il modo più efficiente di utilizzare i checksum è fare in modo che il computer faccia tutto. Usa un filesystem come ZFS che controlla (in realtà usa hash, che sono più forti di un checksum) tutti i dati quando vengono scritti e li verifica ogni volta che vengono letti. Ovviamente, il rovescio della medaglia è che ZFS non sa quando cancellare o sovrascrivere un file è un errore e quando si tratta di un'operazione normale, ma poiché ZFS utilizza la semantica di copia su scrittura per tutto, puoi usare la sua funzione di snapshot per mitigare il rischio .

ZFS può anche ripristinare automaticamente i dati che non superano un controllo hash usando qualsiasi ridondanza che hai impostato, sia parità in stile raid5, mirror di unità o copie duplicate (aggiungi la proprietà copia = N a qualsiasi file system ZFS e memorizzerà N copie di tutti i dati che scrivi). Memorizza anche gli hash in un albero Merkle, dove il valore di hash di un file dipende dagli hash dei blocchi, l'hash di una voce di directory dipende dai valori di hash dei file e delle directory che contiene, l'hash di un filesystem dipende sull'hash della directory principale, ecc.

Indipendentemente dalla soluzione con cui ti trovi, troverai inevitabilmente che il processo è limitato dalla velocità dei tuoi dischi, non dalla velocità della tua CPU.

Inoltre, non dimenticare di prendere in considerazione il BER dei tuoi dischi. Dopotutto, sono semplici piatti di ruggine che gira. Un'unità di livello consumer ha un tasso di errore di 1 bit letto in modo errato per ogni 10 ^ 14 bit letti, che risulta a 1 bit su ogni 11 terabyte letti. Se si dispone di un set di dati da 11 terabyte e si calcola l'hash di ogni file al suo interno, si avrà calcolato uno di questi checksum in modo errato e danneggiato in modo permanente un blocco di uno dei file nel set di dati. ZFS, tuttavia, conosce l'hash di ogni blocco che ha scritto su ogni disco del pool e quindi sa quale blocco è stato perso. Può quindi utilizzare la ridondanza (parità, mirror o copie extra) nel pool per riscrivere i dati in quel blocco con i valori corretti.

Ben sottolinea tuttavia un buon punto nei commenti. ZFS non espone nessuno dei valori di hash che calcola all'utente, quindi i dati che entrano o escono da un sistema ZFS devono essere accompagnati da hash. Mi piace il modo in cui Internet Archive lo fa con un file XML che accompagna ogni elemento nell'archivio. Vedi https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml come esempio.


1
Mi hai battuto sul tempo. Stavo anche per suggerire un sistema basato sull'hash. Hash di ogni file, hash degli hash di file (+ hash della sottodirectory) per un hash di directory ecc. Il compromesso è CPU / IO vs probabilità di errore. Checksum / CRC è economico ma la probabilità di errore aumenta con la scala. Quindi fanno hash comuni ma iniziano con una probabilità di errore molto più bassa.
The Diamond Z,

3
Anche se esegui un file system come ZFS (Btrfs ha anche funzionalità simili, ma è ancora in fase di sviluppo pesante e non è considerato pronto per l'uso in produzione in questo momento) dovrai eseguire un'operazione di "scrub" periodica per assicurarti che i dati siano letto e verificato rispetto ai checksum o agli hash. Il solo calcolo dei checksum e quindi non fare nulla con loro fino a quando non è necessario l' accesso ai dati è potenzialmente peggio che senza valore.
un CVn

1
Sì, è un buon punto. Il mio ultimo scrub ha corretto 2 kilobyte di dati che erano andati male. Sono quattro blocchi sparsi su cinque unità! Più si passa tra le letture di un determinato dato, maggiore è la probabilità che si accumulino abbastanza errori in un singolo file da non riuscire a recuperarlo.

1
L'esecuzione di uno spazio utenti md5sum su circa 150 GB di dati sul mio PC di casa ha richiesto circa 40 minuti di tempo di wallclock, puramente associato a I / O. Aumentando di 100 volte, otteniamo 15 TB controllati su una tonalità in meno di tre giorni, su hardware di consumo. Lo considererei certamente fattibile anche su un grande archivio, con un intervallo correttamente selezionato.
un CVn

3
ZFS calcola i checksum per blocchi, non file o flussi di bit, no? Mentre ZFS risolve il problema di calcolo, sembrerebbe che sia meno controllabile dall'uomo e non stia producendo dati di fissità portatili indipendentemente dal filesystem - qualcosa che è un must per gli archivi.

6

Genererei checksum per ogni file. I checksum sono molto piccoli e la generazione di checksum per l'intera directory richiederebbe anche l'elaborazione di tutti i file (almeno se non si parla di checksum di directory, fatto solo da voci di directory - anch'io li farei, per garantire che non ci siano dati è cancellato).

Supponiamo di avere un checksum per l'intero archivio. Sai che i dati sono danneggiati, ma non sai se questo è solo un file e, cosa più importante, quale di essi. Avere checksum separati ti dà maggiore flessibilità. È possibile rilevare un singolo file danneggiato e sostituirlo dal file da un altro backup (che a sua volta può avere un altro file danneggiato).

In questo modo i tuoi dati hanno maggiori probabilità di sopravvivere.


Questo ha sicuramente senso. Mi sto solo chiedendo quali strategie esistano per gestire l'impresa computazionalmente costosa di generare e controllare centinaia di migliaia di checksum.

4

Forse è un buon momento per far apparire BagIt . Questo è un formato di packaging di file molto semplice ma potente destinato all'archiviazione, alla conservazione a lungo termine e al trasferimento di oggetti digitali. Gli utenti includono la Library of Congress e la California Digital Library.

Uno strumento BagIt (esistono in diversi linguaggi di programmazione) inserisce i tuoi file in una determinata struttura di directory e fa il checksum / hashing per te. Questo è tutto.

PS: Naturalmente, gli strumenti BagIt possono anche verificare i sacchi rispetto ai checksum / hash inclusi e puoi aggiungere alcuni metadati ai sacchi. Ma è complesso come le borse.


1

Questa risposta è una combinazione di quella di @lechlukasz e @ db48x , incorporando anche alcuni punti espressi nei commenti e alcuni dei miei pensieri.

Il semplice percorso da seguire è un approccio combinato di file system e metadati separati.

Utilizzando un file system che esegue l'hashing e la convalida dei dati al volo, come ZFS o Btrfs (si noti che sebbene siano stati fatti grandi progressi, Btrfs non è considerato pronto per l'uso in produzione in questo momento), si può essere ragionevolmente sicuro che se i dati possono essere letti dal disco senza errori del sistema operativo, i dati letti sono stati scritti sul disco nel modo previsto dal file system. Eseguendo periodiche operazioni di "scrub", tutti i dati vengono letti e verificati rispetto all'idea del file system di ciò che dovrebbe essere.

Tuttavia, ciò protegge solo dalla corruzione su disco (blocchi illeggibili, errori di scrittura dell'hardware, scritture non valide che danneggiano parti dei dati direttamente sul dispositivo a blocchi, ecc.). Non protegge da un bug del software, da un funzionamento errato dell'utente o da software dannoso che funziona attraverso le funzionalità del sistema operativo previste per lavorare con i file, supponendo che tali strutture siano prive di tali bug.

Per proteggerti da quest'ultimo, hai bisogno di un altro livello di protezione. I dati di checksum o hashing dal punto di vista di un'applicazione utente aiuteranno a proteggere da molti dei rischi sopra menzionati, ma devono essere eseguiti separatamente (sia come azione di processo integrata nel software, sia come processo completamente separato).

Con l'hardware di oggi e ciò che è pratico per l'archiviazione di grandi quantità di dati (dischi rigidi del disco rotante rispetto ai dischi / SSD a stato solido), anche gli algoritmi di hashing complessi come SHA1 saranno in gran parte legati all'I / O - cioè alla velocità a cui i dati vengono sottoposti a hash sarà una funzione della velocità di lettura del sistema di archiviazione, piuttosto che la capacità del processore del computer di calcolare l'hash. Ho fatto un esperimento con l'esecuzione di un processo di hashing MD5 nello spazio utente su circa 150 GB di dati su quello che nel 2012 era un PC consumer di livello intermedio e si è concluso dopo aver esercitato il disco praticamente senza interruzioni per circa 40 minuti. Scalando quelle cifre di 100 volte, otterresti gli hash MD5 di una raccolta da 15 TB in circa tre giorni sullo stesso hardware. Aggiungendo la velocità di trasferimento in lettura (che può essere facilmente raggiunta ad esRAID 0, ad esempio, sta eseguendo lo striping senza ridondanza, comunemente utilizzato per ottenere prestazioni di lettura / scrittura più elevate, possibilmente in combinazione con RAID 1 che forma RAID 10 ), il tempo di completamento può essere ridotto per la stessa quantità di dati.

Combinando i due, ottieni il meglio da entrambi i mondi: il file system ti dà la certezza che ciò che hai ricevuto durante la lettura del file è ciò che è stato effettivamente scritto, e un processo separato di verifica della fissità può essere eseguito su tutta la raccolta assicurando che i dati memorizzato corrisponde ancora a ciò che è stato ingerito nell'archivio. Qualsiasi incoerenza tra i due (il file system dice che il file è OK, il controllo di fissità dice che non lo è) indicherà un file che è stato modificato al di fuori della modalità di funzionamento prevista dell'archivio ma all'interno delle strutture del sistema operativo, richiedendo un ripristino da un secondario copia (backup). Il controllo di fissità può quindi essere eseguito a un intervallo di tempo più lungo, il che diventa essenziale per archivi molto grandi, ma è comunque garantito che eventuali accessi online non vengano danneggiati sull'hardware se le letture hanno esito positivo. In linea di principio, il software di archiviazione potrebbe fare affidamento sul file system per segnalare incoerenze come errori di lettura ed eseguire un controllo di fissità separato in background mentre l'utente sta lavorando con il file e visualizzando un messaggio appropriato che dovrebbe indicare che il file non corrisponde a ciò che è stato ingerito nell'archivio. Utilizzando un file system con hashing a blocchi, un tale schema avrebbe un impatto minimo sulle prestazioni percepite, garantendo comunque che il contenuto sia corretto.


1

Ho esaminato le risposte e anche se mi piace l'idea di fare affidamento su ZFS per gestire gli errori del livello dati, c'è ancora il problema che i file vengano cambiati, per errore o in modo dannoso. In questo caso ZFS non ti proteggerà e, come qualcun altro menzionato, non ti darà un "hash" visualizzabile dall'utente per archiviare altrove per la convalida esterna.

Esiste un'applicazione Linux chiamata TripWire che è stata ampiamente utilizzata per monitorare gli eseguibili del sistema, per confermare che non sono stati modificati dopo un attacco. Apparentemente quel progetto ora è abbandonato, ma ce n'è uno nuovo chiamato AIDE (Advanced Intrusion Detection Environment), consigliato sopra su ServerFault:

/server/62539/tripwire-and-alternatives

Durante l'installazione, verrebbe eseguito ogni x minuti, configurabile dall'utente, e controllerebbe tutte le cartelle specificate per le modifiche nei file. Deve essere eseguito una volta per calcolare tutti gli hash dei file, quindi verifica tutti gli hash rispetto al file corrente e si assicura che siano sempre gli stessi. Puoi specificare quale tipo di hash o combinazione di hash usare (non consiglierei nulla di più debole di SHA-256), quali attributi di file usare (contenuto, dimensioni, timestampst modificato, ecc.), La frequenza con cui controlla, come / dove archiviare il database hash, ecc.

Alcuni potrebbero considerare questo eccessivo, ma a seconda dei requisiti del PO, potrebbe dargli più tranquillità che i dati che sta conservando rimarranno gli stessi dopo un certo periodo di tempo.


0

L'Archivio nazionale australiano ha sviluppato [Checksum Checker] ( http://checksumchecker.sourceforge.net/ ) che è disponibile gratuitamente con GPLv3.

Legge un checksum e un algoritmo da un database, quindi ricalcola il checksum per il file, confronta i due valori e segnala se si è verificato un errore. Supporta gli algoritmi MD5, SHA1, SHA2, SHA256 e SHA512.

Altri software nel loro repository digitale [DPR] ( http://dpr.sourceforge.net/ ) generano il checksum iniziale (oltre a fare tutte le altre attività di elaborazione)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.