Quelles sont les causes d’un échec de la vérification de somme de contrôle après une copie réussie sur un NAS ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

What Causes Checksum Verification to Fail After a Successful NAS Copy? - Zima Store Online

La vérification de la somme de contrôle peut échouer après qu'une copie ait signalé un succès parce que la fin de la copie confirme que l'outil de transfert a terminé ses opérations d'écriture, tandis qu'une somme de contrôle demande si les octets source et destination sont identiques au moment où ils ont été lus. Une discordance peut venir de la comparaison de versions ou d'algorithmes différents, du hachage d'un fichier encore en cours de modification, de la lecture de données instables depuis la RAM ou le stockage, ou d'une corruption réelle sur le chemin de transfert.

Que prouve une copie réussie — et que ne prouve-t-elle pas ?

Un statut de copie de fichier réussi signifie normalement que l'outil a créé l'objet de destination et n'a reçu aucune erreur d'écriture fatale. Il peut se baser sur la taille et la date de modification, et il peut ne pas effectuer un hachage de contenu de bout en bout. Une discussion sur un forum NAS domestique recommande de hacher la source et de vérifier la destination après la copie car la complétion ordinaire et l'identité du contenu sont des tests distincts.

Enregistrez quel outil a effectué la copie, s'il a utilisé une vérification, s'il a préservé les horodatages, et quand chaque somme de contrôle a été calculée. Sans cette chronologie, une discordance ne peut pas être attribuée à une corruption lors du transfert ou à une modification ultérieure.

Confirmez que les deux sommes de contrôle décrivent la même version du fichier

Avant d'examiner le matériel, comparez le chemin relatif exact, la taille et l'identité du fichier. Un éditeur photo, un indexeur média, un conteneur de base de données, un client de téléchargement ou un service de synchronisation peut modifier la source après son premier hachage mais avant ou pendant la copie. La destination contient alors correctement une version différente.

Gelez la source en arrêtant l'application d'écriture ou en prenant un instantané en lecture seule. Générez une nouvelle somme de contrôle source à partir de ce point stable, copiez le fichier sous un nouveau nom de destination, puis hachez la destination une fois toutes les écritures terminées.

Utilisez le même algorithme et le même format de manifeste des deux côtés

SHA-256, BLAKE3, MD5, CRC32 et les hachages spécifiques aux applications ou dépôts sont des valeurs différentes même pour des octets identiques. Un manifeste peut aussi contenir des marqueurs en mode binaire, des chemins échappés, ou une somme de contrôle pour un objet compressé plutôt que pour le fichier restauré. Une explication sur l'intégrité des données montre que une somme de contrôle représente un flux binaire spécifique sous un algorithme spécifique.

Exécutez la même commande ou un outil compatible sur les deux fichiers et affichez explicitement l'algorithme. Ne comparez pas une somme de contrôle d'un système de fichiers NAS, un ETag cloud, une valeur de parité RAID ou un hachage de segment de sauvegarde avec un digest SHA-256 du fichier entier.

Vérifiez si le fichier a changé pendant sa copie

Les disques virtuels en direct, les fichiers de base de données, les bibliothèques de photos, les magasins de mails et les volumes de conteneurs peuvent changer entre des lectures séquentielles. Une copie peut se terminer sans erreur d'E/S mais représenter un mélange non atomique d'états. Arrêtez l'application, utilisez sa méthode de sauvegarde ou copiez à partir d'un instantané avant de répéter la vérification.

La vérification rapide normale de Rsync et sa comparaison de somme de contrôle répondent à des questions différentes. Une explication technique de mode somme de contrôle versus comparaison temps-et-taille illustre pourquoi une décision de transfert basée sur les métadonnées n'est pas équivalente à une vérification du contenu après copie.

Répétez le hachage pour détecter un chemin de lecture instable

Calculez le hachage du même fichier source inchangé plusieurs fois sans le copier. Puis répétez sur la destination. Un fichier stable doit produire le même résultat à chaque fois. Si un côté change les hachages lors de lectures répétées, le transfert n'est pas le premier suspect ; enquêtez sur la mémoire, le contrôleur, le périphérique cache, le câble, le disque et le système de fichiers de ce système.

Un cas DrivePool a révélé que le striping de lecture produisait des résultats de somme de contrôle incohérents. Le modèle de diagnostic important n'est pas le paramètre spécifique du produit, mais que des lectures répétées d'un même fichier inchangé ont retourné des octets différents.

Associer le modèle d'échec à la RAM, au câble, au contrôleur ou au disque

Si de nombreux fichiers non liés ne correspondent pas sur chaque cible, suspectez le chemin de lecture source ou la RAM du client. Si les divergences suivent un disque NAS, un périphérique cache, un port ou un contrôleur, isolez ce composant. Si seuls les gros transferts SMB échouent, testez le même fichier localement sur le NAS et via un autre client.

Une enquête d'Unraid sur les échecs de somme de contrôle après transfert de fichier identifie l'isolation de la RAM et du contrôleur comme des tests concurrents plutôt que de supposer que seul le réseau a corrompu les données.

Ne pas confondre les différences de métadonnées avec les différences de contenu

L'heure de modification, l'heure de création, la propriété, les ACL, les attributs étendus, l'allocation parcimonieuse et la casse du nom de fichier peuvent différer alors qu'un hachage de contenu de fichier complet correspond toujours. Inversement, une taille et un horodatage identiques ne prouvent pas un contenu identique.

Si votre outil de vérification inclut les métadonnées dans son manifeste, séparez l’écart de contenu de l’écart de métadonnées. Préservez les métadonnées requises avec une méthode de copie adaptée, mais ne considérez pas une différence de simple horodatage comme un contenu de fichier endommagé.

Utilisez une matrice de test contrôlée avant de recopier tout

Résultat du test	Cause probable	Étape suivante
Le hachage source change lors de lectures répétées	Fichier source encore en changement ou chemin source instable	Arrêtez les écritures, faites un instantané, puis testez la RAM et le stockage
Source stable ; hachage destination change	Chemin de lecture destination, cache, RAM ou disque	Lisez localement, contournez le cache, isolez le disque/contrôleur
Les deux stables mais différents	Mauvaise version, copie incomplète ou corruption lors du transfert	Recopiez vers un nouveau chemin et vérifiez immédiatement
Le hachage correspond mais l’outil échoue toujours	Chemin du manifeste, algorithme ou interprétation des métadonnées	Inspectez le format de vérification et la cartographie des fichiers
Un seul chemin matériel échoue	Câble, port, contrôleur, client ou composant cible	Changez une variable et répétez le même fichier test

Utilisez un fichier test immuable assez grand pour solliciter le chemin, et ne changez qu’une variable par essai : client, protocole, partage NAS, paramètre de cache, disque, câble ou port. Conservez les copies de destination échouées jusqu’à ce que vous sachiez si l’écart est répétable.

Choisissez l’action de récupération selon les preuves

Si la source est stable et fiable, recopiez le fichier non conforme sous un nouveau nom et vérifiez avant de remplacer la destination défectueuse. Si la source est aussi instable, protégez les autres données lisibles et examinez le matériel avant d’effectuer des lectures complètes répétées.

La santé de l’ensemble et l’identité du fichier restent des vérifications différentes. Le guide ZimaSpace pour vérifier les sommes de contrôle après un remplacement de disque défaillant explique pourquoi la cohérence RAID doit être suivie d’une comparaison au niveau fichier contre un manifeste ou une sauvegarde fiable.

FAQ

Une heure de modification différente provoque-t-elle un écart de somme de contrôle ?

Pas pour une somme de contrôle basée uniquement sur le contenu. Elle peut échouer dans un rapport de vérification prenant en compte les métadonnées, mais des octets de fichier identiques produisent le même hachage de contenu.

Peut-on faire confiance à une somme de contrôle qui correspond au deuxième essai ?

Seulement après que le même fichier inchangé produise des hachages répétables et que la cause du premier écart soit comprise. Un écart intermittent est en soi un avertissement.

Un fichier non conforme doit-il déclencher une recopie complète ?

Pas immédiatement. Isolez si l’échec suit le fichier, la source, la destination ou le chemin de transfert, puis recopiez la portée affectée et vérifiez-la.

Conclusion finale

Une copie NAS réussie et une vérification de somme de contrôle réussie valident des propriétés différentes. Confirmez la même version de fichier et l'algorithme, figez les données en direct, répétez les hachages pour tester la stabilité de lecture, isolez le matériel une variable à la fois, et remplacez les données uniquement après qu'une source fiable ait produit une destination stable correspondante.