Est-ce que dd fait une vérification?


16

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


Définissez «l'intégrité est sécurisée».
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen Je veux dire que la copie est identique à l'original.
Sparhawk

Si vous ne disposez que de fichiers plats, la méthode traditionnelle pour copier des fichiers utilise tar ou cpio. GNU tar a un indicateur de vérification: gnu.org/software/tar/manual/html_section/tar_81.html . Ces jours rsyncseraient probablement les plus simples.
Thorbjørn Ravn Andersen

1
"sauf erreur matérielle" indique qu'il ne fait aucune vérification. Si c'était le cas, il pourrait détecter la panne matérielle.
Barmar

Réponses:


20

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.

Je crois que la plupart des supports de stockage utilisent suffisamment de FEC pour détecter + corriger un retournement d'un seul bit.
gardenhead

2
Bien sûr, si vous copiez un disque dur entier avec dd, puis comparez immédiatement le disque dur, vous savez que cela a fonctionné car le cache n'est pas assez grand.
Joshua

1
Merci pour la réponse (+1). Je devrais probablement mentionner que j'utilise un assez basique dd if=/dev/sdc of=/dev/sdb bs=4M, donc ma compréhension est que les problèmes d'ignorer les erreurs et la vitesse (plus ou moins, par rapport à cat) sont sans objet. Voulez-vous simplement vérifier la taille en montant alors df?
Sparhawk

4

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.


4

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


C'est plus compliqué que cela , à la fois sur la lecture et la comparaison et sur la dddétection des erreurs.
Gilles 'SO- arrête d'être méchant'

Eh bien, si vous allez aussi loin, il y dda de graves problèmes de corruption de données, mais des cas spéciaux comme ceux-ci ne faisaient pas partie de la question.
frostschutz

Ces problèmes de corruption pourraient justifier la vérification des données produites à l'aide dd. La vraie solution est d'utiliser n'importe quoi mais ddpuisque la corruption silencieuse des données est une spécialité de dd.
Gilles 'SO- arrête d'être méchant'

2
@ Gilles, ou ne dites simplement pas ddd'ignorer les erreurs. Vous ne pouvez pas exactement blâmer un programme de faire exactement ce que vous lui avez demandé.
Mark

@Mark Et comment, je vous prie, vous dire de ddne pas ignorer les erreurs? Et non, ce conv=noerrorn'est pas une bonne réponse. Voir la réponse de frostschutz pour un exemple. Je ne blâme la conception ddpour faire des erreurs en ignorant un mode par défaut, et qui ne peut être éteint sans connaître sa mécanique interne très précisément.
Gilles 'SO- arrête d'être méchant'

2

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.


Il suffit de démonter / monter le système de fichiers pour forcer le système d'exploitation à écrire le cache du système de fichiers sur le périphérique.
miracle173

miracle173, mais même après la synchronisation, le système d'exploitation ne conserve-t-il pas en cache ce qu'il a écrit? donc je ne suis pas sûr que le démontage effacera tout le cache de la RAM.
Matt

1

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.


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.