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

25

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.
tbenz9
la source
2
Vous pouvez essayer différentes sommes de contrôle: en.wikipedia.org/wiki/Checksum . Je ne connais pas leur performance cependant
tumchaaditya
Combien de temps dure le transfert et combien de temps prend la somme md5?
Keith Thompson
Le transfert prend généralement entre 3 et 4 heures et les sommes md5 prennent environ 40 minutes à calculer.
tbenz9

Réponses:

18

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
nerdwaller
la source
1
Juste une pensée: md5deepa un mode "chunk" ( md5deep.sourceforge.net/md5deep.html ) qui peut être utile pour cela.
LawrenceC
@ultrasawblade - C'est un lien génial, je vais devoir vérifier cela à d'autres fins. Merci de l'avoir mentionné!
nerdwaller
10

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 1 .

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 1 TiB = 1024⁴ octets; 1 Mio = 1024² octets. Vient à 17417MB / sec avec des puissances de 1000 unités.

derobert
la source
C'est rapide, je copie d'une grande matrice RAID vers une 2ème grande matrice RAID.
tbenz9
@ tbenz9 J'ai pensé, pas question que ce soit un seul disque! J'ai ajouté quelques pointeurs vers des hachages vraiment rapides, qui nécessiteront malheureusement au moins de les compiler ... Mais ils fonctionneront sûrement aussi vite que vos disques (ou même votre RAM) peuvent fournir les données. (Et si vous vous interrogez sur Mark Adler v. Adler32, oui, cela semble être le créateur d'Adler32)
derobert
@derobert, Au lieu d'utiliser de petits fichiers pour tester, n'auriez-vous pas dû le tester avec un gros fichier comme 1 To?
Pacerier
@derobert, pourquoi n'utilisez-vous pas à la shasumplace?
Pacerier
@Pacerier, c'est la sortie du benchmark intégré d'OpenSSL. Sans doute avec des blocs plus longs, ce sera un peu plus rapide, mais le classement ne changera probablement pas (il était cohérent dans toutes les tailles testées). Shasum a-t-il une implémentation plus rapide qu'OpenSSL? Bien honnêtement, si vous voulez un hachage cryptographique rapide, vous utiliserez BLAKE2.
derobert
9

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.

Keith Thompson
la source
1
Merci pour l'astuce sur le chat, sans rapport avec la question mais néanmoins une astuce utile. À votre santé!
tbenz9
@ tbenz9: le code lisible est plus facile à déboguer, à maintenir et à modifier. "Inutile cat" n'est donc pas nécessairement entièrement mauvais. S'il n'y a pas de gain de performances en l'évitant, il est préférable d'aller avec tout ce qui vous convient le mieux, en supposant que vous serez le responsable de ce code.
iconoclaste du
1
@Keith, Lien vers le bas ..
Pacerier
4

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 ...

spuder
la source
1
Merci pour l'astuce sur sha1sum, rsync prend plus de 10 heures pour être transféré, je peux transférer le même fichier et exécuter les md5sums en environ 4 heures en utilisant nc et md5sum. J'essaie de réduire encore mes 4 heures.
tbenz9
3

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
Ninveh
la source
2

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.

Scott
la source
2

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é.

Gaurav Joseph
la source
Ma compréhension est que, comme il s'agit d'une source et d'une destination, un réseau BitTorrent ne serait pas bénéfique. Cela ne profite-t-il que lorsqu'il va vers de nombreuses destinations à partir de nombreuses sources?
tbenz9
J'ai envisagé de suggérer cette approche (diviser le fichier d'entrée en morceaux, les envoyer séparément et les réassembler à l'autre extrémité) et je n'ai pas pu trouver comment le rendre même neutre en termes de performances, sans parler d'une amélioration. Vous avez toujours le même temps de transfert réseau, mais vous avez beaucoup plus de temps à chaque extrémité. Cela implique essentiellement de copier le fichier de la machine source sur la machine source , puis de le copier sur la machine de destination, puis de le copier de la machine de destination sur la machine de destination . Même avec de gros disques RAM, ce n'est pas gratuit.
Scott
1
Le seul avantage de cette approche est la possibilité de redémarrage, y compris une récupération plus rapide après une panne de transmission. L'OP n'a pas dit combien de fois il avait des échecs et n'a pas indiqué que c'était quelque chose qu'il souhaitait optimiser.
Scott
@ tben9 Bittorrent est l'outil de choix actuel pour le transfert unique de fichiers. La possession des informations de hachage avec le fichier signifie que le client final peut vérifier les données téléchargées et les corriger si nécessaire. Les sources multiples sont pour la vitesse. Donc, oui, dans ce cas, il est avantageux d'utiliser BT pour garantir le transfert correct d'un fichier.
Underverse