Comment puis-je vérifier qu'un fichier de 1 To a été transféré correctement?

Je transfère fréquemment des images de machine virtuelle des hyperviseurs vers un serveur d'archives pour un stockage à long terme.

Je transfère en utilisant netcat car il est plus rapide que scp, rsync, ect ..

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

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

Une fois le transfert du fichier terminé, je vérifie qu'il n'y a pas eu de corruption en exécutant md5sumà la fois la cible et la source.

Malheureusement, l'exécution d'une somme md5 sur un fichier volumineux peut prendre très longtemps. Comment comparer plus rapidement l'intégrité de deux gros fichiers?

Mise à jour:

• Ma transmission est rarement interrompue, donc la capacité de redémarrage n'est pas un problème.
• Il faut généralement 3-4 heures pour transférer via NC, puis 40 minutes pour obtenir la somme md5.
• La sécurité du hachage n'est pas un problème dans ce cas.

Vous pouvez utiliser tee pour faire la somme à la volée avec quelque chose comme ça (adaptez les commandes netcat à vos besoins):

Serveur:

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

Client:

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

La réponse de Nerdwaller à propos de l'utilisation teepour transférer et calculer simultanément une somme de contrôle est une bonne approche si vous êtes principalement préoccupé par la corruption sur le réseau. Il ne vous protégera pas contre la corruption sur le chemin du disque, etc., car il prend la somme de contrôle avant qu'il ne frappe le disque.

Mais je voudrais ajouter quelque chose:

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

C'est assez rapide, en fait. N'oubliez pas que si vous n'avez pas beaucoup de RAM, cela doit revenir du stockage. Donc, la première chose à vérifier est de regarder iostat -kx 10pendant que vous exécutez vos sommes de contrôle; en particulier, vous voulez faire attention à la %utilcolonne. Si vous fixez les disques (près de 100%), la réponse est d'acheter un stockage plus rapide.

Sinon, comme d'autres affiches l'ont mentionné, vous pouvez essayer différents algorithmes de somme de contrôle. MD4, MD5 et SHA-1 sont tous conçus pour être des hachages cryptographiques (bien qu'aucun de ceux-ci ne devrait plus être utilisé à cette fin; tous sont considérés comme trop faibles). En termes de vitesse, vous pouvez les comparer avec openssl speed md4 md5 sha1 sha256. J'ai jeté dans SHA256 pour avoir au moins un hachage encore assez fort.

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 ce qui précède, vous pouvez voir que MD4 est le plus rapide et SHA256 le plus lent. Ce résultat est typique sur du matériel de type PC, au moins.

Si vous voulez encore plus de performances (au prix d'être triviales à falsifier et également moins susceptibles de détecter la corruption), vous voulez regarder un hachage CRC ou Adler. Des deux, Adler est généralement plus rapide, mais plus faible. Malheureusement, je ne connais aucune implémentation de ligne de commande vraiment rapide; les programmes sur mon système sont tous plus lents que le md4 d'OpenSSL.

Donc, votre meilleur pari en termes de vitesse est openssl md4 -r(le -rfait ressembler à une sortie md5sum).

Si vous êtes prêt à faire de la compilation et / ou une programmation minimale, consultez le code de Mark Adler sur Stack Overflow et également xxhash . Si vous avez SSE 4.2, vous ne pourrez pas battre la vitesse de l'instruction matérielle CRC.

¹ 1 TiB = 1024⁴ octets; 1 Mio = 1024² octets. Vient à 17417MB / sec avec des puissances de 1000 unités.

La opensslcommande prend en charge plusieurs résumés de messages. Parmi ceux que j'ai pu essayer, md4semble fonctionner dans environ 65% du temps md5et environ 54% du temps sha1(pour le seul fichier que j'ai testé).

Il y a aussi un md2dans la documentation, mais il semble donner les mêmes résultats que md5.

En gros, la vitesse semble être inversement liée à la qualité, mais puisque vous n'êtes (probablement) pas préoccupé par un adversaire créant une collision délibérée, cela ne devrait pas être un gros problème.

Vous pourriez chercher des résumés de messages plus anciens et plus simples (y en avait-il un md1, par exemple)?

Un point mineur: vous avez une utilisation inutile decat . Plutôt que:

cat foo.box | nc <archive IP> 1234

vous pouvez utiliser:

nc <archive IP> 1234 < foo.box

ou même:

< foo.box nc <archive IP> 1234

Cela permet d'économiser un processus, mais n'aura probablement aucun effet significatif sur les performances.

Deux options:

Utilisation sha1sum

sha1sum foo.box

Dans certaines circonstances, le sha1sum est plus rapide .

Utilisation rsync

Le transfert prendra plus de temps, mais rsync vérifie que le fichier est arrivé intact.

Depuis la page de manuel de rsync

Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté réception en vérifiant une somme de contrôle de fichier entier qui est générée lors du transfert du fichier ...

La science progresse. Il semble que la nouvelle fonction de hachage BLAKE2 soit plus rapide que MD5 (et cryptographiquement beaucoup plus puissante pour démarrer).

Référence: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Des diapositives de Zooko:

cycles par octet sur la fonction Intel Core i5-3210M (Ivy Bridge) 

cycles par octet

          msg long 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

Vous ne pouvez probablement pas faire mieux qu'un bon hachage. Vous voudrez peut-être vérifier d'autres fonctions de hachage / somme de contrôle pour voir si certaines sont beaucoup plus rapides que md5sum. Notez que vous pourriez ne pas avoir besoin de quelque chose d'aussi solide que MD5. MD5 (et des choses comme SHA1) sont conçues pour être cryptographiquement solides, il est donc impossible pour un attaquant / imposteur de créer un nouveau fichier qui a la même valeur de hachage qu'une valeur existante (c.-à-d., Pour qu'il soit difficile de falsifier l'e signé) -mails et autres documents). Si vous n'êtes pas préoccupé par une attaque sur vos communications, mais uniquement par une erreur de communication courante, quelque chose comme un contrôle de redondance cyclique (CRC) peut être suffisant. (Mais je ne sais pas si ce serait plus rapide.)

Une autre approche consiste à essayer de faire le hachage en parallèle avec le transfert. Cela pourrait réduire le temps global et pourrait certainement réduire le facteur d'irritation d'avoir besoin d'attendre la fin du transfert, puis d'attendre à nouveau la fin du MD5. Je n'ai pas testé cela, mais il devrait être possible de faire quelque chose comme ça:

• Sur la machine source:

  mkfifo myfifo
  tee myfifo < fichier_source | nc dest_host  numéro_port & md5sum myfifo
  

• Sur la machine de destination:

  mkfifo myfifo
  nc -l -p numéro_port | tee myfifo> dest_file & md5sum myfifo
  

Bien sûr, la vérification de la taille des fichiers est un bon moyen rapide de détecter si des octets ont été supprimés.

L'envoi de fichiers volumineux est pénible. Pourquoi ne pas essayer de fragmenter les fichiers en générant un hachage pour chaque morceau, puis de l'envoyer à la destination, puis de vérifier le hachage et de joindre les morceaux.

Vous pouvez également configurer un réseau BitTorrent personnel. Cela garantirait que le tout parvienne en toute sécurité.