Est-ce que dd fait une vérification?

J'utilise ddpour copier des données d'un ancien disque dur vers un nouveau. Je veux être sûr que l'intégrité des données est sécurisée.

Sur cette réponse , Gilles dit

Si [dd] s'est terminé avec succès, alors la sauvegarde est correcte, sauf erreur matérielle…

Qu'est-ce que ça veut dire exactement? Y dda- t -il une sorte de vérification intégrée?

Si je devais utiliser rsync à la place, j'exécute également une deuxième passe avec --checksum, pour vérifier. Ce genre de paranoïa est-il justifié?

ddou toute autre application n'a pas "une sorte de vérification intégrée" dans le sens auquel vous pensez probablement: elle ne lit pas les données du support de stockage pour les comparer avec ce qui a été écrit. C'est le travail du système d'exploitation.

Il n'est pas vraiment possible d'effectuer une lecture-vérification du matériel à partir d'une application. Cela fonctionnerait dans certains scénarios, mais dans la plupart des cas, cela n'aboutirait à rien. L'application pourrait relire ce qu'elle vient d'écrire si elle écrit directement sur un support de stockage , mais cela relira généralement à partir d'un cache en mémoire, ce qui ne donnerait aucune assurance utile. Dans l'exemple que vous citez , ddécrit sur un tube, et dans ce cas, il n'a aucun contrôle sur ce qui arrive aux données plus loin sur la ligne. Dans votre exemple rsync, une deuxième passe dersync --checksum est inutile: en théorie, il pourrait attraper une erreur, mais en pratique, si une erreur se produit, alors la deuxième passe ne rapporterait probablement rien de mal, donc vous gaspillez des efforts sur quelque chose qui ne donne pas réellement une assurance utile.

Cependant, les applications ne vérifient ce qui se passe aux données, au sens où ils vérifient que le système d'exploitation a accepté la responsabilité pour les données. Tous les appels système renvoient un état d'erreur. Si un appel système renvoie un état d'erreur, l'application doit propager cette erreur à l'utilisateur, généralement en affichant un message d'erreur et en renvoyant un état de sortie différent de zéro.

Attention, c'est ddune exception: selon les paramètres de la ligne de commande, ddpeut ignorer certaines erreurs . C'est extrêmement inhabituel: ddc'est la seule commande courante avec cette propriété. Utilisez à la catplace de ddcette façon, vous ne risquez pas la corruption et cela pourrait être plus rapide .

Dans une chaîne de copie de données, deux types d'erreurs peuvent survenir.

• Corruption: un peu est retourné lors du transfert. Il n'y a aucun moyen de vérifier cela au niveau de l'application, car si cela se produit, c'est en raison d'un bug de programmation ou d'une erreur matérielle qui est très susceptible de provoquer la même corruption lors de la lecture. Le seul moyen utile de vérifier qu'aucune telle corruption ne s'est produite est de déconnecter physiquement le support et de réessayer, de préférence sur un autre ordinateur au cas où le problème proviendrait de la RAM.
• Troncature: toutes les données qui ont été copiées ont été copiées correctement, mais certaines des données n'ont pas été copiées du tout. Celui - ci est la peine de vérifier parfois, en fonction de la complexité de la commande. Vous n'avez pas besoin de lire les données pour cela: vérifiez simplement la taille.

Non, ddne fait pas de vérification explicite. Si vous souhaitez / avez besoin d'une copie de votre disque ou d'une partie de celle-ci, utilisez dcflddune version améliorée de dddéveloppée par le Département américain de la défense informatique Forensics Lab.

La seule façon d'être «sûr» est d'effectuer une passe de lecture et de comparaison supplémentaire (après avoir supprimé les caches).

En plus de cela, dddétecte les erreurs de lecture et d'écriture de la même manière que tous les autres programmes ... cela fonctionne si les lecteurs (et les autres composants impliqués) signalent des erreurs; pour les lecteurs qui acceptent les données en silence sans les écrire, vous n'avez pas de chance.

Ce genre de paranoïa est-il justifié?

Si vous ne pouvez pas faire confiance à votre matériel pour être fiable, les choses se compliquent ...

Oui, un matériel défectueux peut insérer des bits d'erreur aléatoires dans les données à un certain taux comme un bit par nombre de mégaoctets, cela est possible et se produit parfois en pratique.

Habituellement, j'utilise le hachage md5 ou sha1 pour vérifier que les données sont intactes, en relisant à la fois la source et la destination, par exemple:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Cela suppose que les données sont beaucoup plus volumineuses que le cache du système de fichiers, sinon, vous devrez peut-être redémarrer le système pour vérifier les données réelles sur le support et non le contenu du cache, ou utiliser un autre système pour cela.

De man dd:

Une fois terminé, dd affiche le nombre de blocs d'entrée et de sortie complets et partiels, les enregistrements d'entrée tronqués et les blocs d'échange d'octets de longueur impaire à la sortie d'erreur standard.

Un bloc d'entrée partiel est un bloc dont la taille inférieure à la taille du bloc d'entrée a été lue. Un bloc de sortie partiel est un bloc où une taille inférieure à la taille du bloc de sortie a été écrite. Les blocs de sortie partiels vers les unités de bande sont considérés comme des erreurs fatales. Sinon, le reste du bloc sera écrit. Des blocs de sortie partiels vers des périphériques de caractères produiront un message d'avertissement.

ddvérifie que les tailles de bloc d'entrée / sortie correspondent à chaque fois qu'il copie un bloc. S'ils ne le font pas, il gère l'erreur avec un avertissement ou une erreur fatale (remplacée par noerror). C'est pourquoi ddfonctionne pratiquement tout le temps.

Pourtant, il ne remplace pas la vérification manuelle de l'intégrité de votre disque. Si les informations vous sont précieuses, alors oui, votre paranoïa est justifiée . Exécutez une vérification manuelle une fois ddterminée.