Je souhaite créer une nouvelle copie d’un grand nombre de fichiers d’un lecteur local à un autre.
J'ai lu que rsync effectue une comparaison de somme de contrôle des fichiers lors de leur envoi vers une machine distante via un réseau.
Est-ce que rsync fera la comparaison lors de la copie des fichiers entre deux lecteurs locaux?
Si c'est le cas, est-ce une valeur sûre? Ou vaut-il mieux faire une comparaison octet par octet?
Réponses:
rsync utilise toujours des sommes de contrôle pour vérifier qu'un fichier a été transféré correctement. Si le fichier de destination existe déjà, rsync peut ignorer la mise à jour du fichier si l'heure et la taille de modification correspondent au fichier source, mais si rsync décide que les données doivent être transférées, les sommes de contrôle sont toujours utilisées pour les données transférées entre les processus rsync d'envoi et de réception. . Cela permet de vérifier que les données reçues sont les mêmes que les données envoyées avec une probabilité élevée, sans le lourd fardeau lié à une comparaison au niveau octet sur le réseau.
Une fois que les données du fichier sont reçues, rsync les écrit dans le fichier et garantit que si le noyau indique que l'écriture est réussie, les données ont été écrites sans altération du disque. rsync ne relit pas les données et ne les compare pas à la somme de contrôle connue en tant que vérification supplémentaire.
En ce qui concerne la vérification elle-même, pour le protocole 30 et les suivants (premier supporté en 3.0.0), rsync utilise MD5 . Pour les protocoles plus anciens, la somme de contrôle utilisée est MD4 .
Bien que longtemps considéré comme obsolète pour les hachages cryptographiques sécurisés, MD5 et MD4 restent adéquats pour la vérification de la corruption des fichiers.
Source: la page de manuel et le code source de rsync à vérifier.
-cdrapeau par la page de manuel : "Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté de la réception en vérifiant la somme de contrôle de l'ensemble du fichier générée lors du transfert du fichier, mais cette analyse est ensuite automatique. la vérification n'a rien à voir avec la vérification préalable de cette option "Ce fichier doit-il être mis à jour?" chèque. "
rsyncne fait pas la vérification post-copie pour les copies de fichiers locaux. Vous pouvez vérifier que cela n’est pas le cas en rsynccopiant un fichier volumineux sur un lecteur lent (USB), puis en copiant le même fichier avec cp, par exemple:
time rsync bigfile /mnt/usb/bigfile
time cp bigfile /mnt/usb/bigfileLes deux commandes prennent à peu près le même temps. Par conséquent, vous ne rsyncpouvez pas effectuer la somme de contrôle, car cela impliquerait de relire le fichier de destination sur le disque lent.
La manpage est malheureusement trompeuse à ce sujet. J'ai également vérifié cela avec: une fois stracela copie terminée, rsyncaucun read()appel n'est effectué sur le fichier de destination; il ne peut donc pas y avoir de contrôle. Une dernière chose que vous pouvez vérifier, c’est avec quelque chose comme iotop: vous voyez rsynclire et écrire simultanément (copie de la source à la destination), puis il se ferme. S'il s'agissait de vérifier l'intégrité, il y aurait une phase en lecture seule.
rsync -cnouveau si vous voulez le forcer à vérifier.
rsynceffectue une comparaison de somme de contrôle avant de copier (dans certains cas), pour éviter de copier ce qui existe déjà. Le but de la comparaison de somme de contrôle n'est pas de vérifier que la copie a réussi. C’est le travail de l’infrastructure sous-jacente: les pilotes de système de fichiers, les pilotes de disque, les pilotes de réseau, etc. Des applications individuelles telles que celle rsyncn’ont pas besoin de s’inquiéter de cette folie. Tout ce qu'il rsyncfaut faire (et fait!) Est de vérifier les valeurs de retour des appels système pour s'assurer qu'il n'y avait pas d'erreur.
Réponses rapides et sales, directement aux questions.
Q: Est-ce rsyncque la comparaison sera faite lors de la copie des fichiers entre deux lecteurs locaux? R: Il faudra comparer pour savoir quoi copier.
Q: Si cela se vérifie - est-ce une valeur sûre? Ou vaut-il mieux faire une comparaison octet par octet? A: aussi sûr que les mathématiques derrière la somme de contrôle du fichier MD5. Vous pouvez essayer de faire des expériences simples pour apprendre et faire confiance à l'outil.
Réponse longue: Je suppose que vous vouliez rsyncfaire la comparaison de fichiers (bit par bit ou par somme de contrôle) après la copie des fichiers. Si vous êtes l’un des rares à apprécier l’intégrité des données, les éléments ci-dessous pourraient vous être utiles:
rsync -avh [source] [destination] && rsync -avhc [source] [destination]
rsyncdossier de fichiers de code ci-dessus lors de la première exécution et s’il est complet sans problème, s’exécutera de rsyncnouveau immédiatement tout en effectuant la même comparaison de noms de fichiers en utilisant le hachage du fichier entier.Pour garantir que ce test relise physiquement les fichiers du support de lecteur, je suggère de mettre les deux lecteurs hors tension, puis de les redémarrer avant d'exécuter ce test. Cela effacera leurs caches volatiles internes.
Si vous ne redémarrez pas également Linux, vous devriez au moins supprimer les caches ( * ) avec:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Ensuite, relisez les deux arbres et comparez leurs sommes de contrôle:
rsync --dry-run --checksum --itemize-changes --archive SRC DEST
La somme de contrôle rsync moderne utilise MD5, qui est de 128 bits. La probabilité que cela ne détecte pas une erreur dans un fichier individuel est astronomique (quelques discussions ici ), mais pas impossible.
--checksumjusqu'à ce que le test soit passé sans cela.