¿Cómo puedo verificar que un archivo de 1TB se transfirió correctamente?

Con frecuencia transfiero imágenes de VM de hipervisores a un servidor de archivo para el almacenamiento a largo plazo.

Transfiero usando netcat ya que es más rápido que scp, rsync, ect ..

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

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

Cuando el archivo ha terminado de transferirse, verifico que no hubo corrupción al ejecutar md5sumtanto en el destino como en la fuente.

Desafortunadamente, ejecutar un md5sum en un archivo grande puede llevar mucho tiempo. ¿Cómo puedo comparar más rápidamente la integridad de dos archivos grandes?

Actualizar:

• Mi transmisión rara vez se interrumpe, por lo que la capacidad de reinicio no es un problema.
• Por lo general, tarda de 3 a 4 horas en transferirse a través de NC y luego 40 minutos para obtener el md5sum.
• La seguridad del hash no es un problema en este caso.

Puede usar tee para hacer la suma sobre la marcha con algo como esto (adapte los comandos netcat a sus necesidades):

Servidor:

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

Cliente:

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

La respuesta de Nerdwaller sobre el uso teepara transferir y calcular simultáneamente una suma de verificación es un buen enfoque si está principalmente preocupado por la corrupción en la red. Sin embargo, no lo protegerá contra la corrupción en el camino al disco, etc., ya que toma la suma de comprobación antes de que llegue al disco.

Pero me gustaría agregar algo:

1 TiB / 40 minutos ≈ 437 MiB / seg ¹ .

Eso es bastante rápido, en realidad. Recuerde que a menos que tenga mucha RAM, eso tiene que volver del almacenamiento. Entonces, lo primero que debe verificar es observar iostat -kx 10mientras ejecuta sus sumas de verificación; en particular quieres prestar atención a la %utilcolumna. Si está vinculando los discos (cerca del 100%), la respuesta es comprar un almacenamiento más rápido.

De lo contrario, como se mencionó en otros carteles, puede probar diferentes algoritmos de suma de verificación. MD4, MD5 y SHA-1 están diseñados para ser hashes criptográficos (aunque ninguno de ellos debe usarse para ese fin; todos se consideran demasiado débiles). En cuanto a la velocidad, puede compararlos con openssl speed md4 md5 sha1 sha256. He lanzado SHA256 para tener al menos un hash lo suficientemente fuerte.

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

De lo anterior, puede ver que MD4 es el más rápido y SHA256 el más lento. Este resultado es típico en hardware similar a una PC, al menos.

Si desea aún más rendimiento (a costa de ser trivial para manipular, y también es menos probable que detecte la corrupción), desea ver un hash CRC o Adler. De los dos, Adler suele ser más rápido, pero más débil. Desafortunadamente, no conozco ninguna implementación de línea de comando realmente rápida; Los programas en mi sistema son todos más lentos que el md4 de OpenSSL.

Por lo tanto, su mejor apuesta en cuanto a velocidad es openssl md4 -r( -rlo que hace que se vea como salida md5sum)

Si está dispuesto a hacer una compilación y / o programación mínima, vea el código de Mark Adler en Stack Overflow y también xxhash . Si tiene SSE 4.2, no podrá superar la velocidad de la instrucción CRC de hardware.

¹ 1 TiB = 1024⁴ bytes; 1 MiB = 1024² bytes. Viene a ≈417MB / seg con potencias de 1000 unidades.

El opensslcomando admite varios resúmenes de mensajes. De los que pude probar, md4parece ejecutarse en aproximadamente el 65% del tiempo md5y aproximadamente el 54% del tiempo sha1(para el archivo con el que probé).

También hay un md2en la documentación, pero parece dar los mismos resultados que md5.

En términos generales, la velocidad parece estar inversamente relacionada con la calidad, pero dado que (probablemente) no le preocupa que un adversario cree una colisión deliberada, eso no debería ser un gran problema.

Es posible que busque resúmenes de mensajes más antiguos y simples (¿hubo un md1, por ejemplo)?

Un punto menor: tienes un uso inútil decat . Más bien que:

cat foo.box | nc <archive IP> 1234

puedes usar:

nc <archive IP> 1234 < foo.box

o incluso:

< foo.box nc <archive IP> 1234

Hacerlo ahorra un proceso, pero probablemente no tendrá ningún efecto significativo en el rendimiento.

Dos opciones:

Utilizar sha1sum

sha1sum foo.box

En algunas circunstancias, sha1sum es más rápido .

Utilizar rsync

La transferencia llevará más tiempo, pero rsync verifica que el archivo llegó intacto.

Desde la página de manual de rsync

Tenga en cuenta que rsync siempre verifica que cada archivo transferido se haya reconstruido correctamente en el lado receptor al verificar una suma de comprobación de todo el archivo que se genera a medida que se transfiere el archivo ...

La ciencia está progresando. Parece que la nueva función hash BLAKE2 es más rápida que MD5 (y criptográficamente mucho más fuerte para arrancar).

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

De las diapositivas de Zooko:

ciclos por byte en la función Intel Core i5-3210M (Ivy Bridge) 

ciclos por byte

          mensaje largo 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

Probablemente no puedas hacer nada mejor que un buen hash. Es posible que desee comprobar otras funciones hash / checksum para ver si alguna es significativamente más rápida que md5sum. Tenga en cuenta que es posible que no necesite algo tan fuerte como MD5. MD5 (y cosas como SHA1) están diseñadas para ser criptográficamente fuertes, por lo que no es factible que un atacante / impostor cree un nuevo archivo que tenga el mismo valor hash que un valor existente (es decir, dificultar la manipulación de e firmado -mails y otros documentos). Si no le preocupa un ataque a sus comunicaciones, pero solo un error de comunicación común, algo como una verificación de redundancia cíclica (CRC) podría ser lo suficientemente bueno. (Pero no sé si sería más rápido).

Otro enfoque es intentar hacer el hash en paralelo con la transferencia. Esto podría reducir el tiempo total, y definitivamente podría reducir el factor de irritación de la necesidad de esperar a que termine la transferencia y luego esperar nuevamente a que termine el MD5. No he probado esto, pero debería ser posible hacer algo como esto:

• En la máquina fuente:

  mkfifo myfifo
  tee myfifo < archivo_origen | nc dest_host  número_puerto y md5sum myfifo
  

• En la máquina de destino:

  mkfifo myfifo
  nc -l -p número_puerto | tee myfifo> dest_file & md5sum myfifo
  

Por supuesto, verificar el tamaño de los archivos es una forma buena y rápida de detectar si se eliminó algún byte.

Enviar archivos enormes es una molestia. ¿Por qué no intentar fragmentar los archivos generando un hash para cada fragmento y luego enviarlo al destino y luego verificar el hash y unir los fragmentos?

También puede configurar una red personal de BitTorrent. Eso aseguraría que todo llegue a salvo.