Come posso verificare che un file da 1 TB sia trasferito correttamente?

Spesso trasferisco immagini di macchine virtuali da hypervisor a un server di archiviazione per l'archiviazione a lungo termine.

Trasferisco usando netcat poiché è più veloce di scp, rsync, ect ..

hypervisor$ cat foo.box | nc <archive IP> 1234

archive$ nc -l -p 1234 > foo.box

Quando il file ha terminato il trasferimento, verifico che non vi fosse corruzione eseguendo md5sumsia la destinazione che l'origine.

Sfortunatamente, l'esecuzione di un md5sum su un file di grandi dimensioni può richiedere molto tempo. Come posso confrontare più rapidamente l'integrità di due file di grandi dimensioni?

Aggiornare:

• La mia trasmissione raramente viene interrotta, quindi la possibilità di riavvio non è un problema.
• In genere sono necessarie 3-4 ore per il trasferimento tramite NC e quindi 40 minuti per ottenere il md5sum.
• La sicurezza dell'hash non è un problema in questo caso.

Puoi usare tee per fare la somma al volo con qualcosa del genere (adatta i comandi netcat alle tue esigenze):

Server:

netcat -l -w 2 1111 | tee >( md5sum > /dev/stderr )

Cliente:

tee >( md5sum > /dev/stderr ) | netcat 127.0.0.1 1111

La risposta di Nerdwaller sull'utilizzo teeper trasferire e calcolare contemporaneamente un checksum è un buon approccio se sei principalmente preoccupato per la corruzione in rete. Tuttavia, non ti proteggerà dalla corruzione sulla strada del disco, ecc., Poiché prende il checksum prima che colpisca il disco.

Ma vorrei aggiungere qualcosa:

1 TiB / 40 minuti ≈ 437 MiB / sec ¹ .

È piuttosto veloce, in realtà. Ricorda che a meno che tu non abbia molta RAM, deve tornare dalla memoria. Quindi la prima cosa da controllare è guardare iostat -kx 10mentre esegui i tuoi checksum; in particolare si desidera prestare attenzione alla %utilcolonna. Se stai agganciando i dischi (vicino al 100%), la risposta è acquistare spazio di archiviazione più veloce.

Altrimenti, come menzionato da altri poster, puoi provare diversi algoritmi di checksum. MD4, MD5 e SHA-1 sono tutti progettati per essere hash crittografici (anche se nessuno di questi dovrebbe essere più utilizzato a tale scopo; tutti sono considerati troppo deboli). Per quanto riguarda la velocità, puoi confrontarli con openssl speed md4 md5 sha1 sha256. Ho lanciato SHA256 per avere almeno un hash abbastanza forte.

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              61716.74k   195224.79k   455472.73k   695089.49k   820035.58k
md5              46317.99k   140508.39k   320853.42k   473215.66k   539563.35k
sha1             43397.21k   126598.91k   283775.15k   392279.04k   473153.54k
sha256           33677.99k    75638.81k   128904.87k   155874.91k   167774.89k

Di quanto sopra, puoi vedere che MD4 è il più veloce e SHA256 il più lento. Questo risultato è tipico dell'hardware simile al PC, almeno.

Se vuoi prestazioni ancora maggiori (a costo di essere banale da manomettere e anche meno probabilità di rilevare la corruzione), vuoi guardare un CRC o un hash Adler. Dei due, Adler è in genere più veloce, ma più debole. Sfortunatamente, non sono a conoscenza di implementazioni a riga di comando molto veloci; i programmi sul mio sistema sono tutti più lenti di md4 di OpenSSL.

Quindi, la tua migliore scommessa in termini di velocità è openssl md4 -r(la -rfa sembrare un output md5sum).

Se sei disposto a fare un po 'di compilazione e / o programmazione minima, vedi il codice di Mark Adler sopra Stack Overflow e anche xxhash . Se hai SSE 4.2, non sarai in grado di battere la velocità dell'istruzione CRC hardware.

¹ 1 TiB = 1024⁴ byte; 1 MiB = 1024² byte. Viene a ≈417 MB / sec con potenze di 1000 unità.

Il opensslcomando supporta diversi digest dei messaggi. Di quelli che sono stato in grado di provare, md4sembra funzionare circa il 65% delle volte md5e circa il 54% delle volte sha1(per il file con cui ho provato).

C'è anche un md2nella documentazione, ma sembra dare gli stessi risultati di md5.

Molto approssimativamente, la velocità sembra essere inversamente proporzionale alla qualità, ma poiché (probabilmente) non sei preoccupato per un avversario che crea una collisione deliberata, questo non dovrebbe essere un grosso problema.

Potresti cercare digest di messaggi più vecchi e più semplici (c'era un md1, per esempio)?

Un aspetto secondario: hai un uso inutile dicat . Piuttosto che:

cat foo.box | nc <archive IP> 1234

Puoi usare:

nc <archive IP> 1234 < foo.box

o anche:

< foo.box nc <archive IP> 1234

Ciò consente di risparmiare un processo, ma probabilmente non avrà alcun effetto significativo sulle prestazioni.

Due opzioni:

Uso sha1sum

sha1sum foo.box

In alcune circostanze sha1sum è più veloce .

Uso rsync

Il trasferimento richiederà più tempo, ma rsync verifica che il file sia arrivato intatto.

Dalla pagina man di rsync

Nota che rsync verifica sempre che ogni file trasferito sia stato correttamente ricostruito sul lato ricevente controllando un checksum di tutto il file che viene generato mentre il file viene trasferito ...

La scienza sta progredendo. Sembra che la nuova funzione hash BLAKE2 sia più veloce di MD5 (e crittograficamente molto più forte all'avvio).

Riferimento: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Dalle diapositive di Zooko:

cicli per byte su Intel Core i5-3210M (Ivy Bridge) 

cicli di funzione per byte

          messaggio lungo 4096 B 64 B
MD5 5.0 5.2 13.1
SHA1 4,7 4,8 13,7
SHA256 12,8 13,0 30,0
Keccak 8.2 8.5 26.0
BLAKE1 5.8 6.0 14.9
BLAKE2 3.5 3.5 9.3

Probabilmente non puoi fare di meglio di un buon hash. Potresti voler controllare altre funzioni hash / checksum per vedere se ce ne sono significativamente più veloci md5sum. Nota che potresti non aver bisogno di qualcosa di forte come MD5. MD5 (e cose come SHA1) sono progettate per essere crittograficamente forti, quindi è impossibile per un attaccante / impostore creare un nuovo file che abbia lo stesso valore hash di un valore esistente (cioè, per rendere difficile manomettere la firma e -mail e altri documenti). Se non sei preoccupato per un attacco alle tue comunicazioni, ma solo un errore comms of the mills, qualcosa come un controllo di ridondanza ciclica (CRC) potrebbe essere abbastanza buono. (Ma non so se sarebbe più veloce.)

Un altro approccio è quello di provare a fare l'hash in parallelo con il trasferimento. Ciò potrebbe ridurre il tempo complessivo e sicuramente ridurre il fattore di irritazione dovuto alla necessità di attendere il completamento del trasferimento, quindi attendere nuovamente il completamento dell'MD5. Non l'ho provato, ma dovrebbe essere possibile fare qualcosa del genere:

• Sulla macchina di origine:

  mkfifo myfifo
  tee myfifo < file_origine | nc dest_host  numero_porta e md5sum myfifo
  

• Sulla macchina di destinazione:

  mkfifo myfifo
  nc -l -p numero_porta | tee myfifo> dest_file & md5sum myfifo
  

Ovviamente controllare le dimensioni dei file è un buon modo rapido per rilevare l'eventuale perdita di byte.

L'invio di file di grandi dimensioni è una seccatura. Perché non provare a dividere i file generando un hash per ogni blocco, quindi inviarlo alla destinazione e quindi controllare l'hash e unire i blocchi.

È inoltre possibile configurare una rete BitTorrent personale. Ciò garantirebbe che l'intera cosa raggiunga in sicurezza.